where (you guessed it) path-to-the-file.iso is the place and name of the ISO file on your system and /dev/sdX is the device file of the USB mass-storage device (/dev/sdb or /dev/sdc or /dev/sdd, or …)
It will overwrite all you did with that “clearing with a GPT PT” so that is spoiled time.
It was for good measure, to ensure that the EFI would not solely check the wrong partition, or miss it entirely, if misaligned, so it was not, because it had diagnostic value. Additionally, considering it takes about 5 seconds to perform, I don’t consider it to be of significant importance.
You should only do a unmodified binary copy of the iso to the device (NOT a partition on the device). openSUSE is boot ready needs no modes and never copy to a partition just direct to the USB
@gogalthorp, I didn’t do anything manually - I just reset the device by creating a new partition table. That operation doesn’t create any placeholder partitions by default, so the SUSE ImageWriter was provided with exactly what it should have been.
The sole error preventing me booting the storage device was me being enough of a moron to download the wrong ISO.
I downloaded that “wrong” iso and took a look. It can boot with legacy booting or with 32-bit EFI booting. It cannot boot with 64-bit EFI booting. I then tried it in the VM that I set up for testing 32-bit booting, and it did successfully boot there.
Thanks, @nrickert. I suppose it’s expected that it wouldn’t be able to boot via 64-bit EFI, even if it can do so via 32-bit EFI? I can’t imagine why someone would choose to use a 32-bit Linux ISO on a 64-bit machine.