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

[Harald Hoyer]

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.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>"

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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>