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

[Harald Hoyer]

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

> On Fri, Mar 1, 2013 at 2:26 PM, Lennart Poettering
> <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20130301/d1f5dc85/attachment-0001.html>