[OpenWrt-Devel] [PATCH/RFC 0/3] UBI: unify mouting rootfs based on cmdline parameter

[Daniel Golle]

Hi Richard,

On Sat, Aug 27, 2016 at 11:23:14PM +0200, Richard Weinberger wrote:
> Daniel,
> 
> On 27.08.2016 23:06, Daniel Golle wrote:
> > Hi Richard,
> > 
> > thanks for the quick reply!
> > 
> > On Sat, Aug 27, 2016 at 10:43:45PM +0200, Richard Weinberger wrote:
> >> Daniel,
> >>
> >> On 27.08.2016 21:43, Daniel Golle wrote:
> >>> Hi!
> >>>
> >>> In an attempts to fix the flaws of the current set of UBI-related
> >>> patches we are carrying in OpenWrt, I re-wrote the way mounting the
> >>> rootfs from UBI in OpenWrt/LEDE works. The main requirement I face
> >>> which cannot be easily addressed using other means which are already
> >>> available in the kernel is the fact that UBIFS and squashfs-on-UBI
> >>> require different parameters to be set on the cmdline, e.g.
> >>> for UBIFS: ubi.mtd=ubi root=ubi0:rootfs rootfstype=ubifs
> >>> for squashfs: ubi.mtd=ubi ubiblock=0,1 root=/dev/ubiblock0_1 rootfstype=squashfs
> >>>
> >>> The idea behind this patchset is to provide a single syntax which
> >>> allows mouting rootfs in both cases. To achieve that, the parsing of
> >>> the volume name string from UBIFS is moved to UBI, so it can be
> >>> reused by other in-kernel users. This is then used by init/do_mounts.c
> >>> to create a ubiblock device if the filesystem on the device is
> >>> non-UBIFS. To actually set this device to be ROOT_DEV, ubiblock_create
> >>> is extended to allow passing-back the created ubiblock device.
> >>>
> >>> With those changes, a single set of cmdline parameters is
> >>> sufficient to mount either UBIFS or any other block filesystem
> >>> by creating a ubiblock device:
> >>> ubi.mtd=ubi root=ubi0:rootfs rootfstype=ubifs,squashfs
> >>
> >> well, this all boils down to the point we have already been.
> >> I will tell you do set the cmdline correctly, either via bootloader
> >> or devicetree, or use an initramfs.
> > 
> > I got that points and this patchset is meant to made exactly that
> > possible -- using the kernel cmdline to specify the rootfs.
> > However, usually the filesystem type doesn't need to be explicitely
> > taken into account by the bootloader.
> > 
> >>
> >> I can understand that OpenWrt/LEDE sometimes has to start from a hostile
> >> bootloader which doesn't let you changing the cmdline.
> > 
> > On most systems, *users* do not have bootloader access. Surely, our
> > build-system could generate images with different built-in cmdlines
> > depending on the bundled filesystem types.
> 
> Since you have to provide anyways per-device images because the flash
> type/geometric of each device are different it wouldn't hurt having
> a per device cmdline too, right?

Right, but on the same device using the same kernel you might have
ubifs or squashfs as rootfs when using OpenWrt/LEDE and the like.
Why should the bootloader (or even the device-tree) contain any
knowledge about that?
I reckon we are both aware that re-installing or modifying the
bootloader is far less common on non-x86 targets and is usually avoided
to minimize risks and added complexity to OS installers.

> 
> >> But you can still set (and override) it either using CONFIG_CMDLINE or
> >> in your device tree.
> >> For advanced booting you can also use a inittamfs.
> >>
> >> So, what do I miss?
> > 
> > On block devices, GRUB doesn't need to set any parameters differently
> > depending on the rootfstype being squashfs, xfs or ext4, right?
> 
> No, this works only for trivial storage stacks on x86 when booting from a
> disk.
> For squashfs you need an initramfs anyways on most setups
> since squashfs is stored as regular file.

