Subject: Re: Dracut -- Cross distribution initramfs infrastructure

From: Christoph Hellwig <[email-masked]>
Date: Wed, 17 Dec 2008 14:07:01 -0500

On Wed, Dec 17, 2008 at 01:54:54PM -0500, Jeremy Katz wrote:
> As davej started talking about a few months ago at Kernel Summit and
> LPC, there's a lot of duplication between distros on the tools used to
> generate the initramfs as well as the contents and how the initramfs
> works.  Ultimately, there's little reason for this not to be something
> that is shared and worked on by everyone.  Added to this is the fact
> that everyone's infrastructures for this have grown up over a long-ish
> period of time without significant amounts of reworking for the way that
> the kernel and early boot works these days.
> 
> Therefore I've started on a new project, dracut, to try to be a new
> initramfs tool that can be used across various distributions.  From the
> README...

It looks like Hannes has also been working on a new, modular initramfs
for a while:

	http://git.kernel.org/?p=linux/kernel/git/hare/mkinitrd.git;a=summary

I hope you guys can get together and agree on one implementation..
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to [email-masked]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

---

From: Jeremy Katz <[email-masked]>
Date: Wed, 17 Dec 2008 13:54:54 -0500

Unlike existing initramfs's, this is an attempt at having as little as
possible hard-coded into the initramfs as possible.  The initramfs has
(basically) one purpose in life -- getting the rootfs mounted so that we
can transition to the real rootfs.  This is all driven off of device
availability.  Therefore, instead of scripts hard-coded to do various
things, we depend on udev to create device nodes for us and then when we
have the rootfs's device node, we mount and carry on. This helps to keep
the time required in the initramfs as little as possible so that things
like a 5 second boot aren't made impossible as a result of the very
existence of an initramfs.  It's likely that we'll grow some hooks for
running arbitrary commands in the flow of the script, but it's worth
trying to resist the urge as much as we can as hooks are guaranteed to
be the path to slow-down.

Also, there is an attempt to keep things as distribution-agnostic as
possible.  Every distribution has their own tool here and it's not
something which is really interesting to have separate across them. So
contributions to help decrease the distro-dependencies are welcome.

The git tree can be found at git://fedorapeople.org/~katzj/dracut.git
for now.  See the TODO file for things which still need to be done and
HACKING for some instructions on how to get started using the tool.
There is also a mailing list that is being used for the discussion --
[email-masked].  

Currently, there are a few Fedora-isms which have crept in just as a
result of it being the shortest path to solving some problems, but I'm
actively trying to get those out sooner rather than later as well as
getting to where I'm using it to boot my laptop.

Comments and discussion welcome

Jeremy

---

From: Neil Horman <[email-masked]>
Date: Wed, 17 Dec 2008 14:31:51 -0500

> Comments and discussion welcome

Not that I don't think a unifying tool to create an initramfs is a bad idea
(quite the contrary, I think it would be great), but I'd like to point out that
one of your underlying premises is a bit shaky.  That an initramfs has one
purpose, that being to get the rootfs mounted, isn't entirely accurate.  Kdump
and various embedded systems being the prime examples here.  Many embedded
systems run entirely out of the initramfs, and contain all the code they need to
do so in them.  Additionally, kdump in most environments, attemps to capture
core files entirely from the initramfs as well, operating under the assumption
that the rootfs may not be functioning properly after a crash.  By and large
these initramfs images tend to be larger and offer a more typical (if not
standard) user operating environment.  I'm looking at your tree now, and it
looks like a good start on standardizing the initramfs for the nominal case.  Do
you have plans to include (or are you interested in including) support for
alternate infrastructure (like busybox instead of nash), interactive setup, etc?

Regards
Neil
 
-- 
/****************************************************
 * Neil Horman <[email-masked]>
 * Software Engineer, Red Hat
 ****************************************************/
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to [email-masked]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

---

From: Jeremy Katz <[email-masked]>
Date: Wed, 17 Dec 2008 14:48:29 -0500

(Removing lkml from the cc)

On Wed, 2008-12-17 at 14:31 -0500, Neil Horman wrote:
> standard) user operating environment.  

While I'd like to think that embedded systems are not going to do
something custom, you, I and everyone else know that's unlikely. ;-)

The kdump case is one that I think is at least reasonable to get to
eventually (and also, installer initramfsen), but I think that getting
the cases of "initramfs for booting a system" consolidated first makes
the most sense.  

> I'm looking at your tree now, and it

Well, the use of nash right now is due to the fact that there isn't
historically any switchroot utility shipped in util-linux.  Hopefully
we'll get something there and then the only user of nash that's there
right now can go away.  

