Best way/place to mount a usbstick at /jffs

[mlord]

I want /jffs on my RT-AC68U to point at a USB stick rather than internal flash memory.

It appears that doing it from the init-start script might work.
Is it reasonable to expect the Merlin firmware to behave this way?

My USBSTICK has a partition formatted as ext4, with a label of "JFFS".
My proposed /jffs/scripts/init-script:
#!/bin/sh
## /jffs/scripts/init-script to replace /jffs/ with a USB-stick partition:

... work in progress ...

 

[RMerlin]

It appears that doing it from the init-start script might work.

It won't. There are no mounted USB disk at that point of the boot process.

USB disks are mounted quite late. A lot of features will fail to work if you have the JFFS partition located on disk rather than in flash. OpenVPN processes looking for certificates and the Trend Micro engine require access to files quite early in the boot process or they will fail to start properly.

Moving JFFS to disk is going to break a lot of things, and create nothing but headaches. JFFS is intended to be internal, and available very early at boot time.

 

[mlord]

Since by default, there is no /jffs/ mounted, it would seem odd that parts of the router might have issues with it pointing to a different device when it is mounted.

The script is running now. I just had to add modprobe lines to it to load the USB/storage stacks to detect the USB stick.

It booted, did the flip to the USB stick, and then seems to have processed all of the other scripts and configs from the new mount.

So what isn't supposed to be working here?

Thanks.

 

[mlord]

Ahh.. I added a "ps" command to init-start to see what else was already running at the time. Just about EVERYTHING it seems. It appears that firewall-start is also running at the same time as init-start. That looks a bit racy.

Is there not an earlier place to hook into the system startup than this? Despite the name, "init-start" seems to be called very late during initialization.

Thanks

 

[mlord]

On a related note, is there any way to stop the system from automatically scribbling over the USB partitions when mounted? I've disabled everything to do with samba, yet inserting a USB stick still causes it to have a bunch of .__* files heaped onto each mounted partition.

Thanks again!

 

[mlord]

It appears that firewall-start is also running at the same time as init-start. That looks a bit racy.

Okay, found out why that happens from the source code: It uses run_custom_script() to launch init-start in the background, and continues with initialization in parallel. That's contrary to what the wiki suggests, which is that init-start runs BEFORE most other stuff. Simply not true though.

Perhaps it should be using run_custom_script_blocking() instead of run_custom_script() here? Otherwise init-start isn't quite so useful a hook.

Thanks.

 

[RMerlin]

Since by default, there is no /jffs/ mounted

That's incorrect. The JFFS partition has been used actively by Asus for over a year now, as they store OpenVPN key/certs there, as well as the networkmap database, the Trend Micro Traffic Analyzer database, syslog, etc... It's no longer optional, it's mandatory.

 

[RMerlin]

Perhaps it should be using run_custom_script_blocking() instead of run_custom_script() here? Otherwise init-start isn't quite so useful a hook.

No. All of the scripts (except for the mount ones) are purposely made non-blocking, otherwise a script mistake will force you to do a factory default reset to regain control of your router. This isn't an issue with the mount scripts, as you can simply boot with no USB disk plugged in to recover your router.

 

[mlord]

Yes, they do seem to use it once mounted. But the default router configuration after fresh install was no jffs. And the router worked fine. I guess it just has to be enabled to use the fancier stuff then.

Back to the issue here: init-start is run non-blocking, which means it is NOT guaranteed by any stretch of imagination to run before anything else, which really limits the usefulness of that particular hook. Could you perhaps change that for the next release? Have it use run_custom_script_blocking() instead ?

Doing so would make it much more versatile, allowing us to customize things on jffs before jffs contents are used by other services. Which seems to have been the original intent.

EDIT: Ah. Apologies, I missed your second follow-up post above. Makes sense, though it does mean that the init-start hook is next to useless as a result.

Perhaps a way to address this is to have a simple timeout (say, 10 seconds or whatever) on run_custom_script_blocking() when used for init-start. That way, if the script hangs, things continue as they would today after a short delay. Failsafe.

I can probably code/test that fairly quickly, once I get a working build environment set up here.

Thanks.