Description of problem: I started using Fedora 30 with a pre-release weekly build witch an RC Kernel. Know that Fedora 30 matured a lot I wanted to replace my rescue image so it will use a stable 5.0.5 kernel. Do do that I deleted the vmlinuz and initramfs of the rescue and tried to rengenerate them. The files get generated but one cannot boot the rescue successfully Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. sudo rm -f /boot/vmlinuz-0-rescue-* /boot/initramfs-0-rescue-*.img 2. sudo /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) /boot/vmlinuz-$(uname -r) which yields to "new-kernel-pkg: command not found 3. sudo new-kernel-pkg which yields to bash: new-kernel-pkg: command not found... Install package 'grubby-deprecated' to provide command 'new-kernel-pkg'? Actual results: the rescue is not bootable Expected results: Additional info: The following Link might be useful: https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
(In reply to relentless.1980 from comment #0) > Description of problem: > I started using Fedora 30 with a pre-release weekly build witch an RC > Kernel. Know that Fedora 30 matured a lot I wanted to replace my rescue > image so it will use a stable 5.0.5 kernel. Do do that I deleted the vmlinuz > and initramfs of the rescue and tried to rengenerate them. The files get > generated but one cannot boot the rescue successfully > > > Version-Release number of selected component (if applicable): > > > How reproducible: > > > Steps to Reproduce: > 1. sudo rm -f /boot/vmlinuz-0-rescue-* /boot/initramfs-0-rescue-*.img > > 2. sudo /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) > /boot/vmlinuz-$(uname -r) > > which yields to "new-kernel-pkg: command not found > Yes, that's a bug. In the meantime you can re-generate your rescue initramfs with: $ kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz
(In reply to Javier Martinez Canillas from comment #1) > Yes, that's a bug. In the meantime you can re-generate your rescue initramfs > with: > > $ kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz Thanks for the fast reply. But the rescue initramfs and vmlinuz are re-generated via the 51-dracut-rescue-postinst.sh script successfully as I can see them in /boot/. But if I select the rescue option in grub2 during boot I get the following erros: error: ../../grub-core/fs/fshelp.c:257:file 'vmlinuz-0-rescue-<machine-id>' not found. error: ../../grub-core/loader/i386/efi/linux.c:206:you need to load the kernel first. Press any key to continue... I do get the same errors if I run your command (sudo kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz). I don't get any output of the command which should mean it is running as intended. Do I need to rm -f /boot/vmlinuz-0-rescue-* /boot/initramfs-0-rescue-*.img because your command does not override file as the 51-dracut-rescue-postinst.sh script does? Best regards
(In reply to relentless.1980 from comment #2) > (In reply to Javier Martinez Canillas from comment #1) > > Yes, that's a bug. In the meantime you can re-generate your rescue initramfs > > with: > > > > $ kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz > > Thanks for the fast reply. > > But the rescue initramfs and vmlinuz are re-generated via the > 51-dracut-rescue-postinst.sh script successfully as I can see them in > /boot/. But if I select the rescue option in grub2 during boot I get the > following erros: > > error: ../../grub-core/fs/fshelp.c:257:file 'vmlinuz-0-rescue-<machine-id>' > not found. > error: ../../grub-core/loader/i386/efi/linux.c:206:you need to load the > kernel first. > > Press any key to continue... > > > I do get the same errors if I run your command (sudo kernel-install add > $(uname -r) /lib/modules/$(uname -r)/vmlinuz). I don't get any output of the > command which should mean it is running as intended. > > Do I need to rm -f /boot/vmlinuz-0-rescue-* /boot/initramfs-0-rescue-*.img > because your command does not override file as the > 51-dracut-rescue-postinst.sh script does? > It's generated by /usr/lib/kernel/install.d/51-dracut-rescue.install in the kernel-install case. And yes, you need to remove it since it's not overridden.
(In reply to Javier Martinez Canillas from comment #3) > It's generated by /usr/lib/kernel/install.d/51-dracut-rescue.install in the > kernel-install case. And yes, you need to remove it since it's not > overridden. I still cannot boot the rescue. I did: $ sudo -i [sudo] password for <user>: $ rm -f /boot/vmlinuz-0-rescue-* /boot/initramfs-0-rescue-*.img $ kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz $ grub2-mkconfig -o /boot/grub2/grub.cfg Generating grub configuration file ... Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi Adding boot menu entry for EFI firmware configuration done $ grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg Generating grub configuration file ... Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi Adding boot menu entry for EFI firmware configuration done But I still get the following errors if I select the rescue option in grub2 during boot: error: ../../grub-core/fs/fshelp.c:257:file 'vmlinuz-0-rescue-<machine-id>' not found. error: ../../grub-core/loader/i386/efi/linux.c:206:you need to load the kernel first. Press any key to continue... It is Fedora 30 + Windows 10 DualBoot configuration with seperate EFI-Partitions. Device Start End Sectors Size Type /dev/nvme0n1p1 2048 534527 532480 260M EFI System /dev/nvme0n1p2 534528 567295 32768 16M Microsoft reserved /dev/nvme0n1p3 567296 210282495 209715200 100G Microsoft basic data /dev/nvme0n1p4 998166528 1000214527 2048000 1000M Windows recovery environment /dev/nvme0n1p5 210282496 211730431 1447936 707M EFI System /dev/nvme0n1p6 211730432 317478911 105748480 50.4G Linux filesystem /dev/nvme0n1p7 317478912 946624511 629145600 300G Linux filesystem /dev/nvme0n1p8 946624512 998166527 51542016 24.6G Linux swap I can boot Windows via grub2 and Windows Boot Manger as well as Fedora 30 via grub 2. Just the rescue cannt boot with given errors. Best regards
(In reply to relentless.1980 from comment #4) > (In reply to Javier Martinez Canillas from comment #3) [snip] > > But I still get the following errors if I select the rescue option in grub2 > during boot: > > error: ../../grub-core/fs/fshelp.c:257:file 'vmlinuz-0-rescue-<machine-id>' > not found. I'm not able to reproduce this issue. Could you please share the .conf files in /boot/loader/entries ?
(In reply to Javier Martinez Canillas from comment #5) > > I'm not able to reproduce this issue. Could you please share the .conf files > in /boot/loader/entries ? In /boot/loader/entries/ directory I have 4 files with the following content each: <machine-id>-0-rescue.conf title Fedora (0-rescue-<machine-id>) 30 (Thirty) version 0-rescue-<machine-id> linux /vmlinuz-0-rescue-<machine-id> initrd /initramfs-0-rescue-<machine-id>.img options $kernelopts grub_users $grub_users grub_arg --unrestricted grub_class kernel <machine-id>-5.0.3-300.fc30.x86_64.conf title Fedora (5.0.3-300.fc30.x86_64) 30 (Thirty) version 5.0.3-300.fc30.x86_64 linux /boot/vmlinuz-5.0.3-300.fc30.x86_64 initrd /boot/initramfs-5.0.3-300.fc30.x86_64.img options $kernelopts grub_users $grub_users grub_arg --unrestricted grub_class kernel <machine-id>-5.0.4-300.fc30.x86_64.conf title Fedora (5.0.4-300.fc30.x86_64) 30 (Thirty) version 5.0.4-300.fc30.x86_64 linux /boot/vmlinuz-5.0.4-300.fc30.x86_64 initrd /boot/initramfs-5.0.4-300.fc30.x86_64.img options $kernelopts grub_users $grub_users grub_arg --unrestricted grub_class kernel <machine-id>-5.0.5-300.fc30.x86_64.conf title Fedora (5.0.5-300.fc30.x86_64) 30 (Thirty) version 5.0.5-300.fc30.x86_64 linux /boot/vmlinuz-5.0.5-300.fc30.x86_64 initrd /boot/initramfs-5.0.5-300.fc30.x86_64.img options $kernelopts grub_users $grub_users grub_arg --unrestricted grub_class kernel
(In reply to relentless.1980 from comment #6) [snip] > <machine-id>-0-rescue.conf > title Fedora (0-rescue-<machine-id>) 30 (Thirty) > version 0-rescue-<machine-id> > linux /vmlinuz-0-rescue-<machine-id> > initrd /initramfs-0-rescue-<machine-id>.img The problem is probably that the /boot/ directory is missing. It should be linux /boot/vmlinuz-0-rescue-<machine-id> instead of linux /vmlinuz-0-rescue-<machine-id> and initrd /boot/initramfs-0-rescue-<machine-id>.img instead of initrd /initramfs-0-rescue-<machine-id>.img respectively. Is this another bug or do I have to run the 'kernel-install add' command with other arguments?
(In reply to relentless.1980 from comment #7) > (In reply to relentless.1980 from comment #6) > [snip] > > <machine-id>-0-rescue.conf > > title Fedora (0-rescue-<machine-id>) 30 (Thirty) > > version 0-rescue-<machine-id> > > linux /vmlinuz-0-rescue-<machine-id> > > initrd /initramfs-0-rescue-<machine-id>.img > > The problem is probably that the /boot/ directory is missing. > > It should be > linux /boot/vmlinuz-0-rescue-<machine-id> > > instead of > linux /vmlinuz-0-rescue-<machine-id> > I don't think that's the problem, the kernel and initramfs path is relative to the root of the boot partition. So I assume you have a partition mounted in /boot. The problem I think is the <machine-id> instead of a proper machine ID. What do you have in /etc/machine-id?
(In reply to Javier Martinez Canillas from comment #8) > I don't think that's the problem, the kernel and initramfs path is relative > to the root of the boot partition. So I assume you have a partition mounted > in /boot. > > The problem I think is the <machine-id> instead of a proper machine ID. What > do you have in /etc/machine-id? Sry for the miss-clarification but all values between < > are manually replaced by be. So there is a proper machine-id. I just added /boot/ to the <machine-id>-0-rescue.conf file like so: <machine-id>-0-rescue.conf title Fedora (0-rescue-<machine-id>) 30 (Thirty) version 0-rescue-<machine-id> linux /boot/vmlinuz-0-rescue-<machine-id> initrd /boot/initramfs-0-rescue-<machine-id>.img options $kernelopts grub_users $grub_users grub_arg --unrestricted grub_class kernel now I can boot the rescue via grub2.
(In reply to relentless.1980 from comment #9) > (In reply to Javier Martinez Canillas from comment #8) > > I don't think that's the problem, the kernel and initramfs path is relative > > to the root of the boot partition. So I assume you have a partition mounted > > in /boot. > > > > The problem I think is the <machine-id> instead of a proper machine ID. What > > do you have in /etc/machine-id? > > Sry for the miss-clarification but all values between < > are manually > replaced by be. So there is a proper machine-id. Ah Ok, sorry for the misunderstanding then. > I just added /boot/ to the <machine-id>-0-rescue.conf file like so: > > <machine-id>-0-rescue.conf > title Fedora (0-rescue-<machine-id>) 30 (Thirty) > version 0-rescue-<machine-id> > linux /boot/vmlinuz-0-rescue-<machine-id> > initrd /boot/initramfs-0-rescue-<machine-id>.img > options $kernelopts > grub_users $grub_users > grub_arg --unrestricted > grub_class kernel > Yes, that's needed when you don't have a boot partition (/boot is not a mount point and just a directory in the root partition). But the grub2-switch-to-blscfg and kernel-install scripts should had taken that into account and added a /boot prefix in that case. I wonder why that didn't work for you. > now I can boot the rescue via grub2. Great, good to know.
(In reply to Javier Martinez Canillas from comment #10) [snip] > Yes, that's needed when you don't have a boot partition (/boot is not a > mount point and just a directory in the root partition). [snip] Yes indeed I just have /, /boot/efi, /home, swap partions. So no extra /boot partition. Is that not recommended? Anyway I hope grub2-switch-to-blscfg, kernel-install, 51-dracut-rescue.install and 51-dracut-rescue-postinst.sh scripts can handle this situation in future releases. Thanks a lot!
(In reply to relentless.1980 from comment #11) > (In reply to Javier Martinez Canillas from comment #10) > [snip] > > Yes, that's needed when you don't have a boot partition (/boot is not a > > mount point and just a directory in the root partition). > [snip] > > Yes indeed I just have /, /boot/efi, /home, swap partions. So no extra /boot > partition. Is that not recommended? > > Anyway I hope grub2-switch-to-blscfg, kernel-install, > 51-dracut-rescue.install and 51-dracut-rescue-postinst.sh scripts can handle > this situation in future releases. > In theory they should. I just tried on an install with no boot partition and it worked correctly for me. I wonder what went wrong in your case. > Thanks a lot! You are welcome.
I would like to add to this a more generic bur related issue. If you have grubby-8.40-30.fc30.x86_64 installed, NONE of the scripts on /etc/kernel/postinst.d are automatically executed when installing a new kernel. This is because the responsibility for running these is /usr/sbin/new-kernel-pkg and that is no longer installed by grubby-8.40-30.fc30.x86_64 but only by grubby-deprecated-8.40-30.fc30.x86_64.rpm This inherently breaks all /etc/kernel/postinst.d processing. All scripts in that directory have to be manually run after the yum update is completed.
For reference, this is the process tree when using /etc/kernel/postinst.d/dkms on a Fedora 29 system, where the new-kernel-package tool still exists, showing the dependency. | | |-bash,612882 | | | `-su,833467 - | | | `-bash,833473 | | | `-yum,833557 /usr/bin/yum update | | | `-sh,868473 /var/tmp/rpm-tmp.d4cxYv 3 | | | `-kernel-install,868474 /bin/kernel-install add 5.0.17-200.fc29.x86_64 /lib/modules/5.0.17-200.fc29.x86_64/vmlinuz | | | `-20-grub.install,868495 /usr/lib/kernel/install.d/20-grub.install add 5.0.17-200.fc29.x86_64 /boot/e4ca82af9e3245b38f3409c72c7bf72b/5.0.17-200.fc29.x86_64 /lib/modules/5.0.17-200.fc29.x86_64/vmlinuz | | | `-new-kernel-pkg,877807 /sbin/new-kernel-pkg --package kernel --rpmposttrans 5.0.17-200.fc29.x86_64 | | | `-dkms,877834 /etc/kernel/postinst.d/dkms 5.0.17-200.fc29.x86_64 /boot/vmlinuz-5.0.17-200.fc29.x86_64
FEDORA-2019-df50a7eda6 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-df50a7eda6
grubby-8.40-31.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-df50a7eda6
(In reply to Kelvin J. Hill from comment #13) > I would like to add to this a more generic bur related issue. > > If you have grubby-8.40-30.fc30.x86_64 installed, NONE of the scripts on > /etc/kernel/postinst.d are automatically executed when installing a new > kernel. > > This is because the responsibility for running these is > /usr/sbin/new-kernel-pkg and that is no longer installed by > grubby-8.40-30.fc30.x86_64 but only by > grubby-deprecated-8.40-30.fc30.x86_64.rpm > > This inherently breaks all /etc/kernel/postinst.d processing. All scripts in > that directory have to be manually run after the yum update is completed. Note, though, that in this case the scripts /usr/lib/kernel/install.d/51-dracut-rescue.install is run instead of /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh and /usr/lib/kernel/install.d/95-akmodsposttrans.install is run instead of /etc/kernel/postinst.d/akmodsposttrans 95-akmodsposttrans.install was added to the akmods package middle of May.
(In reply to relentless.1980 from comment #7) > (In reply to relentless.1980 from comment #6) > [snip] > > <machine-id>-0-rescue.conf > > title Fedora (0-rescue-<machine-id>) 30 (Thirty) > > version 0-rescue-<machine-id> > > linux /vmlinuz-0-rescue-<machine-id> > > initrd /initramfs-0-rescue-<machine-id>.img > > The problem is probably that the /boot/ directory is missing. > > It should be > linux /boot/vmlinuz-0-rescue-<machine-id> > > instead of > linux /vmlinuz-0-rescue-<machine-id> > > > and > initrd /boot/initramfs-0-rescue-<machine-id>.img > > instead of > initrd /initramfs-0-rescue-<machine-id>.img > > respectively. Is this another bug or do I have to run the 'kernel-install > add' command with other arguments? This should happen in 51-dracut-rescue.install: { echo "title $PRETTY_NAME - Rescue Image" echo "version $KERNEL_VERSION" echo "machine-id $MACHINE_ID" echo "options ${BOOT_OPTIONS[@]} rd.auto=1" echo "linux $BOOT_DIR/linux" echo "initrd $BOOT_DIR/initrd" } > $LOADER_ENTRY But I see nowhere BOOT_DIR is set to anything anywhere except when you are using systemd-bootd and have no grub2 packages installed. Same for 51-dracut-rescue-postinst.sh.
(In reply to Villy Kruse from comment #18) > > This should happen in 51-dracut-rescue.install: > > { > echo "title $PRETTY_NAME - Rescue Image" > echo "version $KERNEL_VERSION" > echo "machine-id $MACHINE_ID" > echo "options ${BOOT_OPTIONS[@]} rd.auto=1" > echo "linux $BOOT_DIR/linux" > echo "initrd $BOOT_DIR/initrd" > } > $LOADER_ENTRY > > > But I see nowhere BOOT_DIR is set to anything anywhere except when you are > using systemd-bootd and have no grub2 packages installed. > > Same for 51-dracut-rescue-postinst.sh. Correction: The relevant code is actually: cp -aT "${KERNEL_IMAGE%/*}/bls.conf" $LOADER_ENTRY sed -i 's/'$KERNEL_VERSION'/0-rescue-'${MACHINE_ID}'/' $LOADER_ENTRY That is: copying /lib/modules/5.1.11-300.fc30.x86_64/bls.conf to $LOADER_ENTRY 20-grub.install does something similar, but also have code which prepends "/boot to the entries if needed. This is missing in 51-dracut-rescue.install. From 20-grub.install: LINUX="$(grep '^linux[ \t]' "${BLS_TARGET}" | sed -e 's,^linux[ \t]*,,')" INITRD="$(grep '^initrd[ \t]' "${BLS_TARGET}" | sed -e 's,^initrd[ \t]*,,')" LINUX_RELPATH="$(grub2-mkrelpath /boot${LINUX})" BOOTPREFIX="$(dirname ${LINUX_RELPATH})" ROOTPREFIX="$(dirname "/boot${LINUX}")" if [[ $LINUX != $LINUX_RELPATH ]]; then sed -i -e "s,^linux.*,linux ${BOOTPREFIX}${LINUX},g" "${BLS_TARGET}" sed -i -e "s,^initrd.*,initrd ${BOOTPREFIX}${INITRD},g" "${BLS_TARGET}" fi
(In reply to Fedora Update System from comment #16) > grubby-8.40-31.fc30 has been pushed to the Fedora 30 testing repository. If > problems still persist, please make note of it in this bug report. > See https://fedoraproject.org/wiki/QA:Updates_Testing for > instructions on how to install test updates. > You can provide feedback for this update here: > https://bodhi.fedoraproject.org/updates/FEDORA-2019-df50a7eda6 I tested grubby-8.40-31 an commented on https://bodhi.fedoraproject.org/updates/FEDORA-2019-df50a7eda6. For me it seems the update has not resolved the issue. But I might have tested wrong?!
(In reply to relentless.1980 from comment #20) > (In reply to Fedora Update System from comment #16) > > grubby-8.40-31.fc30 has been pushed to the Fedora 30 testing repository. If > > problems still persist, please make note of it in this bug report. > > See https://fedoraproject.org/wiki/QA:Updates_Testing for > > instructions on how to install test updates. > > You can provide feedback for this update here: > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-df50a7eda6 > > I tested grubby-8.40-31 an commented on > https://bodhi.fedoraproject.org/updates/FEDORA-2019-df50a7eda6. > Sorry for hijacking your bug report. I wanted to fix the more general issue of /etc/kernel/ scripts not being executed when a new kernel is installed. That was the goal of the update that you gave negative karma and is blocked now. > For me it seems the update has not resolved the issue. But I might have > tested wrong?! I understand your problem now. The BLS snippet for the rescue image doesn't have a proper 'linux' and 'initrd' path if the /boot directory is not a mount point. But that's something that has to be fixed in the dracut package and not grubby: rpm -qf /usr/lib/kernel/install.d/51-dracut-rescue.install dracut-config-rescue-049-26.git20181204.fc30.x86_64 I'll propose a fix for the 51-dracut-rescue.install script in dracut.
(In reply to Javier Martinez Canillas from comment #21) > (In reply to relentless.1980 from comment #20) > > (In reply to Fedora Update System from comment #16) > > > grubby-8.40-31.fc30 has been pushed to the Fedora 30 testing repository. If > > > problems still persist, please make note of it in this bug report. > > > See https://fedoraproject.org/wiki/QA:Updates_Testing for > > > instructions on how to install test updates. > > > You can provide feedback for this update here: > > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-df50a7eda6 > > > > I tested grubby-8.40-31 an commented on > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-df50a7eda6. > > > > Sorry for hijacking your bug report. I wanted to fix the more general issue > of /etc/kernel/ scripts not being executed when a new kernel is installed. > That was the goal of the update that you gave negative karma and is blocked > now. > > > For me it seems the update has not resolved the issue. But I might have > > tested wrong?! > > I understand your problem now. The BLS snippet for the rescue image doesn't > have a proper 'linux' and 'initrd' path if the /boot directory is not a > mount point. But that's something that has to be fixed in the dracut package > and not grubby: > > rpm -qf /usr/lib/kernel/install.d/51-dracut-rescue.install > dracut-config-rescue-049-26.git20181204.fc30.x86_64 > > I'll propose a fix for the 51-dracut-rescue.install script in dracut. I posted a patch at Bugzill number 1708753 for dracut.
(In reply to Javier Martinez Canillas from comment #21) > Sorry for hijacking your bug report. I wanted to fix the more general issue > of /etc/kernel/ scripts not being executed when a new kernel is installed. > That was the goal of the update that you gave negative karma and is blocked > now. Okay, sorry can a remove my bad karma.. should I? Thanks for the patches.
Hello Villy, (In reply to Villy Kruse from comment #22) > (In reply to Javier Martinez Canillas from comment #21) > > (In reply to relentless.1980 from comment #20) > > > (In reply to Fedora Update System from comment #16) > > > > grubby-8.40-31.fc30 has been pushed to the Fedora 30 testing repository. If > > > > problems still persist, please make note of it in this bug report. > > > > See https://fedoraproject.org/wiki/QA:Updates_Testing for > > > > instructions on how to install test updates. > > > > You can provide feedback for this update here: > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-df50a7eda6 > > > > > > I tested grubby-8.40-31 an commented on > > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-df50a7eda6. > > > > > > > Sorry for hijacking your bug report. I wanted to fix the more general issue > > of /etc/kernel/ scripts not being executed when a new kernel is installed. > > That was the goal of the update that you gave negative karma and is blocked > > now. > > > > > For me it seems the update has not resolved the issue. But I might have > > > tested wrong?! > > > > I understand your problem now. The BLS snippet for the rescue image doesn't > > have a proper 'linux' and 'initrd' path if the /boot directory is not a > > mount point. But that's something that has to be fixed in the dracut package > > and not grubby: > > > > rpm -qf /usr/lib/kernel/install.d/51-dracut-rescue.install > > dracut-config-rescue-049-26.git20181204.fc30.x86_64 > > > > I'll propose a fix for the 51-dracut-rescue.install script in dracut. > > I posted a patch at Bugzill number 1708753 for dracut. Thanks a lot for your patch. Your change certainly looks like the correct fix to me.
(In reply to relentless.1980 from comment #23) > (In reply to Javier Martinez Canillas from comment #21) > > Sorry for hijacking your bug report. I wanted to fix the more general issue > > of /etc/kernel/ scripts not being executed when a new kernel is installed. > > That was the goal of the update that you gave negative karma and is blocked > > now. > > Okay, sorry can a remove my bad karma.. should I? > No worries, I should had communicate better what the fix was about and that the fix for your issue had to be in dracut. If you could remove your bad karma that would be great since I think that autopush would be enabled again, otherwise I can try to push the update manually.
(In reply to Javier Martinez Canillas from comment #25) > (In reply to relentless.1980 from comment #23) > > (In reply to Javier Martinez Canillas from comment #21) > > > Sorry for hijacking your bug report. I wanted to fix the more general issue > > > of /etc/kernel/ scripts not being executed when a new kernel is installed. > > > That was the goal of the update that you gave negative karma and is blocked > > > now. > > > > Okay, sorry can a remove my bad karma.. should I? > > > > No worries, I should had communicate better what the fix was about and that > the fix for your issue had to be in dracut. > > If you could remove your bad karma that would be great since I think that > autopush would be enabled again, otherwise I can try to push the update > manually. Can you check if the file /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh is compatible with bls? As far as I can see it would fail on the missing new-kernel-pkg program.
(In reply to Villy Kruse from comment #26) > (In reply to Javier Martinez Canillas from comment #25) > > (In reply to relentless.1980 from comment #23) > > > (In reply to Javier Martinez Canillas from comment #21) > > > > Sorry for hijacking your bug report. I wanted to fix the more general issue > > > > of /etc/kernel/ scripts not being executed when a new kernel is installed. > > > > That was the goal of the update that you gave negative karma and is blocked > > > > now. > > > > > > Okay, sorry can a remove my bad karma.. should I? > > > > > > > No worries, I should had communicate better what the fix was about and that > > the fix for your issue had to be in dracut. > > > > If you could remove your bad karma that would be great since I think that > > autopush would be enabled again, otherwise I can try to push the update > > manually. > > > Can you check if the file > > /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh > > is compatible with bls? > > As far as I can see it would fail on the missing new-kernel-pkg program. No, it's not. But the rescue initramfs will be generated by /usr/lib/kernel/install.d/51-dracut-rescue.install and then if /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh is executed, it will check the the rescue initrd and kernel image already exist in /boot and just exit. We keep that script for people that opt-out from BLS and are still using the grubby-deprecated package.
(In reply to Javier Martinez Canillas from comment #27) > (In reply to Villy Kruse from comment #26) > > (In reply to Javier Martinez Canillas from comment #25) > > > > As far as I can see it would fail on the missing new-kernel-pkg program. > > No, it's not. But the rescue initramfs will be generated by > /usr/lib/kernel/install.d/51-dracut-rescue.install and then if > /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh is executed, it will > check the the rescue initrd and kernel image already exist in /boot and just > exit. > Oh, that way. A little bit tricky, perhaps. > We keep that script for people that opt-out from BLS and are still using the > grubby-deprecated package.
grubby-8.40-31.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1709940 has been marked as a duplicate of this bug. ***