SBAT verification error - cannot disable secureboot

enok71 · May 20, 2024, 3:27pm

I accidently booted windows last week, which performed various updates, after which I can no longer boot my OpenSuse 15.5.

I don’t have BIOS password to this laptop to I can’t disable secure boot (which is a required step in suggested solutions in other similar threads).

I did download latest fedora live USB and it boots. Is it correct conclusion that fedora then must have a newer shim than OpenSuse, and that OpenSuse shim version is revoked?

Is there any way for me to manually update some files under /boot/EFI e.g. when running under the Fedore Live USB stick, and then be able to boot my OpenSuse again?

enok71 · May 20, 2024, 4:11pm

The shim version on my OpenSuse (which doesn’t boot due to SBAT veritifacion error) is shim-15.8-150300.4.20.2.x86_64 while the Fedora shim RPM that boots is shim-x64-15.8-3.x86_64.

The version numbers seem to indicate this is the same version(?) Yet Fedora boots but OpenSuse doesn’t.

Also tried downloading the latest tumbleweed boot usb 20240517 which also fails to boot (SBAT verification error).

Any ideas?

Output of “mokutils --list-sbat-revocations”:
sbat,1,2024010900
shim,4
grub,3
grub.debian,4

Is it OpenSuses grub that is revoked? Version of grub on non-booting system: grub2-x86_64-efi-2.06-150500.29.25.12.noarch

nrickert · May 20, 2024, 5:25pm

If you have only been using Leap 15.5, then you should not be having this problem. The “shim” from Tumbleweed will cause problems. The “shim” from 15.5 or 15.6 should not be a problem.

Try:

cd /boot/efi/EFI/opensuse
md5sum shim.efi

When I do that, I get:

a47b8bb55bd2bbd277c59009aa477879  shim.efi

If, however, I check the “shim.efi” from Tumbleweed, then I get:

8628f48c5d38765c52418242dbe5c981  shim.efi

And yes, it is possible to manually copy the correct “shim.efi” to your EFI partition – assuming that you can find the correct “shim.efi”.

The file “bootx64.efi” from the current Leap 15.6 iso should be the correct “shim.efi” (but with a different name).

arvidjaar · May 20, 2024, 6:00pm

Show

objcopy -j .sbat -O binary /boot/efi/name-of-shim /dev/stdout

for both openSUSE and Fedora shims. Like

bor@bor-Latitude-E5450:~/src/linux$ objcopy -j .sbat -O binary /boot/efi/EFI/Boot/bootx64.efi /dev/stdout
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.ubuntu,1,Ubuntu,shim,15.7-0ubuntu1,https://www.ubuntu.com/
bor@bor-Latitude-E5450:~/src/linux$

And use preformatted text when posting computer output.

enok71 · May 20, 2024, 6:52pm

The shim.efi on my 15.5 installation has the checksum a47…879 and the bootx64.efi on the tumbleweed installation stick has 862…981. Just as you write. But both the 15.5 installation and the tumbleweed stick cause “SBAT verification” error.

And as I wrote at the top: the problem occurred after booting a Windows M.2 SSD and letting it apply all latest windows updates. After that no OpenSuse media boot (but fedora USB stick boots).

arvidjaar · May 20, 2024, 6:55pm

openSUSE media are using older shim versions. Leap 15.5 comes with shim 15.7 originally.

What exactly does it mean? Where is this file located?

enok71 · May 20, 2024, 7:14pm

On my opensuse Leap 15.5 /boot/efi/EFI/opensuse/shim.efi:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.sle,1,SUSE Linux Enterprise,shim,15.8,mail:security@suse.de

On the fedora boot USB stick (that works) /boot/efi/EFI/fedora/shim.efi:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.rh,3,The Fedora Project,shim,15.8,https://src.fedoraproject.org/rpms/shim-unsigned-x64
shim.redhat,3,The Fedora Project,shim,15.8,https://src.fedoraproject.org/rpms/shim-unsigned-x64
shim.fedora,3,The Fedora Project,shim,15.8,https://src.fedoraproject.org/rpms/shim-unsigned-x64

enok71 · May 20, 2024, 7:28pm

The 15.5 shim.efi is at the location that @nrickert described: efi/EFI/opensuse/shim.efi on the first partition of the ssd where Leap 15.5 is installed.

