I will update the patch as soon as I get home :-) Best Regards, Tobias PS: How do you send patches to this list via gmail? I pasted the output from git format-patch into the mail client, bit there got to be a better way:-) <div class="gmail_quote">On Oct 9, 2014 4:08 PM, "Lennart Poettering" <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, <a href="tel:09.10.14%2009" value="+499101409">09.10.14 09</a>:37, Tobias Hunger (<a href="mailto:tobias.hunger@gmail.com">tobias.hunger@gmail.com</a>) wrote: > On Oct 8, 2014 2:15 PM, "Harald Hoyer" <<a href="mailto:harald.hoyer@gmail.com">harald.hoyer@gmail.com</a>> 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 -- Lennart Poettering, Red Hat </blockquote></div>