http://bugzilla.opensuse.org/show_bug.cgi?id=1168104
http://bugzilla.opensuse.org/show_bug.cgi?id=1168104#c3
Neil Rickert changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CONFIRMED
CC| |nwr10cst-oslnx@yahoo.com
--- Comment #3 from Neil Rickert ---
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.