[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