I've never seen that (squashfs loaded from a filesystem which was
mounted by what's running on the initramfs) on any small embedded
device in my life. *That's* a very complex setup.
Most commonly, squashfs is mounted by the kernel from /dev/mtdblock*.
In the past, most people who were force to use UBI then ended up using
gluebi and then mounting squashfs off the gluebi mtdblock device -- I
understood that ubiblock is intended to replace those legacy hacks and
meant to be the official way to mount non-UBIFS read-only filesystems
store on UBI volumes, right?

> 
> For everything non-trivial, may it RAID, LVM or iSCSI, it won't work
> automagically.

With that in mind, why should a simple system which anyway stores the
kernel and filesystem on the same physical media have an initramfs?

> 
> > On UBI, this assumption no longer holds true, which imho is the
> > remaining core of the problem, which I meant to illustrate using the
> > example in the previous message I've sent.
> 
> Having squashfs on top of ubiblock which is ont op of UBI is something
> non-trivial IMHO.

Ok, so that seems to be the essence of our disagreement. From my
perspective, this setup seems to be the most trivial possible on small
embeeded devices which come with NAND flash and thus do benefit from
using UBI.

> 
> > Do you really explect that the bootloader should probe the rootfs-type
> > and based on that, re-write the cmdline parameters?
> 
> No, the bootloader should *know* on what device it runs on and has to set
> the cmdline correctly. Exactly as we do on every embedded system for ever.
> I don't think OpenWrt/LEDE is so special.

I certainly agree about that. However, depending on the use-case and
stage of development (!), one might choose to use UBIFS as read-write
rootfs or to use squashfs and have a overlay on-top. Thus, the rootfs-
type used on the exact same device may vary, also during the device's
lifecycle.
Using UBIFS as rootfs allows granular rolling-release-style updates
and makes prototyping easy. On more robust production firmware, a
read-only image with either a read-write overlay or just some plain
configuration allows easily reverting to the factory-defaults and
updating the whole system with a replacement image.

> 
> > Just having "ubi.mtd=ubi root=ubi0:rootfs rootfstype=squashfs,ubifs"
> > looks nicer than that, doesn't it?
> 
> I don't agree. Adding more auto probe hacks to the kernel for the sake
> of looking nice are not worth it.

The value I advertise is functional, not just esthetical.
By the end of the day, probing the rootfs-type will to live somewhere.
I agree that for complex setups, an initramfs should be used. However,
an easy an generic way to boot also without mandatory initramfs should
still be possible, even on boards having NAND flash.
In the current (whacky) way we roll UBI support in the kernel, it also
allows the same binary kernel to be used for other distributions (eg.
Debian or archlinux with an UBIFS rootfs on hardware not officially
supported by those distributions)
This added value of having a universal kernel would be lost if high-
level decissions such as the filesystem type would be dictated by
either built-in kernel parameters, the device-tree or the bootloader.
My intention is to preserve that feature in a way which still shouldn't
hard-code the rootfs volume name (which it does, forcing more complex
bootloader setups to come up with a great variety of vendor-specific
implementations).

> Since you have to have *at least* a per device device tree it is perfectly
> fine adding the correct rootfs cmdline to it.
> You also have to specify per device in your device tree the correct MTD
> layout for each device.

Same argument as above: this doesn't imply that the filesystem type
used as a rootfs is the same for all use-cases (and even more so, all
other distributions to run on the same board, ideally without
modifications to the bootloader, it's evironment or the device-tree).

All that being said, I agree that none of the other patches are truely
needed. However, if the cmdline cannot be rootfstype-agnostic, I'll
have to work my way around that. I'll happily work on making that
possible and improve things where needed. I'm still hoping for
constructive criticism on how a generic and thus also rootfstype-
agnostic kernel can truly be achieved *without* using an initramfs on
simple devices.


Cheers


Daniel


> 
> Thanks,
> //richard
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel