Scripts and /etc/rc.local on bootup
-
@Costas-Costas said in Scripts and /etc/rc.local on bootup:
Tried that, doesn't work.
reboot -d 1 will not reboot an Omega that is running my script from /etc/rc.local.
Because it has no way of stopping that script to get the system to a safely rebootable state. Or more importantly its children - the script itself should have done its work and completed shortly after boot, not continued to run.
Need to test if it will reboot a /etc/init.d script.
When properly setup, a properly setup and invoked reboot command should run the shutdown side of your script to top your custom service, get the system to a safely rebootable state, then reboot it.
You can of course invent new ways of doing things; the point is that there's already a mechanism for doing this, which is available if the system and your extensions to it are correctly configured.
-
Warning init.d in the wrong hands is dangerous!
@Chris-Stratton I set up init.d, but badly and now I'm locked out of the Omega (2+).
I removed the & from the node.js call because I thought it was making the script restart when I stopped it. I think actually the node.js script has inbuilt restart as the service should run at all times.
In the init.d script I set START=40 and I'm guessing this is before ssh kicks in and without the & my perpetual node.js script has taken over control of the Omega.
I still have Smartphone control of the Omega, excluding reboot but I can't make any further changes to it. I don't use any of those dock things.
What is the process for resetting the Omega now that i'm locked out?
-
@Costas-Costas said in Scripts and /etc/rc.local on bootup:
Warning init.d in the wrong hands is dangerous!
root access in the wrong hands is dangerous, but less so on a system with so little corruptible state (until you get to interacting with the uboot and firmware partitions)
@Chris-Stratton I set up init.d, but badly and now I'm locked out of the Omega (2+).
Only if you rely on the network for maintenance while developing, which would be a problem sooner or later anyway. This is what safe mode on the serial console is for - it boots without the overlay containing your changes.
Or you can do a factory reset via the button.
Given the way these systems store changes, you need to be backing up your work anyway.
-
@Chris-Stratton I will try console access shortly but I did try"reset" earlier without success.
I have the latest firmware. Should reset just be held to ground for up to 30 seconds and does it only kick in if you do it on reboot?
-
@Chris-Stratton console access worked just fine, phew.
Will changing START=40 to something like START = 100 allow ssh to kick in before my init.d script?
I have added the & to my node.js call but I'm not convinced it will work because the node.js script is self perpetuating.Still interested to know from anyone how reset to factory firmware is done with the rst pin.
-
@Costas-Costas said in Scripts and /etc/rc.local on bootup:
@Chris-Stratton console access worked just fine, phew.
Will changing START=40 to something like START = 100 allow ssh to kick in before my init.d script?
That's probably not a workable goal - even if you get the ssh server up first, you may not have network connected yet, have had a chance to use it yet, etc.
Generally, if you are going to have a system with only radio access, you first test heavily on a system that has serial console access, and changes only make it o the radio-based system after they have been well proven.
More complex systems sometimes include an auto-rollback to an older stable version or a maintenance mode (in your case, ssh but not node red), for example by leaving indications behind that can be seen on startup after a crash. It looks like the MT7688 has some registers intended for this kind of usage, which is simpler than trying to do it with magic values in main memory and then having to make sure that they don't get lost in DDR re-initialization, or startup memory walking.
Essentially you could do something like this:
- on boot, if register is blank set it to UNCOMMANDED_REBOOT_1
- if it is already UNCOMMANDED_REBOOT_1 set it to UNCOMMANDED_REBOOT_2
- if it is UNCOMMANDED_REBOOT_2 startup in safe mode.
When commanding a reboot, first set the register to REBOOT_COMMANDED so it is clear that this was intentional and not a crash.
-
@Chris-Stratton If I understand you right, you want to start a script at start up time from init.d, the script you are starting is to carry on running once init.d has completed but you want your script to be started only once ssh server is fully up.
What I would suggest you do is create an additional shell script (e.g. call it startmyscript.sh for reference any name will do). Create the file startmyscript.sh containing something like:
sleep <nnn> scritptorunWhere <nnn> is some period long enough for ssh server to start up
and scripttorun is the name of the script to runMake this executable by running the command (once only needed):
chmod +x startmyscript.shThen in init.d (I would suggest at the end but at least after the point where ssh server is started) add the line:
<path>/startmyscript.sh &where <path> is the full path to the directory where startmyscript.sh is kept
This will cause startmyscript.sh to be run as a separate background task. The first thing this does is sleep for the given time, then and only then will it run your script
-
@Kit-Bishop said in Scripts and /etc/rc.local on bootup:
@Chris-Stratton If I understand you right, you want...
No, I have no such need, but was merely responding to someone
sleep <nnn> scritptorunThis is unsafe - it assumes that the prerequisite operations will take a given amount of time, which when they involve things like wifi network registration is simply not valid.
Well designed systems use positive event linkage, not delays.
-
@Chris-Stratton I have moved back to rc.local for now as it is much safer than init.d for a novice like me. rc.local is working flawlessly. As the Omega is a "router" my understanding is that killing processes is no different to switching the power off and back on, which Omega state is fine.
Do you have a link to the registers for the MT7688?
-
@Costas-Costas said in Scripts and /etc/rc.local on bootup:
@Chris-Stratton As the Omega is a "router" my understanding is that killing processes is no different to switching the power off and back on, which Omega state is fine.
No, there is in fact substantial difference, and no, arbitrarily pulling power is not safe.
The key issue is that the stock configurations use a writeable filesystem overlay, and if you pull power from that at an inappropriate time you can end up with bad state there; in theory the journaling provides some protection from this, in practice there still appears to be some risk.
The point of an orderly shutdown is that you tell the system to stop all new access to persistent storage, flush changes, and leaves things in a known good state.
In the typical shipped configurations, the fallback to a broken writeable overlay is the factory reset back to the underlying main partition, which should have been write-only the whole time, and so (at least on these SPI flashes) safe from incompleted-write corruption.
Do you have a link to the registers for the MT7688?
They're in one of the versions of the data sheet can be found online
-
@Chris-Stratton thanks for your feedback.
Until such time as Onion change their stance on powering off their device or one of my Omega's fails I will reboot with the procedure I am currently using.
