I am not sure I follow your logic here. I don’t think a backup kernel helps with the same situation a fallback initrd helps with.
Like this:
sudo ln -s /dev/null /etc/kernel/install.d/50-dracut-fallback.install
sudo ln -s /dev/null /etc/kernel/install.d/90-loaderentry-fallback.install
Don’t do this. Putting aside the fact that it is bad practice, if you do this way, your fallbacks will return whenever I update the package.
Form my point of view a fallback initramfs has the purpose to give you a bootable system in case something has messed up with your normal initramfs.
I believe that this is not needed if I have several kernel installed. It is highly unlikely that all kernels and their initramfs get corrupted at the same time. I will always have a working kernel / initramfs to boot from.
What am I missing here?
I guess it depends?
The difference between the fallback initrd and the normal one that the fallback includes a generic set of drivers/functionality and the the normal one is produced with a minimal set that only includes the specific drivers it detects are needed for your install.
Common cases where the fallback is useful are:
Of course, if you make sure you don’t update all your kernels at once, you can mitigate that risk by having an, older, working initrd lying around. In my case, with the kernels I use and the frequency I update, it is pretty common for all my installed kernels to get updated at the same time so I keep the fallbacks around.
To be fair, I have never actually had a situation occur where I needed to boot a fallback image.
Can someone confirm if the AMD microcode released today was automatically installed using the dracut method?
I don’t see any changes here
Thank you @dalto for this nice package, this package and dracut has saved me a lot of hassle trying to enable LUKS unlocking with TPM2, it’s much easier to do with dracut.
a suggestion it would be nice to also have dracut detect if we use Unified kernel image which would also be easier to manage and then enable secure boot the EFISTUB generated by dracut can be signed then.
Thanks again
Ehh…I probably need to add a hook for that. I guess microcode updates need to trigger a dracut rebuild.
For now, you can just use that loop to call kernel-install on all your kernels.
dracut output tells you if it included the AMD microcode:
...
dracut: *** Hardlinking files done ***
dracut: *** Generating early-microcode cpio image ***
dracut: *** Constructing AuthenticAMD.bin ***
dracut: *** Store current command line parameters ***
dracut: *** Stripping files ***
dracut: *** Stripping files done ***
dracut: *** Creating image file '/boot/xxxxxxx/5.15.64-1-lts/initrd' ***
dracut: *** Creating initramfs image file '/boot/xxxxxx/5.15.64-1-lts/initrd' done ***
By the way, for AMD you do not need to install the amd-ucode package. The relevant AMD files are all included in the linux-firmware package as well. Not so for intel. Here you need the intel-ucode package.
EDIT:
I guess I missed the point of the question 
initrd updates for firmware updates are not triggered automatically
Thanks for that info, I didn’t know
No problem 
Hmm…does that mean that I should also be rebuilding the initrds when the linux-firmware package gets updated?
After upgrading amd-ucode and linux firmware yesterday, shouldn’t the patch_level=0x0a201016 be different than before? I’m kind of lost here, sorry if this is a stupid question.
I ran the bottom part of the script:
# Run kernel install for all the installed kernels
while read -r kernel; do
kernelversion=$(basename "${kernel%/vmlinuz}")
echo "Installing kernel ${kernelversion}"
kernel-install add ${kernelversion} ${kernel}
done < <(find /usr/lib/modules -maxdepth 2 -type f -name vmlinuz)
But got the same results as before:
set 01 09:56:40 eos kernel: microcode: CPU0: patch_level=0x0a201016
set 01 09:56:40 eos kernel: microcode: CPU1: patch_level=0x0a201016
set 01 09:56:40 eos kernel: microcode: CPU2: patch_level=0x0a201016
set 01 09:56:40 eos kernel: microcode: CPU3: patch_level=0x0a201016
set 01 09:56:40 eos kernel: microcode: CPU4: patch_level=0x0a201016
set 01 09:56:40 eos kernel: microcode: CPU5: patch_level=0x0a201016
set 01 09:56:40 eos kernel: microcode: CPU6: patch_level=0x0a201016
set 01 09:56:40 eos kernel: microcode: CPU7: patch_level=0x0a201016
set 01 09:56:40 eos kernel: microcode: CPU8: patch_level=0x0a201016
set 01 09:56:40 eos kernel: microcode: CPU9: patch_level=0x0a201016
set 01 09:56:40 eos kernel: microcode: CPU10: patch_level=0x0a201016
set 01 09:56:40 eos kernel: microcode: CPU11: patch_level=0x0a201016
set 01 09:56:40 eos kernel: microcode: Microcode Update Driver: v2.2.
@dalto : I want to propose a name change for the script /usr/share/libalpm/scripts/kernel-install in your package. This script is actually calling itself in line #7:
while read -r line; do
version=$(basename "${line%/vmlinuz}")
echo ":: Running kernel-install for kernel $version"
kernel-install $1 "${version}" "${line}"
done
At least at a first glance it is calling itself. At a second glance it is actually calling /usr/bin/kernel-install which is owned by systemd. I find this confusing.
Can you rename your script to a unique name like kernel-install-for-dracut for example?
I can, I will do that when I update the package for the ucode.
Tested the new package kernel-install-for-dracut released today.
sudo pacman -S amd-ucode linux-firmware-whence linux-firmware to test and the hook worked, kernels were reinstalled automatically.
There are several options for me to prevent the creation of the fallback initrd’s. But I am wondering if this option could be incorporated into the kernel-install-for-dracut package.
@dalto:
dracut knows the option dracut_rescue_image="yes|no". Would it be possible that the scripts 50-dracut-fallback.install and 90-loaderentry-fallback.install honor this option and do nothing if dracut_rescue_image=no. Or could you implement your own environment variable which allows to toggle the creation of the initrd-fallbacks on and off?
The dracut rescue image is different than fallback images. That should be able to be toggled on and off independently of the fallback images.
It would be possible to create a config file and then change those scripts to read it. However, systemd itself provides the ability to inhibit those scripts using:
sudo ln -s /dev/null /etc/kernel/install.d/50-dracut-fallback.install
sudo ln -s /dev/null /etc/kernel/install.d/90-loaderentry-fallback.install
That is is the standard way it works and anyone who knows how systemd works would understand it. If I create a config file, it would be a one-off solution. That seems worse to me.
I had this. But this is overwritten with the new files when the package is updated. So this is not sustainable.
I am currently doing NoExtract in /etc/pacman.conf instead:
NoExtract = usr/lib/kernel/install.d/*fallback*
No, that won’t get overwritten.
That is because you are changing the files in /usr instead of the files in /etc
Ouch. Yes indeed. Creating the links in /etc did the trick. Thank you!
FYI
I tried to switch from mkinitcpio to dracut version 056 today.
I noticed it has the issue with my custom udev-rules script:
$ cat /etc/udev/rules.d/90-disable-mouse.rules
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c539", ATTR{../power/wakeup}="disabled"
This script means that it disables my Logitech mouse USB that should not wake up my PC when the PC is in sleep mode. I am very sure that should work with mkinitcpio initramfs, but it does not work with dracut v056 initramfs.
I tried to build dracut-git with the current version v059 from AUR, but it still has the same issue.
I changed a part of the script:
ATTR{../power/wakeup}="disabled"
to
ATTR{power/wakeup}="disabled"
That works with Dracut v059, but not v056. However, journactl log shows harmless annoying error messages: “No such file or directory”.
3-6:1.2: /etc/udev/rules.d/90-disable-mouse.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:06:00.3/usb3/3-6/3-6:1.2/power/wakeup}, ignoring: No such file or directory
3-6:1.0: /etc/udev/rules.d/90-disable-mouse.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:06:00.3/usb3/3-6/3-6:1.0/power/wakeup}, ignoring: No such file or directory
3-6:1.1: /etc/udev/rules.d/90-disable-mouse.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:06:00.3/usb3/3-6/3-6:1.1/power/wakeup}, ignoring: No such file or directory
This is why I need ATTR{../power/wakeup}="disabled" to prevent these error messages.