[klibc] refactoring do-mounts out of kinit

[maximilian attems]

On Thu, Jul 28, 2011 at 01:34:22PM -0700, Mike Waychison wrote:
> On Thu, Jul 28, 2011 at 12:18 PM, maximilian attems <max at stro.at> wrote:
<snipp>
> > It is my plan to enhance run-init or switch_root (I don't mind much how it
> > is called. my personal pref is for the first, but people seem to have
> > settled for the fugly underline cmd). It should just move mount things
> > including /dev, /proc, /sys and maybe /run.
> > It is currently stupid to unmount for having init to remount them.
> > So kinit should just be fine with there. See
> > http://www.zytor.com/pipermail/klibc/2011-July/002988.html
> > which by itself seems still good to me (the switch_root relaxing got
> > nacked by hpa and I tend to agree with him on second thought).
> 
> So, it looks like your patch moves the mountpoints, (which would
> probably solve my issue when booting ubuntu disks), but I don't think
> it's appropriate to _always_ do this.   Most of our systems boot root
> disks that _do not_ expect those guys to be mounted, and they are
> handled by the /etc/rc.d/rc.sysinit on the disk image itself.

It would be a big bug of /etc/rc.d/rc.sysinit not to handle that.
not beeing a RH guy, have only one cluster at hand and there it
seems to check for the existence of /proc/mounts before mounting
/proc and /sys.

It is a legitimate boot order optimisation and move mounts are as
old as 2.5.1. I remember gaining some time in initramfs-tools for
move mounting and not unmounting in boot speed.

The other optimisation I want for run-init is to fork and
nuke the initramfs *after* the init call in bg (have it in my local
branch).
 
> > not sure what you want to separate out?
> 
> Specifically, the bits that do the mounting of the real root [aka:
> do_mounts()].  I have a patch that seems to do the trick though I
> haven't tested it much yet (will send in reply).
> 
> In initramfs-tools, I think this is the near equivalent to all the
> logic in scripts/local:mountroot() and parse_numeric().

will comment next days on the patch by itself.
haven't yet had time to review the hardening patch,
but I like the intention of that one.

This split seems complicated and axing totally kinit.
 
-- 
maks