http://bugzilla.opensuse.org/show_bug.cgi?id=1168104 http://bugzilla.opensuse.org/show_bug.cgi?id=1168104#c3 Neil Rickert <nwr10cst-oslnx@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED CC| |nwr10cst-oslnx@yahoo.com --- Comment #3 from Neil Rickert <nwr10cst-oslnx@yahoo.com> --- I can confirm this problem. I already had a KVM virtual machine with Leap 15.1. So I cloned that machine for the test. I first deleted the NVRAM entry used for booting: # efibootmgr -b 1 -B I made sure that I could still boot, using the install DVD and selecting "boot from hard drive" Next, I reverted several grub2 related packages to 2.02-lp151.21.9.1, so that I could repeat the update. I then updated using the KDE update applet. The applet reported a successful update. However, "/var/log/zypp/history" contained: ---- history lines ---- # tail /var/log/zypp/history # update-bootloader: 2020-03-30 15:12:39 <3> update-bootloader-6098 run_command.294: '/usr/lib/bootloader/grub2-efi/install' failed with exit code 127, output: # <<<<<<<<<<<<<<<< # target = x86_64-efi # + /usr/sbin/shim-install --config-file=/boot/grub2/grub.cfg # copying /usr/lib64/efi/grub.efi to /boot/efi/EFI/opensuse/grub.efi # Installing for x86_64-efi platform. # Installation finished. No error reported. # /usr/sbin/shim-install: line 326: efibootmgr: command not found # /usr/sbin/shim-install: line 352: efibootmgr: command not found # >>>>>>>>>>>>>>>> ---- end history lines ---- I also checked "efibootmgr" output: # efibootmgr -v BootCurrent: 0003 Timeout: 0 seconds BootOrder: 0003,0004,0000,0009 Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331) Boot0003* UEFI QEMU DVD-ROM QM00002 PciRoot(0x0)/Pci(0x1,0x1)/Ata(0,1,0)N.....YM....R,Y. Boot0004* UEFI QEMU HARDDISK QM00001 PciRoot(0x0)/Pci(0x1,0x1)/Ata(0,0,0)N.....YM....R,Y. Boot0009* EFI Internal Shell FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1) As you can see, there is no NVRAM entry added for "opensuse-secureboot". Most users would not be seriously affected. The installed bootcode was properly updated. And most users would already have an NVRAM entry for "opensuse-secureboot", so the failure to create that entry would not actually affect most users. When installing the update via "zypper" or "Yast", all seems to go well. And that's because "/usr/sbin" and "/sbin" are likely already on the PATH. But apparently, those are not part of the PATH set by "packagekitd", leading to the reported problem. -- You are receiving this mail because: You are on the CC list for the bug.