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