[systemd-devel] [PATCH 1/2] fstab-generator: initrd - mount the entries in /etc/fstab.sys from the initramfs

Harald Hoyer harald.hoyer at gmail.com
Fri Mar 1 11:04:04 PST 2013


On Fri, Mar 1, 2013 at 3:16 PM, Tom Gundersen <teg at jklm.no <mailto:teg at jklm.no>>
wrote:

    On Fri, Mar 1, 2013 at 2:26 PM, Lennart Poettering
    <lennart at poettering.net <mailto:lennart at poettering.net>> wrote:
    > Also, besides / and /usr, is there anything else that would ever show up
    > in fstab.sys? If it's only these two, then it appears much nicer to me
    > to simply have two kernel cmdline options for these (we have one
    > anyway... for /). I mean, being generic and stuff is all cool, but let's
    > not make things too generic here, if there's no reason to.

    I don't know how useful it is, but I have seen people asking for
    support for subdirs of /usr as separate mounts. If we agree that
    that's something we don't want to support by default that's fine with
    me.

    >> Two alternatives were considered, but decided against:
    >>  * configure usr= on the kernel commandline in the same way as root= is.
    >>    However, this would be restricted to only the /usr mountpoint, and the
    >>    kernelcommandline is crowded enough as it is, so it seems more
    reasonable to
    >>    store the configuration in /etc (as we can). Moreover, this logic
    would allow
    >>    us to use more configuration sources from /etc in the future should
    that be
    >>    necessary.
    >
    > But this sounds like something you need anyway, if you ever want to
    > support "generic" initrds that work everywhere, and whose sole source of
    > configuration is cmdline hence, right? With just one more option on the
    > kernel cmdline for usr= I don't really buy the "too crowded"
    > issue... Dunno. Do you see any further uses of this?

    I believe one instance where this might be useful would be to share
    /usr/share between different architectures, but I suppose that could
    have been solved by a specially crafted initrd and don't need to be
    supported by default.

    >>  * configure the 'sys-mounts' in /etc/fstab. This would require a
    heuristic to
    >>    decide which mounts sohuld be taken care of by the initramfs and which
    to be
    >>    taken care of by the real init. I could not come up with a non-hacky
    way of
    >>    doing that. Perhaps there is use-case for mounting with one set of
    options in
    >>    the initrd and remounting with a different set of options in the real init
    >>    (like can be done for the rootfs)? Keeping everything in fstab would make
    >>    that impossible.
    >
    > Well, you could always introduce "x-initrd" as a mount option to set for
    > mounts, if you really want to be this generic, and then filter for
    > it. And also imply it for / and for /usr. But honestly, the usr= kernel
    > cmdline thingy sounds much simpler and sexier to me?

    If we only want to support / and /usr, and don't care about stuff like
    /usr/local or /usr/share on separate mounts, then going with usr=
    makes sense to me. It would also make everything else much simpler (no
    need to reload settings after mounting sysroot). I already wrote the
    patch for usr=, so I'll send it out soon.

    Harald, what do you think?

 
"x-initrd" or "x-initrd.mount" sounds good, but I would imply "x-initrd" for
"/usr" if "noauto" is not set.

/etc/fstab.sys could just be copied to /etc/fstab in the initramfs. For the rest
"x-initrd" can be used easily.

Main usage is for things, which get mounted in the initramfs, survive the
switch-root and cannot be remounted with different options, because they are busy.

/dev/shm and /run come to my mind.


More information about the systemd-devel mailing list