klibc - Nov 2011 - kinit, fstabs and mountpoints on the command line

San and I were working out some of the requirements we have for
booting VMs, and we'd like to "construct" the environment
dynamically
from the "outside".  Not all VMs will have block devices (many will
likely be using 9p heavily).  We'd like to continue to use kinit for
this purpose, though at the moment, kinit is processing the root*flags as the
equivalent of a one-line fstab, though we'd like to also
mount other mountpoints before execing the "init=" flag.

Now, I'm wondering if it would make sense to extend the command line
flags understood by kinit to allow specifying other mountpoints
(fstype, source, options), or if the right approach is to use a real
fstab in the initramfs (which can be overlayed by using the kernel's
overlaying of initramfs trees on top of the built-in initramfs trees).

I still don't like the fact that kinit may soon be mounting /sys,
/proc, /dev for the next root image (as this breaks our production
environment where these are not expected to be mounted by the time the
init-on-disk).  Maybe having support for an fstab processed by kinit
would be the best middle ground for this sort of thing?

Thoughts?

Mike Waychison

On 11/04/2011 10:52 AM, Mike Waychison wrote:
> San and I were working out some of the requirements we have for
> booting VMs, and we'd like to "construct" the environment
dynamically
> from the "outside".  Not all VMs will have block devices (many
will
> likely be using 9p heavily).  We'd like to continue to use kinit for
> this purpose, though at the moment, kinit is processing the root*> flags
as the equivalent of a one-line fstab, though we'd like to also
> mount other mountpoints before execing the "init=" flag.
> 
> Now, I'm wondering if it would make sense to extend the command line
> flags understood by kinit to allow specifying other mountpoints
> (fstype, source, options), or if the right approach is to use a real
> fstab in the initramfs (which can be overlayed by using the kernel's
> overlaying of initramfs trees on top of the built-in initramfs trees).
> 
> I still don't like the fact that kinit may soon be mounting /sys,
> /proc, /dev for the next root image (as this breaks our production
> environment where these are not expected to be mounted by the time the
> init-on-disk).  Maybe having support for an fstab processed by kinit
> would be the best middle ground for this sort of thing?
> 
> Thoughts?
> 
Having an fstab might not be a bad idea for the complex configurations,
and would also add a clean way to mount /sys, /proc, /dev (if you want
them, just put them in the fstab)...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.