The Tumbleweed checksum is from the file EFI/BOOT/bootx64.efi on the first partition of the 20240517 tumbleweed USB stick. @nrickert wrote earlier that he thinks that is the shim file, but perhaps it’s not: when I run your objcopy command on it I just get “file format not recognized”.

I can´t find a file named shim*.efi on the tumbleweed stick.

arvidjaar · May 21, 2024, 3:56am

enok71:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.sle,1,SUSE Linux Enterprise,shim,15.8,mail:security@suse.de

Post photo of the “SBAT verification error”.

enok71 · May 21, 2024, 7:24am

arvidjaar · May 21, 2024, 7:26am

Should not happen with the shim shown so far. What is the output of

efibootmgr -v

enok71 · May 21, 2024, 7:35am

In which environment do you want me to run that command? The only system I can boot is the fedora USB stick or Windows 11.

I guess I could repeat what I did yesterday: boot the fedora stick, mount the unbootable OpenSuse ssd filesystems somewhere, mount all 20 btrfs subvolumes, mount -o rebind all special filesystems and then chroot into it and run that efibootmgr command. But will that help you?

enok71 · May 21, 2024, 7:57am

I tried physically removing the SSD and booting the tumbleweed USB stick 20240517. Still no boot, just that same SBAT failure message.

So my laptop really refuses to boot OpenSuse, but Fedora works.

arvidjaar · May 21, 2024, 8:02am

Tumbleweed has really old shim that will not be bootable in this case. Can you boot Leap 15.6 install image?

It should not really matter as the command lists the content of EFI variables. Except

your firmware may remove (or at least hide) the entries pointing to the non-existent device, so it is better to do it while your SSD with Leap is present. efibootmgr does not exist for Windows. There is bcdedit /enum firmware, but the output is not directly comparable to efibootmgr. So better is to boot Fedora.

enok71 · May 21, 2024, 8:35am

The 15.6-NET-x86_64-Build701.1 boots! And from the boot menu I’m able to boot my 15.5 installation from the SSD.

oeab-hp-4:/home/enok # efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0000,0004,0005
Boot0000* WD Green SN350 500GB 2G0C-23233N470503        PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-1B-44-4A-48-76-AF-32)N.....YM....R,Y.....ISPH
Boot0003* Kingston DataTraveler 3.0 408D5CE57214E7A109054AFC    PciRoot(0x0)/Pci(0x14,0x0)/USB(12,0)N.....YM....R,Y.....ISPH
Boot0004  USB NETWORK BOOT:     PciRoot(0x0)/Pci(0xd,0x0)/USB(1,0)/MAC(3c18a0ced4ef,0)/IPv4(0.0.0.00.0.0.0,0,0)N.....YM....R,Y.....ISPH
Boot0005  USB NETWORK BOOT:     PciRoot(0x0)/Pci(0xd,0x0)/USB(1,0)/MAC(3c18a0ced4ef,0)/IPv6([::]:<->[::]:,0,0)N.....YM....R,Y.....ISPH

arvidjaar · May 21, 2024, 8:46am

There is no boot entry for openSUSE which implies it is likely using \EFI\Boot\bootx64.efi, not \EFI\opensuse\shim.efi. Show in Leap 15.5:

lsblk -f -o +partuuid
ls -lR /boot/efi
objcopy -j .sbat -O binary /boot/efi/EFI/boot/grubx64.efi /dev/stdout

enok71 · May 21, 2024, 9:01am

oeab-hp-4:/home/enok # lsblk -f -o +partuuid
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS            PARTUUID
nvme0n1                                                                                                   
├─nvme0n1p1 vfat   FAT32       8402-95D4                             502.7M     2% /boot/efi              390c3189-ae90-418c-b851-44cf0bd57bf3
├─nvme0n1p2 btrfs              78c141bd-dbc1-4f35-a223-cca7c5638bbe  363.1G    22% /home                  e2478872-11ee-45bc-8fe7-e78adde5220f
│                                                                                  /var                   
│                                                                                  /root                  
│                                                                                  /srv                   
│                                                                                  /boot/grub2/x86_64-efi 
│                                                                                  /boot/grub2/i386-pc    
│                                                                                  /tmp                   
│                                                                                  /usr/local             
│                                                                                  /opt                   
│                                                                                  /.snapshots            
│                                                                                  /                      
└─nvme0n1p3 swap   1           4842f75c-b944-4ff1-a5e2-226acc9ea739                [SWAP]                 4fd36be2-920f-433f-acc7-0a67f03978d6
oeab-hp-4:/home/enok # ls -lR /boot/efi
/boot/efi:
total 4
drwxr-xr-x 5 root root 4096 Mar  1 01:27 EFI

