I’ve just upgraded a GL.iNet GL-MT6000 to 25.12.2 and my /etc/rc.local that looks for files on a mounted USB SD card reader no longer finds them because it appears to be being called before the external volume is mounted. On 25.12.1 on a Netgear WAC124 the USB volume is mounted before /etc/rc.local is called. Any ideas?
The startup sequencing is not deterministic in terms of the timing that tasks complete. Services/scripts will be started in the order specified, but it is not guaranteed that each completes before the next begins to execute.
With that said, the solutions I’d recommend would be to either add a sleep interval at the beginning of your script (this is super easy, but not necessarily robust), or add logic to the script to test for the presence of the mount point before progressing. If the mount has not yet occurred, it can wait a short time and try again. Once the mount is ready, it can proceed to the existing script.
I remember trying that back with 19.7.x and found that rc.local was blocking anything new from starting up while it was still running.
If the action you were waiting for has already been spawned by procd then it could work, but otherwise not.
I wonder if this is still the case?
Anyway, my solution at the time was to add a line to rc.local to spawn my actual script, eg something like:
/usr/lib/myscripts/my_startup_script.sh &
Then my_startup_script.sh can quite happily loop while waiting for whatever to complete.
In my case it was waiting for a network bridge to come up, but same applies if waiting for a mount to be completed.
Well, the LuCI UI editor for rc.local says “This is the content of /etc/rc.local. Insert your own commands here (in front of 'exit 0') to execute them at the end of the boot process.” which kind of implies it runs after everything else but yes, a backgroup process is how I’ve worked around it as well.
Interesting that /etc/init.d/fstab (which runs “/sbin/block mount”) is at priority 11 and /etc/init.d/done (which runs /etc/rc.local) is at priority 95. But I guess USB devices (“/sbin/block hotplug”) may be triggered later via hotplug. Just odd that I’ve never had this issue until 25.12.2. Hey ho.
It certainly was a thing back in the 19.7.x days so not a new "feature" at all.
Ah, maybe I only started using rc.local and/or USB storage on later revisions. Thanks for the info. I guess this thread is closed.