Re: initrd question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
> 

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux