Problems with Dracut during kernel update

English Install/Boot/Login
1

I configured Dracut to generate uefi image which is saved to /boot/efi/EFI/Linux but during the kernel update Dracut is acting erroneously - it generates the image correctly but saves it as a regular initrd image to /boot/initrd-“linux version”.
If Dracut is started manually after the new kernel is installed, it saves the uefi image in the right place.

Terminal output: https://paste.opensuse.org/28252654

Also, I noticed that kernel purge does not removes the uefi images of old kernel versions from /boot/efi/EFI/Linux even if that kernel was uninstalled.

2

The problem can be seen in the 1st line:

dracut: Executing: /usr/bin/dracut -f /boot/initrd-6.0.0-1-default 6.0.0-1-default

The file name is hardcoded. It should be omitted so that the build scripts would work as intended.

3

And what is your question? There is no single question mark in your posts so it is unclear whether you are asking something or just provide information for others.

4

I want to get some assistance on how to fix this.

5

To fix what? You said you " configured Dracut to generate uefi image which is saved to /boot/efi/EFI/Linux ", but I see nowhere how you did that. How do you suppose anybody can comment on that?

6

I used uefi=yes option

uefi=yes
early_microcode=yes
uefi_secureboot_cert=/etc/secureboot/keys/db/db.pem
uefi_secureboot_key=/etc/secureboot/keys/db/db.key
uefi_stub=/usr/lib/systemd/boot/efi/linuxx64.efi.stub

uefi=“{yes|no}”
Instead of creating an initramfs image, dracut will create an UEFI executable, which can be executed by an UEFI BIOS (default=no). The default output filename is <EFI>/EFI/Linux/linux-$kernel$-<MACHINE_ID>-<BUILD_ID>.efi. <EFI> might be /efi, /boot or /boot/efi depending on where the ESP partition is mounted. The <BUILD_ID> is taken from BUILD_ID in /usr/lib/os-release or if it exists /etc/os-release and is left out, if BUILD_ID is non-existant or empty.

My dracut conf files has no hardcoded names or paths for output files.

7

Fix what? According to your original post

dracut does exactly what you configured it to do. When dracut is called from within SUSE packages or administrative tools it follows SUSE layout and puts kernel and initrd where SUSE intends it. If you want to change that you need to open bug report and provide compelling arguments why SUSE should support and spend time implementing something else. “I want it this way” is insufficient.

One reason for having kernel in /boot is snapshot management. Moving kernel into ESP will require significant redesign of snapshot implementation and it will not be atomic anymore.

Scripts used during kernel (un-)installation are in /usr/lib/module-init-tools/kernel-scriptlets/, so sledgehammer approach is to replace them with your own versions.

kernel purge does not removes the uefi images of old kernel versions from /boot/efi/EFI/Linux

Why do you expect it to do it? SUSE never installed kernels in this location, why should any tool provided by SUSE look there?

8

Why would you do that?

9

The problem is not that specific config but the installation script that instructs dracut to generate image file with a specific name which is not necessary because provided config files will do that anyway.

10

I have a PC with Secure Boot enabled and full disk encryption, it is for security because separate initrd image cannot be signed.

11

In standard SUSE layout initrd is inside encrypted container. You want to move it into filesystem that cannot be encrypted. Whether it will increase security is certainly open to discussion.

12

When uefi option is enabled in dracut, images are saved in /boot/efi which is not encrypted. Only those images are exposed and they are signed, Secure Boot prevents unsigned binaries from executing and TPM is responsible for system integrity (for example to make sure that SB has not been disabled). All of this is ensuring the security of the system.

13

I think this is a bug because when initrd generation is triggered by other packages such as kernel-firmware, the filename is not mentioned and the image is correctly generated.

dracut: Executing: /usr/bin/dracut --kver=6.0.0-1-default -f

14

The bug is when something does not work as intended/designed. SUSE did not design to do what you want so it is not a bug - it is missing feature.

when initrd generation is triggered by other packages such as kernel-firmware, the filename is not mentioned and the image is correctly generated.

Again - “correctly” for you, but it does not mean it is “correct” for maintainers of this script.

Anyway, this is good catch - at the very least two tools from the same package behave inconsistently. Kernel ends up calling weak-modules2 that calls dracut and kernel-firmware ends up calling regenerate-initrd-posttrans which calls dracut (GitHub - openSUSE/suse-module-tools: suse-module-tools scripts). This is certainly a topic for a bug report, so you if you are concerned, submit github issue. But do not forget that one possible outcome of this issue will be making regenerate-initrd-posttrans behave the same as weak-modules2 …