ITP for yaird, yet another mkinitrd
This is to draw attention to the ITP for yaird,
Yet Another mkInitRD, http://bugs.debian.org/315298
Jonas Smedegaard will be Debian maintainer.
If you see anything in this message that could get
in the way of the kernel distribution process,
this is a good time to speak up.
Technically, it's a generator for initial boot images
(initrd or initramfs), written in perl, that uses sysfs
to analyse which modules are needed to boot the system,
and that uses templates to achieve maximum flexibility
in the generated images; you could also see it as
a massively over-engineered bugfix for #284294.
It supports SATA, IDE, LVM2, mdadm, cryptsetup,
cryptsetup-luks, USB keyboards, NFS root. Perhaps
it supports SCSI and USB storage (the code is there,
but no test reports for actual hardware). It does not
yet support EVMS, swsusp, firewire, DASD, loopback,
loopaes, dmraid.
Integration with kernel distribution is simple: there
is a wrapper, mkinitrd.yaird, that can be invoked at
kernel install time using the "ramdisk=" option in
recent kernel packages. No diversions, no update-alternatives.
There are important differences with Jeff Bailey's
work on mkinitramfs, also scheduled to go into unstable,
(Jeff, please correct me if I'm oversimplifying):
- Jeff puts everything on the image and lets udev
decide at boot time what's needed; I do the analysis
at image build time. The consequence is that my
images can be smaller, and his images are more resistant
to hardware changes.
- Jeff works in shell, I work in perl. His code is smaller
and thus easier to dive into, mine has more error checking
and should be able to cope with more complexity before
degrading into spaghetti.
We are aware of each others work and willing to share ideas
and implementations where that makes sense.
A note about the future: yaird is not finished. It boots this PC just
fine, but there's room for improvement, in particular in the following
areas:
- The templates give flexibility at the lowest level,
enough to tune the package for Debian or Fedora, but at a higher
level more flexibility is needed. As an example, it should be easy
to omit keyboard support for headless systems.
- The tools on the initramfs are not tuned for maximum efficiency.
As an example vgchange as found on the root file system is used,
which sucks in glibc, which greatly increases the size of the image.
- A number of features -- evms, swsusp -- are not yet supported.
Working on that now ...
Regards,
Erik
Reply to: