Hi, this is an ebuild for Dracut and patches to make it work on Gentoo. Dracut is a new cross-platform initramfs generation tool developed by Red Hat. Like sys-kernel/genkernel, it generates an initramfs which is used during boot to mount the root filesystem. Since genkernel is ancient and unmaintained, and there isn't any other package for generating an initramfs, I've ported Dracut to Gentoo. Some advantages over genkernel's initramfs: - uses udev to load drivers only for detected hardware - can boot from USB mass storage devices without mount delay hacks - runs much faster This ebuild hasn't been thourogly tested. I've tested booting from SATA disks and USB mass storage devies, and resuming from hibernation. I've added dependencies for additional features (LVM, disk encryption, NFS), however I don't have the resources to verify that they work. I would appreciate it if someone could test these.
Created attachment 198591 [details, diff] patch to allow installing to desired folders
Created attachment 198592 [details, diff] patch to unmount pseudo filesystems instead of remounting them Dracut will attempt to mount-move /dev, /proc and /sys to the new root filesystem. Gentoo init scripts however do not expect this and will fail. This patch makes the initramfs unmount these folders instead.
Created attachment 198593 [details] config file template
Created attachment 198599 [details] ebuild
Genkernel is ancient and unmaintained? Where did you get this idea?
(In reply to comment #5) > Genkernel is ancient and unmaintained? Where did you get this idea? > I didn't mean to insult anyone, but: - it loads all the drivers in the initrd and waste system memory even though it is possible to load only the needed ones (it has been for years), and it spends a lot of time doing this - it ships with a kernel config for kernel version 2.6.24 - I had some difficulties getting in patches as developers were "busy on other things" Dracut is being actively developed and it will for sure get more stable and get new features, so why not allow users use it as an alternative?
Created attachment 199238 [details] ebuild Update to version 0.7. Changes: - require >=sys-apps/module-init-tools-3.6, otherwise we get no kernel modules - require net-misc/bridge-utils for NFS - add md USE flag for kernel md devices (software RAID) - add dmraid USE flag
Created attachment 199240 [details, diff] patch to allow installing to desired folders
Created attachment 199241 [details, diff] patch to unmount pseudo filesystems instead of remounting them
On amd64 multilib Gentoo, /lib is a symlink to /lib64, and dracut creates duplicate files in /lib and /lib64 in a resulting cpio image. Other files are missing in /lib64 but exists in /lib in that image. So /usr/sbin/lvm fails to run from initrd due to missing libraries. A possible solution is to create in the initrd the same /lib symlink as in host system, if /lib is a symlink.
Created attachment 199361 [details, diff] proposed patch to fix files duplication when /lib is a symlink
(In reply to comment #10) > On amd64 multilib Gentoo, /lib is a symlink to /lib64, and dracut creates > duplicate files in /lib and /lib64 in a resulting cpio image. Other files are > missing in /lib64 but exists in /lib in that image. So /usr/sbin/lvm fails to > run from initrd due to missing libraries. > A possible solution is to create in the initrd the same /lib symlink as in host > system, if /lib is a symlink. > Thanks you for reporting the problem. I have however found a more general solution. Could you please try the attached patch?
Created attachment 199388 [details, diff] take into account directory symlinks on the host system
Created attachment 199389 [details] ebuild dir symlink patch added
Created attachment 205377 [details] update ebuild to version 002
Created attachment 205378 [details, diff] update dir symlinks patch to version 002
I've created an ebuild based on your initial ebuild with some enhancements. I don't have it in the tree yet, but you can check my overlay out on github [1]. I've made a few changes based from the the upstream spec file. Some of major points are: * Switched all the network related use flags to a unified "network" useflag too follow upstream's installation. Granted, it would be nice not to require all the network packages if you only needed one, however upstream seems to do all or none as well and I didn't want to deal with strange bugs. It also simplified the ebuild considerably. * Remove any module we don't have enabled via a useflag * Add more DEPENDS based from the spec file included from upstream * Create /boot/dracut & /var/lib/dracut/overlay per their spec file * Create a dracut-version file per upstream spec file * Remove the template config file and assume the user will add the modules manually My intention was to try and follow what upstream did as closely as we could. Have you tried submitting patches upstream for the three you created? It would be ideal to have these fixes upstream, especially if they are needed for other distributions. Please test my ebuild and let me know if you have any issues. I'll see about getting this into the tree within the next week. Thanks! [1] http://github.com/ramereth/ramereth-overlay/tree/master/sys-kernel/dracut/
(In reply to comment #17) > * Switched all the network related use flags to a unified "network" useflag > too follow upstream's installation. Granted, it would be nice not to > require all the network packages if you only needed one, however upstream > seems to do all or none as well and I didn't want to deal with strange > bugs. It also simplified the ebuild considerably. After some more thought, I decided to switch this back to a useflag for each network based option. That way people don't have to pull everything thing in. I just pushed the change to my repo.
Works fine here. > * Remove the template config file and assume the user will add the modules > manually I don't thing this is a good idea. It is non-obvious to the user that additional configuration is required to use optional features besides enabling the use flags. Additionally, the names of the modules are not even mentioned in the dracut man page, only module-specific kernel command line options. If you insist on that, please at least mention it in the note at the bottom of the ebuild, and make it say which use flags require which modules. Thank you for taking care of this ebuild!
(In reply to comment #19) > Works fine here. > > > * Remove the template config file and assume the user will add the modules > > manually > I don't thing this is a good idea. It is non-obvious to the user that > additional configuration is required to use optional features besides > enabling the use flags. Additionally, the names of the modules are not even > mentioned in the dracut man page, only module-specific kernel command line > options. If you insist on that, please at least mention it in the note at > the bottom of the ebuild, and make it say which use flags require which > modules. Good point, I'll add something to the bottom of the ebuild so that they notice it more. > Thank you for taking care of this ebuild! No problem, thank you for submitting the patches and ebuild!
New ebuild committed to the tree. Added two more patches for dracut-gencmdline fixes. Thanks for the initial ebuild and patches!
