LWN: Comments on "Dracut looks to replace the initramfs patchwork"

Dracut looks to replace the initramfs patchwork

bobbytables — Tue, 03 Aug 2010 21:24:36 +0000

I was introduced to initramfs-tools when I started building my kernel.org images with kernel-package/make-kpkg (yet another great Debian tool).

It was a breeze for me so I didn't even appreciate how good it is... until I tried to set up my full disk encryption on another distro (a root partition inside a LVM2 container inside a LUKS partition) - it was pain...

Congrats for your work and I'd really like to see an article!

Dracut looks to replace the initramfs patchwork

tack — Wed, 11 Feb 2009 20:55:08 +0000

One more "me too."

I recently got a thorough education on how initramfs-tools works in troubleshooting recent root-over-lvm-over-md problems, and I must say I was very pleased with the design, flexibility, and customizability.

When I later had to deal with Fedora's initrd toolset, I was one very agitated sysadmin.

Dracut looks to replace the initramfs patchwork

apollock — Sun, 08 Feb 2009 22:24:34 +0000

Yes, please do write an article. I'd be happy to help. Having dicked around with Ubuntu's initramfs to customisation purposes, it's really a hidden goldmine of flexibility.

Dracut looks to replace the initramfs patchwork

lbt — Thu, 05 Feb 2009 17:44:28 +0000

Yes please - and don't forget to talk about issues with smaller devices too (eg Nokia N800).

It would be interesting to see 'the right way' to extend initramfs too.

Why not submit it upstream - no-one thinks twice about YAFS so it seems reasonable to have a competing initramfs tool.

Dracut looks to replace the initramfs patchwork

Stephen_Beynon — Thu, 05 Feb 2009 16:32:21 +0000

At the risk of this turning into a 'me too' thread I would also like to see such an
article.

Dracut looks to replace the initramfs patchwork

iabervon — Thu, 05 Feb 2009 16:19:39 +0000

You'll never be able to make a single initramfs image that works for everything, but I don't see any reason that a single initramfs project couldn't have a per-kernel build process that would take a set of instructions on mounting the root filesystem as part of its configuration and generate an initramfs image that does it.

Dracut looks to replace the initramfs patchwork

roblucid — Thu, 05 Feb 2009 14:55:43 +0000

Very interested!

Dracut looks to replace the initramfs patchwork

nix — Thu, 05 Feb 2009 14:22:42 +0000

Indeed. I have systems here that boot normally, systems here that need to
mount LVM, systems that mount LVM-atop-RAID, one bizarre system that has a
root filesystem on RAID-atop-LVM (!), a couple of systems whose RAID
arrays are assembled over the network block device, and one that never
actually mounts a root filesystem atop the rootfs but does all its work
from there.

Booting can be arbitrarily complicated: it must, no matter what, remain
possible to *replace* whatever standardized initramfs framework goes
upstream, because nothing will ever cope with all the utterly bizarre
corner cases.

Req: article on initramfs-tools.

k3ninho — Thu, 05 Feb 2009 09:50:31 +0000

Jeff, thanks for your work on initramfs-tools. I've had to start using it when I moved up to Debian from Ubuntu. I'd love to hear more about it, especially when other comments in this thread describe it as simple elegant and powerful.

K3n.

Dracut looks to replace the initramfs patchwork

climent — Thu, 05 Feb 2009 09:43:18 +0000

Not only every basic feature will have to be implemented in dracut, but also every extended feature (read cryptofs/LUKS) will have to be. For all the distros.

The day that happens we have a replacement. Otherwise, I want to be able to boot from my encrypted partitions when i use my laptop.

Dracut looks to replace the initramfs patchwork

jengelh — Thu, 05 Feb 2009 08:18:25 +0000

That is because initramfs is extracted to the 'rootfs' (some instance of an ramfs), and rootfs is not supposed to be pivoted. Instead, you remove all files and then do a normal chroot. In other words:

