Hi J,
On Thu, Aug 11, 2016 at 06:15:32AM -0700, J Mo wrote:
On 08/11/2016 05:31 AM, Daniel Golle wrote:
That's what I told you in the previous mail, removing the rootfs= parameter from the dts should do the trick, because you just cannot mount a ubi device (which is a character device in Linux) with a block-based filesystem (like squashfs). This cannot and won't ever work and you could either leave it to OpenWrt/LEDE's auto-probing to figure out what to do based on the rootfs type (non-ubifs vs. ubifs) or append even more board- and filesystem-specific crap to your cmdline such as ubiblock=... root=/dev/ubiblock0_1 (however, that then won't work for ubifs, thus the auto-probing patches).
... OH!
Well, I needed some extra intellectual clubbing to catch on.
NOW I remember reading the UBI docs, about glubi, the fact that volumes are char devices, and I even seem to remember some ALL CAPS red size-20+ text at the top of the page saying something about it.
Tomorrow I'll go read the docs again, because I know I remember reading that you could put a RO-squashfs in a UBI volume. I just need to have it mounted the right way.
Exactly. However, this makes mounting a UBIFS volume entirely different from mounting a volume with any other (read-only) filesystem which needs a ubiblock device (gluebi has been deprecated in favour of ubiblock) to be created and subsequently mounted. The idea of the auto-probing patches [1] was to keep things filesystem- agnostic, ie. allow for either a single read-write UBIFS rootfs or any read-only filesystem (e.g. squashfs) which needs ubiblock and have a UBIFS read-write overlay on top. In this way, all you have to take care of is *not* to have any rootfs= or ubi* parameters in your kernel cmdline and all the rest should happen automagically.
Cheers
Daniel