(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. ***