[klibc] refactoring do-mounts out of kinit

Mike Waychison mikew at google.com
Thu Jul 28 14:19:12 PDT 2011


On Thu, Jul 28, 2011 at 2:02 PM, maximilian attems <max at stro.at> wrote:
> 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.

Hmm, well, we forked from RH maybe 10 years ago?  We don't have those
checks :\   I can add them if needed, but some other types of mounts
aren't generally appropriate.  We don't use udev for instance, so
mounting on top of /dev for our custom image would prove fatal..

> 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).

Isn't this a bit of a micro-optimization?  I mean, the initramfs is
just memory, how long can it take to nuke?   I'm not against the idea,
I just think its a little heavy weight for what seems to me as
negligible improvement.

>
>> > 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.

It just makes kinit.c implementable as a relatively short script ;)

An alternative is to have kinit support drop directory script
invocation in between root mounting and root switching (like
initramfs-tools init does all over the place).  Thoughts on doing
things that way?



More information about the klibc mailing list