robustini
commented
1 year ago Interesting, don't ask me why but apparently all the services start, i've the msp-osd working in the Goggles!
It's the configurator that doesn't intercept them after a reboot for that initd issue, so the services cannot be enabled or disabled in the startup section, I can do it in that page only after an rc.unslung restart in CLI! Tested on two identical Vista Light, one with firmware 606 and the other with 608, same issue. So, after a reboot:
root@pigeon_wm150_tiny:/ # dinitctl list dinitctl: connecting to socket /data/.dinitctl: No such file or directory
And after a "/opt/etc/init.d/rc.unslung restart":
root@pigeon_wm150_tiny:/ # dinitctl list [[+] ] boot [{+} ] wtfos-auto-naco [{+} ] msp-osd-airside (pid: 2736)
So this initd does its job at boot but then something abnormal happens, then dying. I hope this report will be helpful to you in intercepting the problem, although at the moment the important thing here is that the services work on boot.
stylesuxx
j005u
As I have already documented on Discord this Air Unit Light after rooted regularly does not allow correctly installed packages to run at boot for this dinit issue. But then imparting this command in CLI the two selected services instead run smoothly as you can see in the image, without giving that command i cannot activate them, so I lose them at every reboot:
/opt/etc/init.d/rc.unslung restart
@j005u has already performed remote session to check what it might be but has not figured out where the problem lies, and from what I read on Discord @stylesuxx had helped someone solve this problem always on an Air Unit Lite, I don't know if he succeeded or not. We have already reflashed slot_1 to the stock version after checking the md5 of ota.zip with these commands, it gave no errors:
unrd slot_1.status_successful 0 unrd slot_1.status_active 0 unrd slot_2.status_active 1 rm -rf /blackbox/wtfos reboot
But even after this operation, after wtfos repair/fix the problem was not solved. Now in my ignorance if doing an initd restart after booting solves the problem one solution might be to create a check on whether the selected services actually start during boot (check of related PID or other), in case they are found to be disabled you run an rc.unslung restart, I think that would be the simplest solution. It is possible that the execution of that services at boot occurs at a time where they find a condition so they cannot be executed? I don't know. If you do not understand where efffectively the problem lies I think it is enough to find an empirical way to skip the problem. Tried with 606 and 608 firmware, same problem. Re-executed reflashing with Assistant as well, but I remain in a dead end. Without these services available at reboot the root in this unit is therefore useless. I've execute root and everything else with the configurator on three other identical units and I haven't had any problems, selected services are performed at boot regularly. I'm in your hands........ :-(