[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: appending partition results in zero bytes written
From: |
Thomas Schmitt |
Subject: |
Re: appending partition results in zero bytes written |
Date: |
Fri, 04 Aug 2023 16:28:33 +0200 |
Hi,
Cameron Seader wrote:
> When i use the resulting -outdev i get an error of:
> Verifying shim SBAT data failed: Security Policy Violation
> What might be causing this? Any hints?
Looks like something about UEFI Secure Boot.
It stays unclear to me whether the EFI firmware or the software in the EFI
partition issues the message. But the trigger must sit in the partition.
"shim" is the software which the Linux distros submit to Microsoft for
digital signing. It starts the boot loader, if all works well.
"SBAT" probably means "Secure Boot Advanced Targeting":
https://www.gnu.org/software/grub/manual/grub/html_node/Secure-Boot-Advanced-Targeting.html
The error message "Something has gone seriously wrong: SBAT self-check
failed" lets Google find various complaints of openSUSE users who suddenly
could not boot from their system disks (possibly after a system upgrade).
An interesting find is:
https://bugzilla.opensuse.org/show_bug.cgi?id=1209985
Somehow it seems to be about the EFI or the shim seeing traces of an older
shim ... i guess ...
The remedy near the end of the thread is to disable Secure Boot, boot, run
mokutil, reboot, and re-enable Secure Boot.
Another interesting find is a statement in
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot
"Since version 15.3, shim will not launch EFI binaries without a valid
.sbat section. Run objdump -j .sbat -s /path/to/binary.efi to verify
if an EFI binary has it. See the SBAT documentation for details."
The shim binary should be /EFI/BOOT/BOOTX64.EFI in the FAT filesystem of
the EFI partition. The GRUB binary to be launched is probably GRUBX64.EFI
in the same directory.
Have a nice day :)
Thomas