[systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=

[Harald Hoyer]

On 09.10.2014 16:08, Lennart Poettering wrote:
> On Thu, 09.10.14 09:37, Tobias Hunger (tobias.hunger at gmail.com) wrote:
> 
>> On Oct 8, 2014 2:15 PM, "Harald Hoyer" <harald.hoyer at 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>"

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=... :-)