Bugzilla – Bug 1226676
Installation: kdump reports an error if systemd-boot has been selected for bootloader
Last modified: 2024-07-16 08:14:15 UTC
Created attachment 875628 [details] y2log YaST reports an error that the call of mkdumprd has been failed. Calling mkdumprd manually returns: /usr/lib/kdump/kdump-read-config.sh: line 144: /etc/sysconfig/kdump: No such file or directory Kernel not found.
Meanwhile we are informing the user that there is a problem until this bug is fixed: https://github.com/yast/yast-kdump/pull/138
Please don't attach just a lone /var/log/y2log file; you know that we need full y2logs generated with the supplied 'save_y2logs' script. https://en.opensuse.org/openSUSE:Report_a_YaST_bug#I_attached_/var/log/YaST2/y2log_to_a_YaST2_bug,_and_still_I_am_asked_to_attach_y2logs._Why? And from the error messages it appears that 'mkdumprd' (which is part of the 'kdump' package) and the /usr/lib/kdump/kdump-read-config.sh script (also part of the 'kdump' package) that it calls are not robust enough to live without a /etc/sysconfig/kdump file, i.e. it does not have any reasonable defaults.
AFAICS /etc/sysconfig/kdump is generated with some fillup-template. In this case, obviously this does not work. So the first thing to do would be to ensure that there is ALWAYS an /etc/sysconfig/kdump if the kdump package needs it so desperately. I guess this whole thing is also supposed to work when installing an image without the help of YaST, so it should be self-contained with the kdump package always having reasonable defaults.
/etc/sysconfig/kdump is generated from /usr/share/fillup-templates/sysconfig.kdump (owned by package kdump) in the post-install script of kdump. /sbin/mkdumprd is also owned by package kdump. So this is a problem that needs to be handled within the kdump package. YaST is only *reporting* a problem of those underlying tools, not creating it. % osc maintainer -e kdump Defined in package: Kernel:kdump/kdump bugowner of kdump : petr@tesarici.cz, jbohac@suse.com maintainer of kdump : petr@tesarici.cz, jbohac@suse.com Defined in project: Kernel:kdump bugowner of kdump : petr@tesarici.cz maintainer of kdump : tiwai@suse.com, trenn@suse.com, petr@tesarici.cz, jbohac@suse.com, db7532@qq.com, dmair@suse.com, - Defined in project: Kernel bugowner of kdump : - maintainer of kdump : jeffm@suse.com, jslaby@suse.com, msuchanek@suse.com, kernel-bugs@suse.de, -, kernel-maintainers@suse.de (Bugzilla doesn't know petr@tesarici.cz, reassigning to jbohac@suse.com)
*** Bug 1227241 has been marked as a duplicate of this bug. ***
(In reply to Stefan Hundhammer from comment #3) > AFAICS /etc/sysconfig/kdump is generated with some fillup-template. In this > case, obviously this does not work. "obviously" meaning you understand why? Or you just see it didn't? :) Because I don't understand why it does not work. > So the first thing to do would be to > ensure that there is ALWAYS an /etc/sysconfig/kdump if the kdump package > needs it so desperately. It doesn't need it. If it does not exist, it still works, using default values. The error message "/usr/lib/kdump/kdump-read-config.sh: line 144: /etc/sysconfig/kdump: No such file or directory" is misleading and I just fixed it: https://github.com/openSUSE/kdump/commit/0d1cd2c6b21f875d6ad9c6a97df20ff946578455 The real problem is the other error message: "Kernel not found." By deafult kdump expects a /boot/vmlinuz symlink to exist, seems to not be the case here... investigating why.
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. These links have always been created by the kernel's %post scriplet, which calls /usr/lib/module-init-tools/kernel-scriptlets/rpm-post This script used to be provided by the suse-module-tools-scriptlets subpackage. This is where the links are created: https://github.com/openSUSE/suse-module-tools/blob/790fe7ce0eb9db37932c65161d88da73efcb809f/kernel-scriptlets/rpm-script#L183 When I installe with sdboot, sdbootutil-rpm-scriptlets is installed instead of suse-module-tools-scriptlets and no such symlinks are created. 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. 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. Could the links be added to sdbootutil-rpm-scriptlets?
(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).
(In reply to Alberto Planas Dominguez from comment #8) > > 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 canonical but for one loader only? That's not really what I'm looking for. I really like the output of pbl --default-settings Any chance this will work with systemd-boot? On a systemd-boot system it prints: Option --default-settings not available for systemd-boot. I would really like to have a truly universal way to give me a reasonable default kernel without caring which boot loader is being used. Until now this has been /boot/vmlinuz. Is there future in pbl, or something similar that would provide this information?
Btw, kdump also relies on pbl --get-option, --del-option and --add-option to configure FADUMP. This also seems broken with sd-boot. Is this ever going to work?
(In reply to Jiri Bohac from comment #9) > canonical but for one loader only? That's not really what I'm looking for. No, bootctl works for any bootloader that follows the BLS. For example, in Factory the GRUB2 used has patches that make is partially BLS compliant, and sdbootutil is using bootctl to control and query the entries. > I really like the output of > pbl --default-settings > Any chance this will work with systemd-boot? I do not know. I am a bit confused by pbl. The last news that I had was that was dropping perl to use only shell, and that supported systemd-boot. > On a systemd-boot system it prints: Option --default-settings not available > for systemd-boot. > > I would really like to have a truly universal way to give me a reasonable > default kernel without caring which boot loader is being used. Until now > this has been /boot/vmlinuz. Is there future in pbl, or something similar > that would provide this information? I do not know the future of pbl, should the maintainer be involved?
(In reply to Jiri Bohac from comment #10) > Btw, kdump also relies on pbl --get-option, --del-option and --add-option to > configure FADUMP. This also seems broken with sd-boot. Is this ever going to > work? Do you mean that if pbl fully support BLS mkdumprd would not require any update?
(In reply to Alberto Planas Dominguez from comment #12) > Do you mean that if pbl fully support BLS mkdumprd would not require any > update? Currently mkdumprd reads /boot/vmlinuz directly, not through pbl --default-settings. But changing this is easy, I could do that right away. And looking at /usr/lib/bootloader/grub2/default-settings I see it's doing the same thing as mkdumprd does - reads /boot/vmlinuz. pbl --get-option, --del-option and --add-option is used elsewhere in kdump, so this will currently also fail with sd-boot.
Created https://github.com/openSUSE/perl-bootloader/issues/168
(In reply to Jiri Bohac from comment #13) > (In reply to Alberto Planas Dominguez from comment #12) > > Do you mean that if pbl fully support BLS mkdumprd would not require any > > update? > > Currently mkdumprd reads /boot/vmlinuz directly, not through pbl > --default-settings. But changing this is easy, I could do that right away. > And looking at /usr/lib/bootloader/grub2/default-settings I see it's doing > the same thing as mkdumprd does - reads /boot/vmlinuz. > > pbl --get-option, --del-option and --add-option is used elsewhere in kdump, > so this will currently also fail with sd-boot. That is good news then. Completing pbl will simplify the work.
Implemented in kdump-2.0.8: https://github.com/openSUSE/kdump/commit/0e12cea401da5fae68b9456273741ab881a0eda8 So once pbl is updated this should start to work.
> The last news that I had was that was dropping perl to use only shell, and > that supported systemd-boot. perl-Bootloader is using only shell scripts meanwhile. It's just the package name has not been changed (bug 1214361). > On a systemd-boot system it prints: Option --default-settings not available > for systemd-boot. Yes, true. The same is also true for grub2 with BLS patches. I'll implement the missing bits.