https://bugzilla.suse.com/show_bug.cgi?id=1226676 https://bugzilla.suse.com/show_bug.cgi?id=1226676#c8 --- Comment #8 from Alberto Planas Dominguez <aplanas@suse.com> --- (In reply to Jiri Bohac from comment #7)

By default kdump relies on the /boot/vmlinuz symlink (or other image name variants on non-x86 archs). This points to the last installeed kernel. When a specific kernel version is requested by setting KDUMP_KERNELVER=xxx then it relies on the /boot/vmlinuz-xxx symlink.

If a BLS-compatible bootloader is used, the kernel now lives in the ESP, a different FAT32 partition that we mount in /boot/efi

When I installe with sdboot, sdbootutil-rpm-scriptlets is installed instead of suse-module-tools-scriptlets and no such symlinks are created.

Yes, the sdbootutil-rpm-scriptlets package is in the process of being removed. All the functionality is merged back unto the suse-module-tools-scriptlets. The chages were submitted to Factory recently, but they are still under review

One way of fixing this would be to create the symlinks in sdbootutil-rpm-scriptlets.

Another way would be for kdump to look for the kernels elsewhere.

I prefer this option. Now suse-module-tools-scriptlets knows about BLS and sdbootutil, that is used to install a new kernel, update initrd and create boot entries. For BLS the responsibility of synchronizing all the boot related stuff is moving into sdbootutil, that under the hood uses the data provided by bootctl, that is the real canonical source of information Ideally mkdumprd should also known about BLS and ask bootctl about the default boot entry, the active one, or the one that correspond to an specific kernel. It will return the information of there it is the kernel, initrd, the cmdline uses and all the information allocated for this entry.

To me the post scriplet seems to be an ideal place to deal with this, without kdump having to embed knowledge of the location of kernel images which could be fragile.

That is the shift of this model. There is no need to use links to represent the current default kernel. There are boot entries that capture this information and a tool to retrieve it (bootctl). -- You are receiving this mail because: You are on the CC list for the bug.