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)…

So, after searching the wild wild Internet, it appeared that with specific updates from Microsoft (courtesy of Windows 11 on said laptop), the secure boot policy on the system the patches were installed was “upgraded” to exclude “vulnerable” versions of UEFI shims (which includes majority of the UEFI bootloaders pre-dating the update).

Not satisfied with the “canned” (not to mention less secure) resolution of simply rolling back the SBAT updates and disabling all future SBAT updates (from Microsoft, no less), I attempted to look around for other solutions.

Ventoy Ahoy!

Ventoy already had a bug report, but the latest version (at time of writing) was still not “fixed”; the actual (acceptable, to me at least) “fix” was referenced from elsewhere (here and here) – but which mainly addressed fixing actual Linux installs, not USB bootloaders.

In summary, to get the Ventoy bootloader to work, I did the following:

• on a working system, copy a latest version of the Ubuntu Server/Desktop, CentOS or Fedora ISO (released post August 2024) to the multiboot USB device
• create temporary mount points:
  • mkdir /mnt/sdX1_data
  • mkdir /mnt/sdX2_efi
  • mkdir /mnt/iso_ro
• mount the various partitions and ISO  (following commands assume my USB disk is /dev/sda and using Ubuntu Server 24.04.1 ISO image)
  • run fdisk -l and find your Ventoy USB disk and partitions
  • mount /dev/sda1 /mnt/sdX1_data
  • mount /dev/sda2 /mnt/sdX2_efi
  • mount -o loop /mnt/sdX1_data/ubuntu-24.04.1-live-server-amd64.iso /mnt/iso_rw
• rename some files, replace some files and copy other files
  • cd /mnt/sdX2_efi/EFI/BOOT
  • mv grub.efi grubx64.efi
  • cp /mnt/iso_rw/EFI/boot/bootx64.efi ./BOOTX64.EFI
  • cp /mnt/iso_rw/EFI/boot/mmx64.efi . (NOTE: please note the trailing ‘.‘)
• unmount everything and clean up
  • umount /mnt/iso_ro /mnt/sdX1_data /mnt/sdX2_efi
  • rmdir /mnt/iso_ro /mnt/sdX1_data /mnt/sdX2_efi

Subsequently, the ISOs that you are attempting to boot from the Ventoy multiboot USB device must already have its own bootloaders updated, otherwise the manually updating these left as another exercise to you…

Enjoy!