$myothercommands;
LD_LIBRARY_PATH=/mnt/lib /mnt/lib64/ld-linux-x86-64.so.2 /mnt/bin/rm -Rf /$everythingButMnt;
exec /mnt/lib64/ld-linux-x86-64.so.2 --library-path "/mnt/lib:/mnt/usr/lib" /mnt/usr/bin/chroot /mnt /sbin/init "$@";

something like that. Of course you can wrap that into a nice C program, but if it works without, you'll probably spare the extra binary.

Dracut looks to replace the initramfs patchwork

jake — Thu, 05 Feb 2009 04:36:20 +0000

> Hmm, I wonder if it's worth writing an LWN article on initramfs-tools
> pimping it a little harder? Anyone interested in seeing it?

Not only are we interested in seeing it, we are interested in paying for it :) See the "Write for LWN" link at the top and if you are still interested, let's talk ...

jake

Dracut looks to replace the initramfs patchwork

linuxjacques — Thu, 05 Feb 2009 04:15:53 +0000

I would love to see an initramfs-tools article.

I do embedded and when I hear glibc and bash I think they must be joking.

Dracut looks to replace the initramfs patchwork

jbailey — Thu, 05 Feb 2009 03:36:44 +0000

(obDisclosure: I am the original author and designer of initramfs-tools)

The reason the question keeps coming up about why not reuse the initramfs-
tools code is because by the design of Dracut, it looks like they're trying
to produce the exact same thing that we did, about 3 years after we wrote
that one. Judging by the git tree, it looks like the authors haven't
bothered to look at what existing initramfs' in distros already do.
(Something which I did extensively before writing it. It wasn't like I
*wanted* to do this, just that all of the distros were still using
pivot_root at the time and I'd recently attended a talk at OLS where we
were told this method of booting was going away)

My biggest concerns are things like the authors apparently not being
interested in klibc (initramfs-tools uses that to get a nice small shell
and for embedded cases producing initramfs' that are a fraction the size of
glibc, never mind glibc plus the userspace tools), their use of bashisms,
and the fact that they're starting quite far behind on different boot
scenarios.

Hmm, I wonder if it's worth writing an LWN article on initramfs-tools
pimping it a little harder? Anyone interested in seeing it?

Tks,
Jeff Bailey

Dracut looks to replace the initramfs patchwork

jbailey — Thu, 05 Feb 2009 03:22:22 +0000

pivot_root requires an older-style initrd. It doesn't work with an
initramfs at all.

Dracut looks to replace the initramfs patchwork

me@jasonclinton.com — Thu, 05 Feb 2009 02:54:22 +0000

I'll be surprised if this goes anywhere other than to replace RH's aging, crufty initfs system--so, they need to do the work anyway. I'm glad that they are working on something else--it's a total pain to modify it now.

But, here's why I don't think anyone else will adopt it: I worked for a company a few years ago that built a custom thin-client software stack. I wrote all of the initramfs integration. At the time the project started, I looked around for a nice framework that already existed that I could just reuse so that I didn't have to reinvent the wheel. I evaluated every distro's initramfs generation framework. In short, they all have terrible kludges and assumptions about the host OS and requirements EXCEPT for Debian's initramfs-tools. The design is simple, elegant and completely agnostic. And it works in just about every boot case you can possibly imagine with a fully pluggable boot method system (which we abused liberally).

I think it will take a few years for Dracut or any other solution to reach that level of maturity. And I just don't see any Debian-based system switching to Dracut until its forced on them--because what they have now is so, so nice.

It's a shame that this is yet another Redhat NIH. (And I don't buy the explanation that it was done to encourage adoption. If it's the right technical solution, people will use it.)

Dracut looks to replace the initramfs patchwork

miffe — Thu, 05 Feb 2009 02:07:59 +0000

Hmm, my util-linux already contains a pivot_root, itn't that what the proposed switch_root woudld do?

Or am I missing something?