/boot/efi/EFI:
total 12
drwxr-xr-x 2 root root 4096 Sep 15  2020 boot
drwxr-xr-x 2 root root 4096 May 20 16:08 opensuse
drwxr-xr-x 2 root root 4096 Nov  1  2019 opensuse.new

/boot/efi/EFI/boot:
total 1860
-rwxr-xr-x 1 root root 852408 Mar  1 01:58 MokManager.efi
-rwxr-xr-x 1 root root 953800 Mar  1 01:58 bootx64.efi
-rwxr-xr-x 1 root root  90592 Mar  1 01:58 fallback.efi

/boot/efi/EFI/opensuse:
total 3352
-rwxr-xr-x 1 root root  852456 Apr 23 04:24 MokManager.efi
-rwxr-xr-x 1 root root      58 Apr 23 04:24 boot.csv
-rwxr-xr-x 1 root root     167 Apr 23 04:24 grub.cfg
-rwxr-xr-x 1 root root 1275904 Apr 23 04:24 grub.efi
-rwxr-xr-x 1 root root  319488 Apr 23 04:24 grubx64.efi
-rwxr-xr-x 1 root root     196 May 20 16:08 opensuse.shim.efi.out
-rwxr-xr-x 1 root root  965672 Apr 23 04:24 shim.efi

/boot/efi/EFI/opensuse.new:
total 3248
-rwxr-xr-x 1 root root  852456 Mar  1 01:58 MokManager.efi
-rwxr-xr-x 1 root root      58 Mar  1 01:58 boot.csv
-rwxr-xr-x 1 root root     369 Mar  1 01:58 grub.cfg
-rwxr-xr-x 1 root root 1320960 Mar  1 01:58 grub.efi
-rwxr-xr-x 1 root root  172032 Mar  1 01:58 grubx64.efi
-rwxr-xr-x 1 root root  965672 Mar  1 01:58 shim.efi
oeab-hp-4:/home/enok # objcopy -j .sbat -O binary /boot/efi/EFI/boot/grubx64.efi /dev/stdout
objcopy: "/boot/efi/EFI/boot/grubx64.efi": No such file
oeab-hp-4:/home/enok # objcopy -j .sbat -O binary /boot/efi/EFI/opensuse/grubx64.efi /dev/stdout
oeab-hp-4:/home/enok #

arvidjaar · May 21, 2024, 9:15am

They are different which explains your problem.

Sorry, it should have been

objcopy -j .sbat -O binary /boot/efi/EFI/boot/bootx64.efi /dev/stdout

enok71 · May 21, 2024, 9:28am

Seems you found the explanation! How could that happen? Both files should be created when updating the shim rpm I suppose?

So I just overwrite the bootx64.efi with shim.efi?

oeab-hp-4:/home/enok # objcopy -j .sbat -O binary /boot/efi/EFI/opensuse/shim.efi /dev/stdout
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.sle,1,SUSE Linux Enterprise,shim,15.8,mail:security@suse.de
oeab-hp-4:/home/enok # objcopy -j .sbat -O binary /boot/efi/EFI/boot/bootx64.efi /dev/stdout 
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.sle,1,SUSE Linux Enterprise,shim,15.7,mail:security@suse.de

arvidjaar · May 21, 2024, 9:42am

For all I can tell this is a bug in shim-install.

Yes, but shim-install checks whether \EFI\Boot\bootx64.efi comes from the same “vendor”. It does it by looking for certificate name inside of the binary. Unfortunately, on openSUSE Leap the shim.efi comes from SUSE, but shim-install looks for openSUSE certificate.

It was not noticed because normally the \EFI\Boot\bootx64.efi on fixed disks is not used at all. So there is second issue - why normal boot entries are missing. They may have been removed by Windows update or by your firmware. You could try update-bootloader --reinit - any changes in efibootmgr output?

What is the output of

grep -b 'SUSE Linux Enterprise Secure Boot CA1' /boot/efi/EFI/boot/bootx64.efi; echo $?
grep -b 'openSUSE Secure Boot CA1' /boot/efi/EFI/boot/bootx64.efi; echo $?

Yes, also MokManager.efi. Not sure where fallback.efi comes from. But save the original files. You should really open bug report, https://bugzilla.opensuse.org/, same user/password as here, select Leap 15.5, component Bootloader.