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