I've replaced all my GPT disklabels with Sun disklabels because I refuse to let them talk.

UEFI still boots. Spec said it can boot from fat in an eltorito floppy image and sun disklabels sit in the second or so sector. Spec also said it abstracts the type of volume so all boot methods always work for all drives. ISO images don't use the first 4kB so it doesn't see there's disklabel at all

So now I can mount the ssd as iso9660 but there's also partitions on it of which the third spans the entire drive (of course, because that's the c partition)

Downvote-a-bots are not capable of actual thinking.

What you sometimes need is a USB stick having a native "geometry" in terms of HDD emulation ability, that will be recognized properly by the particular series of chipset on the target mainboard.

Then the data bits written to a fully-zeroed drive must conform to what is expected of a bootable device on the target mainboard, for one thing the partition(s) often needs to be well-aligned with the underlying storage hardware to a more particular degree than merely when it is a "perfectly" readable & writeable drive.

Many new USB sticks fail at this fundamental point because the factory partitioning & formatting was accomplished using an image not exactly appropriate after the vendors of the silicon storage or controller chips make hardware revisions.

Analogously, also why writing an IMG or dd from a not-very-identical stick, or with dissimilar partitioning and/or formatting is quite hit or miss.

Sometimes freshly reformatting is enough for problem sticks, other times they can not be made to boot without repartitioning. Either way a fresh reformat or repartition may simply overwrite using (proven nonoptimal) disk structures still remaining in place unless the device is zeroed beforehand. Sometimes a reboot is needed for an OS to forget the structure that was recognized during most recent insertion.

I like Ventoy (and Rufus) but for best results I start with a proven bootable stick which I prepare manually from a zeroed stick and verify bootability beforehand. Similar preparation when getting ready to manually write reliable plain Windows Setup USBs from the mounted ISO.

As someone who isn’t afraid of reproducible binary blobs but would absolutely pay attention to a failure-to-reproduce report from an advocate otherwise, I’m disappointed to see you failing to do so here. If you’re afraid and not willing to prove or disprove your fears yourself, then that negates your arguments to reject binary blobs categorically, rather than conditionally as I and others in this thread are accepting. So.. of this isn’t an argument about whether this project is safely using binary blobs, it’s about propagating the belief that binary blobs are never acceptable; then while normally I would dig up proof like you seek or make it myself, proof has no bearing on beliefs and I’d best not.

My concern is that they grabbed some random driver signed by a random person and just assumed it was trustworthy enough to be included in a project. That's not the behavior I associate with how "extremely trustworthy" projects should be run. I understand others may not agree, though. I also understand that this is a different project, but that behavior kinda makes me feel like any project with those people involved shouldn't be viewed as extremely trustworthy. Are they also running randomly grabbed code on the build machines and assuming it's safe to do so?

To sibling comment: I don't understand your line of reasoning. How does using someone's software make you trust them? Don't you need trust to run someone's software first?

Because you intend to run their software? And don't try to tell me you've never ran any proprietary software.

It depends on what customizations you'd like to use.

I've also had a very hard time creating an automated install media for an appliance for windows iot... Worst was the (LLM generated?) powershell scripts in the documentation that didn't work at all.

Microsoft's tooling for customizing images amounts to several gigabytes to download and install just to get started.

The Windows approach is based on a mix of relatively limited offline modifications and automating clicks and keystrokes (AutoUnattend.xml, OOBE.xml) and recording or forgetting manual changes (Audit Mode, Sysprep). Both are insanely kludgey.

New development of the tooling always comes to dism.exe first rather than the DISM PowerShell module, so you may need to use DOS commands instead of the (very lovely) modern shell that Microsoft maintains.

Depending on what kind of stuff you're trying to install, you might need to do half a dozen reboots in the course of recording your manual changes.

Mounting/unmounting a WIM file can take more than a minute (wtf?) and if you're working on modifying one of the installer images from upstream, you need dozens of gigabytes of free disk space.

If you don't just want install media, but a bootable repair environment, everything is even worse. Hardware recognition is bad, boot is slow, and only some programs can actually run in a WinPE environment.

Have you ever customized bootable Linux media?

When I had to make some custom NixOS install media for an aarch64 VPS, it required only a few lines of code in the exact same environment as I use to customize running systems, and it's completely declarative, non-interactive, requires no special toolkit, doesn't require dozens of gigabytes of scratch space, never requires me to boot anything...

Teenage interns can also shovel manure, but that doesn't make it pleasant or painless!