For the use case we are talking about here, locally-generated initrds, mkosi-initrd is not intended in the first place. Dracut will remain around for that for the foreseeable future in all distros.
mkosi-initrdâs use case is pre-built initrds, and we already have a solution for that: core-initrd and snapped kernels, as used on FDE desktop images.
mkosi-initrd is used also fully intended to be used for locally built initrds. The image will be customized for local crypttab, cmdline, modules, firmware, but still be built from packages for all the rest. I have documented this some time ago at https://wiki.debian.org/EFIStub#With_mkosi-initrd
I use dracut in ubuntu since 22.04, I never had single problem, it is powerful and easy to config.
I actually installed the dracut binary package, and removed initramfs-tools. I do not want hybrid config. I think it works more stable without initramfs-tools
I asked around; are you using the Rust coreutils instead of the regular one?
If so, GRUBâs packaging isnât quite adapted for it yet. You could either revert to the regular coreutils, or try patching it manually (not recommended).
If you arenât actually using the Rust coreutils, then this is very curious, please explain more.
25.04 releases this Thursday. Upgrade when itâs offered (usually a week or two after release) and try it after youâve upgraded if you want to experiment with it for best results.
It is working, independent to choice of bootloader grub or systemd-boot and persists system upgrades.
initramfs-tools are purged from the system, both dracut-core and dracut are installed.
Felt less painful than making initramfs-tools ignore nvidia modules. I guess Ubuntu 24.10 improved on apt / dpkg integration making the hack of overwriting update-initramfs obsolete.
Ups. Thatâs a bug that my recent dracut upload causes. Can you file a Launchpad bug against dracut? Iâll fix that after the weekend. I should add an autopkgtest for that.
I am going to report is a success. My system I built myself the following specs:
Motherboard: Asus ROG Crosshair X870E
CPU: AMD Ryzen⢠7 9800X3D
Ubuntu: 24.04.3 LTS
Root mount: /dev/mapper/cryptroot on / type btrfs (rw,noatime,compress=zstd:3,ssd,space_cache=v2,commit=120,subvolid=256,subvol=/@)
Success in Kubuntu 24.04 with two LUKS partitions unlocked at boot via cryptab: one root, one mdraid â luks â lvm â ext4.
System: custom desktop OS build (Nvidia RTX4090 GPU, Ryzen 7 5800X CPU)
Root mount:
/dev/mapper/luks-[redacted] on / type ext4 (rw,relatime)
My LUKS setup is peculiar as it involves non-discoverable fido2 keys, which donât play great with initramfs but dracut handles OK!
Details on the LUKS fido2 issue for those interested. initramfs-generated boot asks for the fido2 token even if you already unlocked the password key slot, then refuses to boot without the fido2 key. dracut understands the fido2 cryptsetup options (e.g., fido2-device=auto) which initramfs does not, and only requires a single key slot to be unlocked to proceed.
Not sure if this is expected, but dracut did not include the nice GUI elements initramfs boot has (e.g., motherboard + OS logos w/ LUKS password entry GUI prompt). dracut just gave me plain tty prompts. Hopefully official dracut config for Ubuntu will bring back the aesthetics?
@bdrung I saw that Fedora 44 will have a very interesting feature that modernizes the live media and adds a persistent layer when we write the iso to a USB storage device. This could be achieved thanks to dracut. Here are the details: https://fedoraproject.org/wiki/Changes/ModernizeLiveMedia
My question is: something is already mapped to do the same with Ubuntu, or can I open a bug report so this feature can analyzed and implemented in the future? What do you think?
@fictiontoreality A bunch of work went into the plymouth integration (the GUI part) in Ubuntu 25.10 and later. Ubuntu 25.10 and later should show the password prompt in the GUI.
The Fedora 44 change lives in a separate package and I havenât seen it outside of Fedora. I see no reason why this should be specific to Fedora. IMO the best place for this code is the upstream dracut project.
So in case you are interested and have time for it: You could have a look at the features in dracut and the features of Fedora 44. Come up with a comparison (a quick look indicates that it uses systemd more). Are there new features? Then you could file a feature request against upstream dracut project for adding those improvements. Bonus points for providing test cases that could be added to the test suite.