initrd question

Don Dutile ddutile at redhat.com
Sun Mar 1 20:50:24 UTC 2009


Richard W.M. Jones wrote:
> At the moment mkinitrd goes through a big hoo-hah where it tries to
> determine what precise set of kernel modules are needed to mount the
> root filesystem, and no more.
> 
> But I don't understand why we don't just put every possible block
> device driver / LVM / crypto module / etc. into the initrd.  The
> ramdisk is discarded as soon as the root filesystem is mounted, so at
> most we're saving a few kilobytes of disk space.  At the same time,
> mkinitrd is massively more complicated than it really needs to be, and
> initrd images are non-portable between machines[*].
> 

here's one:
	the !@#$%^&* xen-pv driver(s).
        the equally !@#$%^&* xen tools present an xvd & hda to a FV
        guest; xenbus code reads xenstore & (blindly) creates the /dev/xvd[a-?]
        device file, whether used or not, but doesn't get rid of it if it isn't
        hooked up/used.  along comes anaconda, opens such an device, which
        is empty, and anaconda hacks a fur-ball.
        We can go on for a long time why the xen code & tools are all messed
        up, but we have a life, and need to move on....
So, to deal with such problems & further your recommendation, though,
I suggest that mkinitrd make everything *but what it is told to exclude*.
The exclusion list is small; the inclusion (working) list is large.
a --with would override the default exclusion list.

overall, I agree in principal; include the kitchen sink; exclude what
has corner cases that break stuff, or fix the broken cases, instead of
having tools (anaconda) work around all the crazy options / conditions.

- Don

> The particular problem I am encountering is with P2V and V2V
> conversions.  Because typically virtio-blk drivers aren't included, we
> have to take extra steps to run 'mkinitrd --with virtio_pci --with
> virtio_blk'.  Doing this from a script is not just massively
> complicated (we have to run it within the context of a guest
> filesystem probably located inside a raw disk image), but completely
> unnecessary if initrd just included all the drivers in the first
> place.
> 
> Thoughts?
> 
> Rich.
> 
> [*] They would still hard-code the root and swap partition names, but
> I think it should be possible to get rid of those too and make initrd
> images really portable.
> 




More information about the fedora-devel-list mailing list