WoeUSB VS shim

Windows uses some weird install process where it needs two partitions for the install media. Basically the whole installation is too big for FAT32 so IIRC the way to have it work is to split the ISO in two having the bootable part on one partition and a lot of the installation content on another.

https://github.com/WoeUSB/WoeUSB

https://github.com/WoeUSB/WoeUSB - you give it an MS iso and where to put it on a USB stick and it will do the job using NTFS, which doesn't have snags with >4GB files.

For flashing Windows I had luck with woeusb.

You want to repost your support request as issue on the WoeUSB issues github page.

instead I needed to use a tool called WoeUSB to create the drive.

Download, install and use woeusb to flash the ISO file to a thumb drive. Then boot from the thumb drive (you might have to use the BIOS boot menu to choose USB boot) and install windows onto the main storage device. You will likely have to use the Windows installer formatting tool before you can choose the installation destination.

Microsoft doesn't really sign other people's code for UEFI. They do sign shim (https://github.com/rhboot/shim) which will look at other keys the user registered with UEFI to load other components to enable you to write custom third party UEFI modules while still supporting secure boot.

In this case, the distros first boot loader is shim, which is signed by Microsoft. Shim is FOSS: https://github.com/rhboot/shim

How do I get dual boot set up and running? There doesn't seem so much documentation about this sbat chicanery as it was introduced to shim in 2021 and patched in rEFInd a bit more than a month ago, so I suppose not enough people have had this trouble yet.

Secure boot still isn't "secure" at all because microsoft has signed multiple bootloaders with their own keys, which exist only to chain load a second bootloader. See https://github.com/rhboot/shim and https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/

A new mechanism called SBAT (https://github.com/rhboot/shim/blob/main/SBAT.md) is now used to allow revocation of groups of bootloaders rather than individual hashes in order to mitigate the resource consumption

{ echo "sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md" echo "systemd-boot,1,systemd,systemd-boot,1,https://systemd.io" } > sbat.csv

Yeah, that incident instigated a totally new approach to revoking bad bootloaders that everybody (including Microsoft) should be using nowadays. So I guess HP just never got the memo.