Dear Maintainer,
thanks for maintaining dracut for Debian and thanks for the extra
effort of migrating to the dracut-ng upstream! Here is probably
a follow-up issue caused by that ...
* What led up to the situation?
Installation of dracut-ng-based dracut package 102-3.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Called my usual "dracut --quiet --force --regenerate-all" command
to manually regenerate dracut initramfs/initrd images after a
configuration change.
* What was the outcome of this action?
Files being generated with names "initramfs-*-amd64.img" and not, as
previously "initrd.img-*-amd64":
------------------------- snip -------------------------
[~]$ ls -al /boot/
[...]
-rw------- 1 root root 28477336 Jun 19 12:08 initramfs-6.6.15-amd64.img
-rw------- 1 root root 28742400 Jun 19 12:08 initramfs-6.7.12-amd64.img
-rw------- 1 root root 28742715 Jun 18 11:07 initrd-fallback.img-6.7.12-amd64
-rw-r--r-- 1 root root 28477398 Jun 18 11:07 initrd.img-6.6.15-amd64
-rw------- 1 root root 28742715 Jun 18 11:07 initrd.img-6.7.12-amd64
[...]
------------------------- snip -------------------------
In above listing, you can nicely see the difference: The files generated
on "Jun 18" have been created by the dracut post-install hooks, the
files generated on "Jun 19" manually.
* What outcome did you expect instead?
I would have expected that a plain
sudo dracut --quiet --force --regenerate-all
would create the same files as the dracut post-install hooks.
My dracut configuration, nothing spectacular:
------------------------- snip -------------------------
[~]$ cat /etc/dracut.conf
hostonly="yes"
add_drivers+=" i915 "
omit_dracutmodules+=" i18n "
# avoid warnings because of dependencies on uninstallable
# tpm2-tss
omit_dracutmodules+=" systemd-pcrphase "
[~]$ ls -al /etc/dracut.conf.d/
total 16
drwxr-xr-x 2 root root 4096 Dec 8 2023 .
drwxr-xr-x 131 root root 12288 Jun 19 12:08 ..
------------------------- snip -------------------------
I rembember there was a discussion about the initrd name and the plan
was to have the same name on all distributions, and there's a new
option in dracut.conf
*initrdname=*"_<filepattern>_"::
Specifies the file name for the generated initramfs if it is not set otherwise.
The initrdname configuration option is required to match the _initr*${kernel}*_
file pattern and only one file with this pattern should exists in the
directory where initramfs is loaded from. Defaults to _initramfs-${kernel}.img_.
But I don't remebmer the details about the change.
It seems that dracut uses initramfs... by default but Debian is using
initrd... when calling /etc/kernel/postinst.d/dracut
So if you still using the kernel postinst hook, things are fine IMO.
Thanks for your prompt response!
That's reasonable, but regardless of what the "standard" initrd
name is or will be, probably *both* manual dracut and
post-install hooks should use the same standard name, then. Plus
GRUB should pick up that new name. (I haven't checked whether
update-grub picks up the initramfs-*.img names.)
The "initrdname" option does not seem to be suitable for the
"--regenerate-all" use-case since it does not allow for the
kernel version to be templatized (from /usr/bin/dracut):
if ! [[ $initrdname ]]; then
initrdname="initramfs-${kernel}.img"
fi
[...]
else
outfile="$dracutsysrootdir/boot/$initrdname"
fi
My experiments with 'initrdname="initrd.img"' confirm that:
------------------------- snip -------------------------
[~]$ cat /etc/dracut.conf
[...]
initrdname="initrd.img"
[~]$ sudo dracut --quiet --force --regenerate-all
[~]$ ll -tr /boot
[...]
-rw------- 1 root root 28742715 Jun 18 11:07 initrd-fallback.img-6.7.12-amd64
-rw------- 1 root root 28477336 Jun 19 12:08 initramfs-6.6.15-amd64.img
-rw------- 1 root root 28742400 Jun 19 12:08 initramfs-6.7.12-amd64.img
-rw-r--r-- 1 root root 28538617 Jun 19 13:48 initrd.img-6.6.15-amd64
-rw------- 1 root root 28804327 Jun 19 13:48 initrd.img-6.7.12-amd64
drwxr-xr-x 5 root root 4096 Jun 19 13:58 .
-rw------- 1 root root 28804621 Jun 19 13:58 initrd.img
------------------------- snip -------------------------
I dug a bit deeper into this, and for dracut <= 60 there was
patch debian/patches/initrd-not-initramfs.patch. More
specifically:
dracut (059-4) unstable; urgency=low
* Fix file name in patch initrd-not-initramfs.patch
Closes: #1029413, #1030191
Thanks to nabijaczleweli for for the patch
Not sure what you mean here. That I call the kernel postinst
hook manually to regenerate the initramfs's?
If yes, using the kernel postinst hook manually has the minor
disadvantage that you have to loop over the installed kernels to
cover all of them, while "dracut --regenerate-all", well, does
*all* kernels out of the box.
Thanks
Jens
Yes, the initrd-not-initramfs.patch was removed because upstream developer said it's not needed any more. The kernel postinst hook is /etc/kernel/postinst.d/dracut I use # dpkg-reconfigure dracut to recreate the initrd for all kernels.
Hello ! From the description of the upstream PR - https://github.com/dracut-ng/dracut-ng/pull/160 Would the following work ? If it does it should be probably added to the Debian package config. Laszlo
Nice, thanks. That suits my needs. I still feel the inconsistency between manual "dracut --regenerate-all" and post-install hooks itching, but now less so. So feel free to do with this bug what you think is right.
You mean as a value in /etc/{dracut.conf|dracut.conf.d/*}?
I haven't tested it, because I thought that the dracut script does
not evaluate the value (as far as I can see from the sources). But
OTOH dracut *sources* the configuration files, so this might
actually work. Of course only if dracut sources them per kernel
version.
I could test it, but only on Monday ...
Hello
I can confirm this works but the correct value to match postinst.d is:
initrdname="initrd.img-${kernel}"
The Debian package should probably ship this as the default
configuration under /usr/lib/dracut//as long as Debian is using
this convention.
Regards,
Simon
Hi, It'd probably be good to decouple a transition to dracut from a transition of that well-known name. IMO we should think this from the intended user experience. In its current state dracut is incredibly confusing in Debian testing and unstable. It generates files that do not match what's falling out of the kernel postinst by default. You need to pass it a target filename that does not match the pattern and the intended kernel version. --regenerate-all generates new files that will not be used. At the very least we should put the name patch back in. That being said I think there's a more general question here about what the user interface should be. Admins are accustomed to run "update-initramfs -u -k all" or for a specific version. Maybe dracut should divert the tool, given that the interface is so generic and not plumbing, like dracut itself is? Do we expect everyone to move over to dracut invocations instead? It looks like the intended interface as per dracut is: # All versions dracut --regenerate-all # Specific version dracut --kver <version> Both of which are currently broken due to this bug. Kind regards and thanks Philipp Kern
Hi, one additional point to consider against using initrd/initramfs path argument in kernel hooks. On my system I have set up dracut to generate UKIs using uefi option: $ cat /etc/dracut.conf.d/99-uefi.conf uefi=yes With the option set and output filename not specified, dracut generates UKIs and places them in /boot/efi/EFI/Linux But if the output filename is set resulting kernel images overwrite initrd/initramfs files, which is confusing and lead to broken boot: $ sudo apt install --reinstall linux-image-6.11.10-amd64 ... /etc/kernel/postinst.d/dracut: dracut: Generating /boot/initrd.img-6.11.10-amd64 ... $ file /boot/initrd.img-6.11.10-amd64 /boot/initrd.img-6.11.10-amd64: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows, 9 sections Please consider avoiding explicitly specified initrd/initramfs filenames in kernel hooks. Best, Roman