busybox, etc are really all just extra pain as compared to using real
system utilities... once you accept that you're dynamically linked,
you're better off just maintaining one set of the utilities as opposed
to having one set in coreutils and one set in busybox.

Jeremy

---

From: Neil Horman <[email-masked]>
Date: Wed, 17 Dec 2008 15:17:43 -0500

> something custom, you, I and everyone else know that's unlikely. ;-)
Agreed :)

> the cases of "initramfs for booting a system" consolidated first makes
Absolutely, thats fine with me.  I just didn't want everyone to assume that
getting to the rootfs was the only thing that initramfs' did.  Adding kdump
support later is well and good. 

> we'll get something there and then the only user of nash that's there
Thats true, and a small part of the reason that most kdump implementations use
busybox.

> to having one set in coreutils and one set in busybox.
I'm not so sure I agree with that, but I'll not turn this thread into that
argument :).  Suffice it to say, That if we can cram ifconfig, sed, awk, lsmod,
modprobe, bash, cp, grep, reboot, halt, ps, kill, and pivot_root and a few other
utils into less than 1.8MB of space, switching might be worthwhile.

Neil

---

From: "Kay Sievers" <[email-masked]>
Date: Wed, 17 Dec 2008 21:29:51 +0100

> the cases of "initramfs for booting a system" consolidated first makes

Maybe Bernhard Walle, who currently maintains the SUSE initramfs, can
possibly take care of that. He's is working on kdump stuff.

> we'll get something there and then the only user of nash that's there

SUSE uses a small binary run-init copied from klibc:
  http://git.kernel.org/?p=libs/klibc/klibc.git;a=blob;f=usr/kinit/run-init/run-init.c;hb=HEAD
 Maybe it's time to add something like that to util-linux? Karel?

> to having one set in coreutils and one set in busybox.

Busybox is nice as an option to be able to rescue/hack. It should
definitely be provided as an optional "plugin" for people who need it.
But there is no chance to depend on it by default, for the very same
reason klibc, or any other libc is not an option.

Full-featured distros who make their money with support, can just not
afford to support tools compiled differently from the tools in the
real rootfs. SUSE used klibc for one release, and stopped doing that
immediately, because you go crazy if you run into problems with bootup
problems on cutomer setups you can not reproduce with the tools from
the real rootfs.

We need to use tools in initramfs which will not work realibly, or not
at all, with other libcs. We will have one dynamic glibc there anyway,
so there is no valid reason to also use any single statically linked
binary, or any other libc by default. Really, it's just nice to use
the same environment in the real root and in initramfs, and you also
get the smallest possible size that way, if you need to include only a
single "advanced" tool.

Thanks,
Kay

---

From: Neil Horman <[email-masked]>
Date: Wed, 17 Dec 2008 16:06:45 -0500

> possibly take care of that. He's is working on kdump stuff.
I do to, thats why I brought it up :)

> problems on cutomer setups you can not reproduce with the tools from
This is all hyperbolie.  Yes, its nice to be able to use the same tools and the
same environment, but busybox works perfectly well in a kdump environment.  I've
used busybox in Fedora and RHEL, and since RHEL5 and FC-6 shipped, I've
encounted I think 3 bugs that dealt with minor differences in how busybox worked
from the rootfs tools

> get the smallest possible size that way, if you need to include only a
busybox is dynamically linked now too, so C library issues are irrelevant at
this point.  And busybox provides, at my last count 255 utilities in the Fedora
build.  Compare that to the cumulative size of all the corresponding individual
utilities and see who comes out taking up less space.

Neil

---

From: David Zeuthen <[email-masked]>
Date: Wed, 17 Dec 2008 16:15:07 -0500

On Wed, 2008-12-17 at 16:06 -0500, Neil Horman wrote:
> This is all hyperbolie.  

Hardly. Having to support two different C libraries in a real production
environment, for reasons like "just because we can" and "it's about
freedom" is not something I ever want this project to see or support. In
there lies madness.

FWIW, as Kay said, it's fine to have an unsupported "--with-busybox" or
whatever option but please don't think that people using it can expect
any kind of real support or attention to their bug reports.

     David

---

From: Neil Horman <[email-masked]>
Date: Wed, 17 Dec 2008 16:22:50 -0500

> freedom" is not something I ever want this project to see or support. In
Either I wasn't clear, or you didn't read closely enough.  I don't use two
different c libraries, We use the same C library everywhere, busybox included.
Which is not to say you have to do that.  You can certainly use a different
library, and I agree with you there, to use two different C libraries in the
same system is rather insane.  But I don't do that, and unless you are _that_
constrained for space, you don't need to.

> any kind of real support or attention to their bug reports.
Seea above.