[klibc] refactoring do-mounts out of kinit

[Mike Waychison]

On Thu, Jul 28, 2011 at 12:18 PM, maximilian attems <max at stro.at> wrote:
>
> On Thu, Jul 28, 2011 at 10:43:04AM -0700, Mike Waychison wrote:
>> So, today, I'm using kinit from our initramfs to handle early boot up
>> sequence.   Our init is actually a shell script that does a some setup
>> stuff (plugging values into appropriate proc files mostly), and the
>> script currently passes on to kinit by finishing with "exec /kinit
>> "$@"".
>>
>> I have a situation now though, where due to some ubuntu weirdness, I
>> seem to need to do stuff between the mounting of the root filesystem,
>> and pivoting into it.   Things I think need to happen include mounting
>> a tmpfs on to next root's /dev, mounting /proc, and mounting /sys.
>> Usually, this happens within the initrd built by the distro, but I'd
>> like to avoid having a separate initrd (as it is much easier for us to
>> build an initramfs as part of the kernel compile that *just works* for
>> all the boot environments we care about).
>
> 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.

>
>> For the moment, it *seems* that the requirement is to just add a bunch
>> of mountpoints, but I'm tempted to "fix" my problem by refactoring
>> some of kinit.
>>
>> Currently, kinit is already setup as not much more than a wrapper that
>> ties together the following components of the early boot up sequence:
>>
>>  - ipconfig
>>  - nfsmount
>
> historical additions to klibc.
>
>>  - resume
>
> needed it in initramfs-tools, so refactored aka separated it.
>
>>  - run-init
>
> was separate from day 0.
>
>> The filesystem detection bits are also available as 'fstype'.
>
> right.
>
>> The only thing needed to be split out in the build that would enable
>> me to replace kinit with shell scripting calls to the components it is
>> comprised of (allowing me to write setup stuff between the steps of
>> the boot) is the actual step that does the handling of root=.
>
> 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().

>
>> I've taken a couple stabs locally of refactoring do-mounts out into a
>> sub directory at usr/kinit/do-mounts, but that doesn't play very well
>> with KBuild, as it needs to depend on portions of ipconfig and
>> nfsmount, which are in sibling directories (and this confuses KBuild
>> when doing parallel builds).
>>
>> The alternative I think is to refactor it a bit so that do-mounts code
>> stays where it is, but a new binary target is created next to the
>> kinit binary.
>
> I have been the road of sh scripting and it's not pretty, see
> dracut or initramfs-tools each.
> having the thing in c like kinit is much better, so currently
> I'm working on improving klibc support of early userspace
> (module-init-tools, udev, mdadm, lvm2, cryptsetup, ..)
> and enhancing the klibc utilities themself to have less shell scripting
> in initramfs-tools, which I maintain for Debian and also Ubuntu.

Ya, shell scripting isn't always the best way to do things.  That said
though, breaking out the C implementation bits apart sufficiently such
that they are available for custom invocation from shell is quite nice
;)

>
>> Questions:
>>
>> - Does my approach make sense?
>> - Anyone have any reasons I shouldn't go ahead with this refactor?
>
> Quite sure the first stated reason is not worth it, but there were allways
> people asking for extensions of kinit, so I'm happy to gather input.
>
> --
> maks
>