Issue with Patches openSUSE-2020-395 and openSUSE-2020-401 installed yesterday

English Install/Boot/Login
#1

The patches openSUSE-2020-395 (ruby2.5) and openSUSE-2020-401 (grub2) were installed yesterday on this UEFI Laptop. Zypper history noted the following errors:


# 2020-03-29 15:26:07 Output of grub2-i386-pc-2.02-lp151.21.12.1.noarch.rpm %posttrans script:
#     update-bootloader: 2020-03-29 15:26:04 <3> update-bootloader-6892 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
#     x86_64-efi wird f374r Ihre Plattform installiert.
#     installation beendet. Keine Fehler aufgetreten.
#     /usr/sbin/shim-install: Zeile 326: efibootmgr: Kommando nicht gefunden.
#     /usr/sbin/shim-install: Zeile 352: efibootmgr: Kommando nicht gefunden.
#     >>>>>>>>>>>>>>>>
#     update-bootloader: 2020-03-29 15:26:07 <3> update-bootloader-6892 run_command.294: '/usr/lib/bootloader/grub2-efi/config' failed with exit code 127, output:
#     <<<<<<<<<<<<<<<<
#     + /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg
#     Generating grub configuration file ...
#     Found theme: /boot/grub2/themes/openSUSE/theme.txt
#     Found linux image: /boot/vmlinuz-4.12.14-lp151.28.44-default
#     Found initrd image: /boot/initrd-4.12.14-lp151.28.44-default
#     Found linux image: /boot/vmlinuz-4.12.14-lp151.28.40-default
#     Found initrd image: /boot/initrd-4.12.14-lp151.28.40-default
#     Found linux image: /boot/vmlinuz-4.12.14-lp151.28.36-default
#     Found initrd image: /boot/initrd-4.12.14-lp151.28.36-default
#     /etc/grub.d/80_suse_btrfs_snapshot: Zeile 7: btrfs: Kommando nicht gefunden.
#     >>>>>>>>>>>>>>>>

Forcibly reinstalling the affected packages this morning executed without any failures being logged.


2020-03-30 09:45:28|command|root@xxx|'zypper' 'install' '--force' 'grub2' 'libruby2_5-2_5' 'grub2-i386-pc' 'ruby2.5' 'grub2-x86_64-efi' 'grub2-systemd-sleep-plugin' 'grub2-snapper-plugin' 'ruby2.5-stdlib'|

Has anyone else noticed this issue?

#2

Hi
No errors seen here;


2020-03-28 20:32:58|install|grub2-i386-pc|2.02-lp151.21.12.1|noarch||repo-update|

grep '127' /usr/include/asm-generic/errno.h
#define    EKEYEXPIRED    127    /* Key has expired */

Are you using secure boot?

#3

No problem here.

How did you apply the patches? Did you have an odd PATH?

#4

Yes – on an AMD Notebook – Chipset, CPU, Radeon Graphics – Lenovo G505s …

#5

Hi
Wonder if is/was Mok/key related…? Might try running mokutil and check keys? Secure boot working fine here in qemu, booted from shim.efi.

#6

KDE Plasma Updates Plasmoid front ending to PackageKit.

  • The 2nd time around with a forced re-install everything was OK.

[HR][/HR]Possibly an overnight fix in the Package Script?

#7

Only one key – from openSUSE …


 # mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: 46:59:83:8c:82:03:fe:15:52:ad:19:e1:86:09:db:21:7e:3a:d2:4f
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=build@opensuse.org
        Validity
            Not Before: Aug 26 16:12:07 2013 GMT
            Not After : Jul 22 16:12:07 2035 GMT
        Subject: CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=build@opensuse.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
#8

I doubt that the package changed. What changed, is how you installed the package.

Your error seems to be in running “efibootmgr”. That is in “/usr/sbin”. Maybe there’s a bug in “packagekit”, such that it is using an unsuitable PATH. You might want to file a bug report on that.

#9

I’ve walked through the errors reported – /usr/lib/bootloader/grub2-efi/install, /usr/sbin/shim-install, /etc/grub.d/80_suse_btrfs_snapshot are all scripts.
The /usr/sbin/ executables “efibootmgr” and “btrfs” are present and correct and execute correctly.
[HR][/HR]I suspect that, because the scripts do not call the executables by the full path name that, this, possibly, causes problems with PackageKit …
[HR][/HR]The packages which install these scripts are “shim” (Copyright owned by Red Hat) and “grub2-snapper-plugin” (no documentation in the package). I’ll try a Bug Report …

#10

Right now, I am cloning a KVM virtual machine that has Leap 15.1 (with UEFI booting). Then, in that clone, I revert to the earlier version of grub2. After that, I will activate the KDE update daemon, and let it handle the update.

Then I’ll check logs to see whether there was a problem.

#11

This is definitely a bug.

Please report, and post the bug number here. I will add a confirmation.

Here’s what I got:


#     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
#     >>>>>>>>>>>>>>>>

This text is from “/var/log/zypp/history”. I used the Leap 15.1 Plasma update applet for this update. And the update applet said that the update was fine.

Before I updated, I removed the UEFI boot entry

efibootmgr -b 1 -B

After the update, there was no boot entry.

I should note that I set the VM up to boot from the install DVD, where I choose the “boot from hard drive” menu entry. That is so I am not dependent on the UEFI boot entry for “opensuse-secureboot” (the entry that is missing).

Most users won’t actually see a problem. The boot entry will already be there. So the failure to add that boot entry should not cause problems. However, this still should not happen.

#12

Looking more carefully, I see that you have already filed a bug report

Bug 1168104 - Issue with Patch openSUSE-2020-401

I added a comment, and marked it as confirmed.

#13

Thanks Neil.

  • I only hope that, due to the “up-stream” ownership of the “shim” and “grub2-snapper-plugin” packages that, the SUSE team can influence the package owners to correct their scripts.

[HR][/HR]Regarding Shim and noticing this Debian information: <https://wiki.debian.org/SecureBoot>

It was developed by a group of Linux developers from various distros, working together to make SB work using Free Software. It is a common piece of code that is safe, well-understood and audited so that it can be trusted and signed using platform keys. This means that Microsoft (or other potential firmware CA providers) only have to worry about signing shim, and not all of the other programs that distro vendors might want to support.

Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.

IOW – COMMUNITY …
[HR][/HR]The GRUB2 Snapper Plugin should be somewhat easier: <https://www.linux.com/news/snapper-suses-ultimate-btrfs-snapshot-manager/>

Snapper, the excellent Btrfs management tool, is yet another of SUSE Linux’s best-kept secrets.

IOW – “In House” … :slight_smile: