On 09.10.2014 16:24, Harald Hoyer wrote: > On 09.10.2014 16:08, Lennart Poettering wrote: >> On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hun...@gmail.com) wrote: >> >>> On Oct 8, 2014 2:15 PM, "Harald Hoyer" <harald.ho...@gmail.com> wrote: >>>>> What is the rationale of this patch? >>>>> Supporting systems without /etc/fstab in the root device? >>>>> Overriding the /etc/fstab settings? >>>>> >>>>> In a systemd initrd (e.g. in dracut) as soon as initrd-root-fs.target is >>>>> reached, initrd-parse-etc.service is executed, which retriggers the >>>>> fstab-generator and reads fstab from the real root and generates units >>> for /usr. >>> >>> Hello Harald, >>> >>> The use case is exactly the one Lennart described in his blog about >>> deploying Linux in the future. >>> >>> My setup now looks like this: I got a Btrfs partition for my Linux >>> installations. This partition has a subvol root:somename:someid:x86_64 >>> containing a Linux installation minus /use. >>> >>> Then I have several versions of /use for that distribution in more >>> subvolumes named usr:someid:x86_64:version (all with different versions, >>> basically getting incremented whenever a new set of packages gets >>> installed). >>> >>> The idea is to now be able to write bootloader entries for all versions the >>> somename-installation. >>> >>> For that the initrd needs to know which /usr to mount on top of the root >>> partition. >>> >>> I can not use the fstab from the root drive here, because that would always >>> point to the same version of /use, preventing me to roll back/forward when >>> something breaks during an upgrade. >>> >>> What I could do instead is to put the information about which subvol to >>> mount at /use into the initrd. But I actually think the way of passing this >>> into initrd in the same way as the rootfs is more consistent and it also >>> saves me from having a new initrd in /boot when libreoffice gets updated. >>> That *might* be necessary when using secure boot, but only then. >>> >>> Does this explain my motivation for this patch sufficiently? >> >> Hmm, so I think this should be merged, but I'd like to ask for one >> more change. We really want to avoid inventing new non-namespaced >> kernel command line options, that's really something we should leave >> to the kernel guys... >> >> Hence, I'd propose using "mount.usr=", "mount.usrflags=" and >> "mount.usrfstype="... Or maybe "fs." as prefix? Or "mnt."? But I think >> "mount." is the nicest one, even if it is slightly more to type. >> >> Hope that make sense? >> >> (OTOH I just yesterday merged a patch that introduced a new >> un-namespaced kernel cmdline option "rescue", so I am not totall fair >> here, but I think that's a special case...) >> >> Lennart >> > > Just be careful choosing the prefix. It must not be the name of a kernel > module, otherwise this kernel module is presented with all those options, > which > might freak out that module. > > I accidentally chose "rd." not knowing that "rd" is a module alias for the brd > kernel module. > > Just check with a recent kernel: > # modinfo "<prefix>"
Oh, that might not work with builtin modules and not shipped modules. So you have to manually check the kernel source code :-/ > > I have the feeling, we should somehow register a namespace for userspace on > the > kernel command line or have global list. :-/ > > I just don't want to end with something like > org.freedesktop.systemd.log_level=... :-) > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
