So, I had to purchase a new laptop for someone, and as per usual, it came with the entire SSD capacity allocated, which I still feel is bad practice – specifically ensuring there is unallocated space that the drive firmware knows about, assuming TRIM is supported by both OS, controller and drive, (which, AFAIK, all “modern” OS and hardware do) to improve the drive’s wear-leveling ability and thereby extending the SSD’s lifespan.
To do so, I use a “rule of thumb” to leave ~20% of unpartitioned space – at the “end” of the disk (from a “logical” view of the partition table, regardless MBR or GPT). Usually, I simply use a “multi-boot” USB stick created using YUMI or Ventoy (the former now looking like a “wrapping” of the latter in its latest “exFAT” variant).
Aware of the shenanigans/rain dance required to make UEFI secure boot work from such bootloaders, like hundreds of other times (but never done for awhile), I simply (1) disabled CSM in BIOS, (2) enabled secure boot (and rebooted), (3) manually loaded the ENROLL_THIS_KEY_IN_MOKMANAGER.cer into the key store via BIOS from the prepared Ventoy USB disk…
I then confidently rebooted the laptop, pointing to the USB UEFI as the boot device, then ran headlong into the wall with a sickening SMACK. The wall was black, with only the words “Verifying shim SBAT data failed: Security Policy Violation” emblazoned across the top…
Attempting to fix this on this “new” laptop took me off on tangent, wasting nearly a half day trying to research and resolve… Hopefully this helps someone else with the “summary” below, assuming you have a working Linux system that can mount the USB device’s bootloader (i.e. EFI partition), since Windows cannot (without jumping through hoops)…
