This has been going on for a while, but I only just got around to reporting it. During a Fedora Rawhide live install you can see this: 07:54:34,145 INF program: /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh: line 64: new-kernel-pkg: command not found 07:54:34,145 DBG program: Return code: 127 This is triggered by some code in anaconda's live payload which is trying to create rescue images: ==== # Live needs to create the rescue image before bootloader is written if os.path.exists(util.getSysroot() + "/usr/sbin/new-kernel-pkg"): useNKP = True else: log.warning("new-kernel-pkg does not exist - grubby wasn't installed?") useNKP = False for kernel in self.kernelVersionList: log.info("Generating rescue image for %s", kernel) if useNKP: util.execInSysroot("new-kernel-pkg", ["--rpmposttrans", kernel]) else: files = glob.glob(util.getSysroot() + "/etc/kernel/postinst.d/*") srlen = len(util.getSysroot()) files = sorted([f[srlen:] for f in files if os.access(f, os.X_OK)]) for file in files: util.execInSysroot(file, [kernel, "/boot/vmlinuz-%s" % kernel]) ==== Note how it's checking whether new-kernel-pkg exists and using it if it's there, but otherwise calling /etc/kernel/postinst.d/ scripts directly...which then causes a failure anyway because one of them just assumes new-kernel-pkg will be there. :) 51-dracut-rescue-postinst.sh basically looks like this: ==== [[ $dracut_rescue_image != "yes" ]] && exit 0 if [[ ! -f $INITRDFILE ]]; then dracut --no-hostonly -a "rescue" "$INITRDFILE" "$KERNEL_VERSION" ((ret+=$?)) fi if [[ ! -f $NEW_KERNEL_IMAGE ]]; then cp --reflink=auto "$KERNEL_IMAGE" "$NEW_KERNEL_IMAGE" ((ret+=$?)) fi new-kernel-pkg --install "$KERNEL_VERSION" --kernel-image "$NEW_KERNEL_IMAGE" --initrdfile "$INITRDFILE" --banner "$NAME $VERSION_ID Rescue $MACHINE_ID" ==== i.e. it just happily calls new-kernel-pkg, assuming it exists. But since the BLS changes, it commonly won't any more. new-kernel-pkg is now part of grubby-deprecated and not installed by default any more. It seems this script needs updating for the BLS system. I believe the consequence of this is likely that current Rawhide live installs don't have a working rescue kernel.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
Verified in Fedora 31. /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh: line 64: new-kernel-pkg: command not found
It has no sense to support 51-dracut-rescue-postinst.sh when we have BLS-enabled grub. Modern kernel.spec runs /bin/kernel-install to install the kernel in the /boot and the script just executes all the scripts in "/etc/kernel/install.d" and "/usr/lib/kernel/install.d", but the /usr/lib/kernel/install.d/51-dracut-rescue.install also has a bug. When you install a new kernel it doesn't update initramfs-0-rescue-${MACHINE_ID}.img because vmlinuz-0-rescue-${MACHINE_ID} and initramfs-0-rescue-${MACHINE_ID}.img have always the same names. Patch is proposed. https://github.com/dracutdevs/dracut/pull/698
Verified in RHEL 8.1: /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) /boot/vmlinuz-$(uname -r) /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh: line 64: new-kernel-pkg: command not found
I need to refresh the rescue environment. Since /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) /boot/vmlinuz-$(uname -r) does not work anymore and /usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r) /boot /boot/vmlinuz-$(uname -r) ends with cp: cannot stat '/boot/bls.conf': No such file or directory how can I do it? Thanks
(In reply to yuk from comment #6) > I need to refresh the rescue environment. > Since > > /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) > /boot/vmlinuz-$(uname -r) > > does not work anymore and > > /usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r) /boot > /boot/vmlinuz-$(uname -r) > > ends with > > cp: cannot stat '/boot/bls.conf': No such file or directory > > how can I do it? > We probably need to add a command to kernel-install to do this, but it will create a kernel and initrd rescue image if these don't exist when a new kernel is installed. So as a workaround you could do: $ sudo rm /boot/*rescue* $ sudo dnf reinstall kernel-core
FWIW, even with grubby-deprecated installed (which provides /usr/sbin/new-kernel-pkg), the script 51-dracut-rescue-postinst.sh errors out with: $ /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) /boot/vmlinuz-$(uname -r) grubby fatal error: unable to find a suitable template
(In reply to Javier Martinez Canillas from comment #7) [snip] > We probably need to add a command to kernel-install to do this, but it will > create a kernel and initrd rescue image if these don't exist when a new > kernel is installed. > > So as a workaround you could do: > > $ sudo rm /boot/*rescue* > $ sudo dnf reinstall kernel-core Another option is to do the following: $ sudo /usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r) "" /lib/modules/$(uname -r)/vmlinuz But as mentioned I think that users executing /etc/kernel/postinst.d or /usr/lib/kernel/install.d/ scripts directly is not something that should be done but instead kernel-install should have an option to do this.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The bug is still present in rhel 8.2
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug is still alive in RHEL 8.3: [root@rhel8:~]# /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) /boot/vmlinuz-$(uname -r) /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh: line 64: new-kernel-pkg: command not found [root@rhel8:~]# lsb_release -r Release: 8.3 Can you please reopen it against RHEL 8.3 ? Thanks Bye
We don't typically move bugs from Fedora to RHEL, a separate bug should be opened. But yes, this has been pinged around quite a lot, in these commits: https://github.com/dracutdevs/dracut/commit/0bb9a683d4df27427a0ab1d247b6dbb8343d820e - dropped it from master entirely on the basis it was only needed in RHEL and RHEL has branches https://github.com/dracutdevs/dracut/commit/819ea3865161d440353b2f961f3dfeaabeed333d - brought it back with a "FIXME: remove after F30" because F30 needed it https://github.com/dracutdevs/dracut/commit/9e68789d66a6a383e5c46f687350897705c7994f - changed it to only install on Fedora <= 30 or RHEL <= 8 https://github.com/dracutdevs/dracut/commit/9eb1d1ed5ed1eb5008e6173c1ae0480132a4bea4 - changed the conditional so it only installed on RHEL <= 8, never Fedora all those commits are on master; the last two, despite relating to RHEL, were never applied to the RHEL-8 branch. So the RHEL-8 branch is still in the state after 819ea3865161d440353b2f961f3dfeaabeed333d , where it's installed on any Fedora or RHEL install, hence it gets installed. (The downstream package repo specs are always sourced from these upstream branches, AFAICS). I guess I'll send a PR to upstream dracut to cherry-pick those last two changes to the RHEL-8 branch...
https://github.com/dracutdevs/dracut/pull/975 https://github.com/dracutdevs/dracut/pull/976
Which will be the correct procedure to update the rescue environment? We regularly update firmwares and new firmwares sometimes require new kernel modules. So, the old rescue environment becomes useless if not updated as well.
To be honest, I'm afraid I don't know. I tend to do my own rescuing with live images and stuff :P