[RFC] Advice re auto-extroot for EcoNet platform

Caleb James DeLisle cjd at cjdns.fr
Sun Sep 14 09:50:52 PDT 2025


Hello,

I'm seeking comments regarding how best to provide a default 
auto-extroot implementation for EcoNet (and other) devices.


The EcoNet target is Fiber and DSL modems, these devices use dual-image 
layouts, so the EcoNet target to only ever uses OS-A, thus converting 
dual-image into dual-boot. This way a user can boot the factory OS to 
access the complete drivers. This is important information because it 
means we do not want to disturb the data on flash.


EcoNet devices use NAND but they store raw kernel + squashfs because 
there is a bad block management system. Factory OS uses either a UBI 
partition or just binary "config" partitions, depending on available 
space. They do not use JFFS at all.


To keep with the factory layout, the EcoNet platform uses squashfs + 
ramdisk only.


Many EcoNet devices contain an SDCard reader, USB port(s), or both, so I 
would like to offer extroot as an option.


My goals are:

1. A plain EcoNet OpenWRT build should be capable of automatic 
partition, mount, and pivot if a drive is plugged in.

2. It should never use a drive that isn't partitioned as OpenWRT rootfs

3. It should never partition a drive that isn't meant to be partitioned 
(e.g. use `echo 'OPENWRT DESTROY ALL DATA' | dd ...` to mark the empty 
drive)

4. It should be (easily) reusable in other platforms than EcoNet, in 
case others want it

5. It should have predictable behavior during upgrades


I looked at 
https://openwrt.org/docs/guide-user/additional-software/extroot_configuration 
and https://github.com/attila-lendvai/openwrt-auto-extroot and what I 
found is:


1. Not that easy because it requires a special build using the image builder

2/3. There is a warning that it can trash disks if they're left plugged in

4. Is obviously satisfied (within the limitation of needing to use the 
image builder)

5. There is a note about problems with upgrade


I think there should be a way to implement this as a package so it can 
be selected in the base image build.


I'm thinking the biggest problem with this is the fact that USB is 
implemented as kmods, and kmods are loaded after 80_mount_root, so 
unless that's resolved, extroot is always going to be buggy. I assume if 
it becomes available during preinit, updating should be the same as with 
JFFS / UBI, please correct me if I'm wrong.


I see 3 possible ways around this:

A. Add USB symbols to config-6.12 for EcoNet - Not very reusable to 
other platforms, and hard to turn off when extroot is not wanted

B. Submit a PR to add a config option to make all kmods builtin if 
they're in the base image - Then the extroot option can depend on this.

C. Possibly a way to generate kmod-builtin-xxx for every kmod-xxx (?)


My preference is B, because A is doesn't meet the goals, and I really 
don't know how to go about implementing C. If I did, I would definitely 
make some bad Makefile code which would require a lot of review and 
discussion. Furthermore, making all of the modules built-in has been 
shown to have a significant amount of space-savings ( 
https://openwrt.org/docs/guide-user/additional-software/saving_space#making_all_kernel_modules_built-in 
) so that flag might be worth something to others as well.


The second question is what is the right way to handle devices which 
have a small JFFS or UBI section in addition to the extroot? If it 
exists at the time the extroot is first mounted, we can copy files over, 
but if we boot with the extroot removed, data will be stored there again 
and it will go out of sync. We can imagine creating an init script which 
prints a warning in this case, but the risk will always be present. My 
preference, because I would rather avoid additional code and testing, is 
to ignore whatever may be found in the JFFS / UBI volume for the first 
version.


What do you think, is this a viable idea?


Thanks,

Caleb





More information about the openwrt-devel mailing list