[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