[OpenWrt-Devel] [PATCH] fstools: block: make extroot mount preparation more robust

[Kenneth Miller]

I had trouble using an ext4 extroot overlay on my Zyxel NBG6817 running
18.06.2, so I took a closer look at the way libfstools and its block
tool setup the extroot overlay during PREINIT and found some things
broke extroot mounting on certain devices.

The issue and logs are documented in the following ticket:
https://bugs.openwrt.org/index.php?do=details&task_id=2231

What I found was that the main_extroot code would only look for
"rootfs_data" partitions on MTD storage (specifically only JFFS2 and
UBIFS partitions), before defaulting to calling mount_extroot with no
configuration path prefix.
mount_extroot would then try to load the fstab uci config at
/etc/config/fstab, which would fail as this isn't present on the normal
r/o squashfs eMMC partition.

With a /etc/config/fstab uci config be pre-placed on the squashfs,
mount_extroot would continue after loading it and successfully finding
an /overlay extroot entry, but fail during check_extroot when no MTD
partition or UBIFS volume can be found.

With the attached patch the behaviour of main_extroot and check_extroot
is expanded to allow detection of rootfs overlays on block devices such
as eMMC, without compromising the behavior for JFFS2 and UBIFS rootfs
discovery:

1. The default mount_extroot call now uses '/tmp/overlay' as a default
parameter should no MTD partition be detected. This results in
config_load attempting to load a uci fstab with this
prefix before defaulting to /etc/config/fstab.
2. UBIFS_EXTROOT now acts as a supplementary option instead of an
exclusionary one and will allow rootfs discovery on block devices even
when it fails to find UBIFS rootfs volumes.
(IMHO the best design decision as this option defaults to 'y' in the
fstools package configuration)