Create a Bootable USB That Actually Boots (UEFI/Legacy Done Right)

The mental model: what “bootable” actually means

When people say “make a bootable USB,” they usually mean: “Put an ISO on a stick so firmware finds it, loads a bootloader, and the bootloader loads a kernel or installer.” That’s one sentence hiding three independent systems that fail independently:

• The USB media and partitioning: does the stick present a sane partition table and filesystems the firmware can read?
• The firmware boot path: UEFI or BIOS (Legacy). Each has different expectations about partitions, boot sectors, and filesystem layout.
• The bootloader chain: EFI executable, GRUB/syslinux, Windows boot manager, etc. It must match the machine’s mode (UEFI vs Legacy) and CPU architecture.

Reliability comes from controlling variables. “I used a GUI tool and it worked once” is not control. Control is: verify the ISO, write it in a mode appropriate for the ISO type, confirm the stick’s partition layout, and confirm the machine is attempting the right boot mode.

Also: your firmware is not your friend. It is an overconfident librarian with a strict filing system and no empathy. You either label the books correctly or you don’t get service.

Interesting facts and historical context

Knowing why things are the way they are helps you stop guessing. Here are some concrete bits of history that show up in today’s boot problems:

1. BIOS boot came from disks that had no partitions at all. The original boot sector model predates modern partitioning. That’s why “boot code in the first 446 bytes” still matters in 2026.
2. MBR’s partition table was always cramped. Four primary partitions felt generous until it wasn’t; that’s one reason extended partitions exist, and also why people flee to GPT.
3. UEFI standardized booting as “load an EFI executable from a filesystem.” That’s a huge shift: firmware can read FAT filesystems and execute files like BOOTX64.EFI.
4. The “EFI System Partition” (ESP) is usually FAT32 for a reason. FAT is simple and widely supported in firmware, unlike ext4, NTFS, or fancy journaling filesystems.
5. Secure Boot isn’t encryption; it’s signature enforcement. It refuses to run EFI binaries not signed by keys the firmware trusts.
6. Hybrid ISOs exist because vendors wanted one image for many boot paths. Some Linux ISOs are ISO9660 images with embedded partition tables so you can dd them directly to USB.
7. Windows install media has long had opinions about FAT32 and file size. The install.wim file can exceed 4 GiB, which FAT32 can’t store; many creation tools split it or switch to NTFS—with consequences for UEFI firmware compatibility.
8. UEFI boot entries can be “sticky” and misleading. Firmware NVRAM remembers entries that point to devices that no longer exist, which is how you get phantom boot options and false confidence.
9. USB sticks lie. Some are “fixed disk” vs “removable” in ways that change how Windows tools behave; some controllers are flaky under sustained writes and silently corrupt data.

One quote worth keeping on your desk:

“paraphrased idea” — Gene Kranz: rigorous discipline and clear procedures prevent avoidable failures.

Choose your USB creation method (and why)

Method A: Raw write the ISO (best for hybrid Linux ISOs)

If the ISO is designed to be written “as-is” to USB (common for Linux installers), the most reliable method is a raw write. You are cloning the image layout the distro tested. No creative reinterpretation by tooling. No “helpful” reformat that breaks UEFI boot.

Use this when:

• The ISO is a modern Linux installer and the vendor explicitly supports dd or raw imaging.
• You want the simplest chain of custody: checksum → write → boot.

Avoid this when:

• You’re building Windows install media from an ISO (raw-writing Windows ISOs usually does not produce bootable USB in the way you expect).
• You need persistent storage on the same USB without additional steps.

Method B: File copy onto a properly prepared ESP (best when you control layout)

For UEFI boot, what matters is: a FAT32 partition with \EFI\BOOT\BOOTX64.EFI (or the architecture equivalent). You can build that deliberately. This is great when you need custom bootloaders, custom kernel args, or you’re building rescue media in a controlled environment.

Method C: Use a multiboot tool (Ventoy-style) when you value flexibility

These tools install a bootloader once, then you copy ISOs as files. It’s convenient and often works, but it’s not magic. Some Secure Boot setups block it, some odd firmware implementations hate it, and some ISOs require special handling.

This is the “carry a lot of wrenches” option. Great for field work. Not my first pick for a compliance-heavy environment.

Joke #1: A bootable USB is like a parachute—if it’s “probably fine,” you’ll learn something new very quickly.

Practical tasks: commands, outputs, and decisions (12+)

These are field-tested tasks. Each includes the command, example output, what the output means, and the decision you make. Run them on Linux; if you’re on macOS or Windows, translate the ideas, not the syntax.

Task 1: Identify the USB device correctly (before you destroy a disk)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,TRAN,RM,FSTYPE,MOUNTPOINTS
NAME   SIZE MODEL            TRAN RM FSTYPE MOUNTPOINTS
sda   953.9G Samsung_SSD      sata  0        
├─sda1  512M                  0    vfat   /boot/efi
├─sda2  200G                  0    ext4   /
└─sda3  753G                  0    ext4   /var
sdb    28.9G SanDisk_Ultra     usb  1        
└─sdb1 28.9G                   1    exfat  /media/cr0x/USB

What it means: sdb is removable (RM=1) and USB transport. That’s your target stick.

Decision: If the target isn’t clearly removable USB, stop. Re-run with the stick unplugged/plugged to confirm the delta.

Task 2: Confirm nothing is mounted from the target device

cr0x@server:~$ mount | grep -E '^/dev/sdb'
/dev/sdb1 on /media/cr0x/USB type exfat (rw,nosuid,nodev,relatime)

What it means: The OS is actively using the filesystem.

Decision: Unmount before imaging; otherwise you risk corruption and “it wrote fine but doesn’t boot.”

Task 3: Unmount cleanly

cr0x@server:~$ sudo umount /dev/sdb1
cr0x@server:~$ echo $?
0

What it means: Exit code 0 means success.

Decision: If unmount fails due to “busy,” close file managers, terminals cd’d into it, or use lsof to find blockers.

Task 4: Verify the ISO checksum (don’t debug a corrupt download)

cr0x@server:~$ sha256sum ubuntu-24.04.1-live-server-amd64.iso
d7b1e3c3f8f2b6d7d8a4c1c6f0d2a0b3a4d7c5a0b8f2e1d3c4b5a6f7e8d9c0b1  ubuntu-24.04.1-live-server-amd64.iso

What it means: You have a deterministic hash you can compare to the vendor’s published value.

Decision: If it doesn’t match, delete and re-download. Do not “try it anyway.” That’s how you waste afternoons.

Task 5: Inspect whether the ISO is a hybrid image (clue for raw write)

cr0x@server:~$ file ubuntu-24.04.1-live-server-amd64.iso
ubuntu-24.04.1-live-server-amd64.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Ubuntu-Server 24.04.1 LTS amd64'

What it means: “DOS/MBR boot sector” suggests a hybrid ISO with embedded boot structures.

Decision: Prefer raw write (dd or equivalent) for this type of image.

Task 6: Raw-write the ISO to the USB (Linux)

cr0x@server:~$ sudo dd if=ubuntu-24.04.1-live-server-amd64.iso of=/dev/sdb bs=4M conv=fsync status=progress
1562378240 bytes (1.6 GB, 1.5 GiB) copied, 32 s, 48.8 MB/s
2971666432 bytes (3.0 GB, 2.8 GiB) copied, 61 s, 48.7 MB/s
4026531840 bytes (4.0 GB, 3.8 GiB) copied, 83 s, 48.5 MB/s
4630511616 bytes (4.6 GB, 4.3 GiB) copied, 96 s, 48.2 MB/s
1103+1 records in
1103+1 records out
4630511616 bytes (4.6 GB, 4.3 GiB) copied, 96.1312 s, 48.2 MB/s

What it means: The image was written fully, and conv=fsync forces data flush.

Decision: After dd, don’t yank the stick immediately. Let udev settle, then validate the layout.

Task 7: Force the kernel to re-read the partition table

cr0x@server:~$ sudo partprobe /dev/sdb
cr0x@server:~$ lsblk -f /dev/sdb
NAME   FSTYPE FSVER LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sdb                                                                   
├─sdb1 iso9660      Ubuntu-Server 2024-08-28-14-10-41-00             0     100%  
└─sdb2 vfat   FAT16 UEFI_BOOT   2A1B-3C4D                            

What it means: You now have an ISO9660 partition and a small FAT partition for UEFI boot. This is typical of many hybrid images.

Decision: If you don’t see a FAT partition and you expect UEFI boot, inspect the ISO; some images are legacy-only or rely on other structures.

Task 8: Confirm the UEFI fallback path exists on the stick

cr0x@server:~$ sudo mkdir -p /mnt/usb-uefi
cr0x@server:~$ sudo mount /dev/sdb2 /mnt/usb-uefi
cr0x@server:~$ sudo find /mnt/usb-uefi/EFI -maxdepth 2 -type f
/mnt/usb-uefi/EFI/BOOT/BOOTX64.EFI
/mnt/usb-uefi/EFI/BOOT/grubx64.efi

What it means: Firmware that can’t or won’t use NVRAM entries can still boot via the default path \EFI\BOOT\BOOTX64.EFI.

Decision: If BOOTX64.EFI is missing, UEFI boot is likely dead on arrival unless the vendor provides a different path and you add an entry manually.

Task 9: Validate the ISO was written correctly by sampling bytes

cr0x@server:~$ sudo cmp -n 1048576 ubuntu-24.04.1-live-server-amd64.iso /dev/sdb && echo "first 1MiB matches"
first 1MiB matches

What it means: The start of the device matches the ISO. This catches a surprising number of “controller lied” problems.

Decision: If it differs, try a different USB port, disable USB selective suspend, or replace the stick. Debugging a failing $8 device is a hobby, not operations.

Task 10: Check for GPT vs MBR on the USB (helps explain firmware behavior)

cr0x@server:~$ sudo fdisk -l /dev/sdb | sed -n '1,20p'
Disk /dev/sdb: 28.9 GiB, 31016853504 bytes, 60579840 sectors
Disk model: SanDisk Ultra
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6e9b2a1c

What it means: This stick uses an MBR (“dos”) label. Many hybrid ISOs do.

Decision: If you need GPT explicitly (some enterprise firmware behaves better), consider a file-copy method with a GPT partition table and a FAT32 ESP.

Task 11: Create a deliberate GPT + FAT32 ESP (for custom UEFI boot media)

cr0x@server:~$ sudo wipefs -a /dev/sdb
cr0x@server:~$ sudo parted -s /dev/sdb mklabel gpt
cr0x@server:~$ sudo parted -s /dev/sdb mkpart ESP fat32 1MiB 1025MiB
cr0x@server:~$ sudo parted -s /dev/sdb set 1 esp on
cr0x@server:~$ sudo mkfs.vfat -F32 -n UEFI_INSTALL /dev/sdb1
mkfs.fat 4.2 (2021-01-31)

What it means: You now have a clean ESP-sized FAT32 partition with the correct GPT flag.

Decision: Use this when you’re constructing media manually (custom EFI binaries, signed shims, a vendor-specific rescue environment).

Task 12: Copy the EFI bootloader into the fallback path

cr0x@server:~$ sudo mount /dev/sdb1 /mnt/usb
cr0x@server:~$ sudo mkdir -p /mnt/usb/EFI/BOOT
cr0x@server:~$ sudo cp BOOTX64.EFI /mnt/usb/EFI/BOOT/BOOTX64.EFI
cr0x@server:~$ sudo ls -l /mnt/usb/EFI/BOOT
total 1312
-rwxr-xr-x 1 root root 1343488 Feb  4 09:10 BOOTX64.EFI

What it means: The firmware has a standard place to look, regardless of NVRAM state.

Decision: If you’re supporting mixed hardware, always include the fallback path. It’s cheap insurance.

Task 13: Verify the machine booted in UEFI mode (from the live environment)

cr0x@server:~$ test -d /sys/firmware/efi && echo "UEFI mode" || echo "Legacy mode"
UEFI mode

What it means: Linux exposes UEFI runtime services via /sys/firmware/efi.

Decision: If you expected UEFI but got Legacy, stop blaming the USB. Fix the firmware boot mode selection.

Task 14: Inspect existing UEFI boot entries (helps when firmware is confused)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0007,0003,0001
Boot0001* ubuntu	HD(1,GPT,2f1c...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0003* UEFI: SanDisk, Partition 2	PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/HD(2,MBR,0x6e9b2a1c,0x3a00,0x8000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0007* UEFI: Built-in EFI Shell	FvFile(7C04...)

What it means: The firmware sees the USB’s EFI file path, and you can confirm which one actually booted (BootCurrent).

Decision: If the USB entry isn’t present but the stick has \EFI\BOOT\BOOTX64.EFI, use the one-time boot menu; some firmware won’t auto-enroll it.

Task 15: Detect Secure Boot state (common “why does it instantly fail” culprit)

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

What it means: Unsigned EFI binaries won’t run unless enrolled keys allow them.

Decision: If your USB uses an unsigned bootloader, either disable Secure Boot for the install, or use a signed shim-based chain.

UEFI vs Legacy: how the machine decides what to boot

Legacy BIOS boot in one paragraph

Legacy BIOS looks at the first sector of the disk (MBR) and executes code there. That code then finds a “next stage” bootloader somewhere else. This is why tiny details—like where the bootloader expects to find stage2—matter. It’s also why filesystem type doesn’t directly matter to BIOS at first: BIOS isn’t reading files; it’s running boot code.

UEFI boot in one paragraph

UEFI reads partitions, mounts a filesystem (usually FAT), and loads an EFI executable. It can do this via NVRAM boot entries (explicit paths), or via the fallback path \EFI\BOOT\BOOTX64.EFI. UEFI is cleaner, but firmware implementations vary wildly, especially around filesystem support and removable media behavior.

The key compatibility rules you should live by

• If you want UEFI boot everywhere: Provide a FAT32 partition that contains \EFI\BOOT\BOOTX64.EFI.
• If you want Legacy boot everywhere: Ensure there’s valid MBR boot code, and the bootloader supports BIOS mode.
• If you want both: Use vendor-provided hybrid ISOs, or build media that supports both chains. Do not assume “UEFI-capable” media will boot in Legacy mode, or vice versa.
• Don’t mix modes mid-install. Installing an OS in UEFI mode typically requires an ESP on the target disk; installing in Legacy uses different boot sectors. Mixing leads to the classic “it installed but won’t boot” tragedy.

Joke #2: Firmware setup menus are the only place where “Save & Exit” feels like a threat.

Secure Boot: when “works” becomes “blocked”

Secure Boot is the reason a USB boots fine on an older server but faceplants on a newer laptop with a corporate image. The firmware checks signatures of EFI binaries before executing them. If the binary isn’t signed by a trusted key, it won’t run. Some firmware will show a message; some will silently refuse and fall back to the next boot option, which looks like “USB not detected.” It was detected. It was rejected.

What to do in real environments

• For mainstream Linux installers: use images that include a signed shim and signed GRUB. Most do.
• For custom rescue tools: either sign your EFI binaries and enroll your key (MOK or firmware DB), or plan a controlled Secure Boot disable procedure.
• For Windows media: stick to the officially supported creation path, because Windows boot components are signed and expected to match.

In an enterprise setting, disabling Secure Boot might be forbidden except under break-glass procedures. In that case, your USB creation method is not a personal preference; it’s a compliance constraint.

Three corporate mini-stories (anonymized, plausible, and technically real)

Incident #1: The wrong assumption (UEFI is “basically BIOS, right?”)

A mid-size company rolled out a new fleet of laptops for developers. The build team made an internal “golden” Linux installer USB. It booted on the test bench, which was a couple of older desktops configured for Legacy BIOS because that’s what the bench had always been.

On the new laptops, the USB showed up in the one-time boot menu—twice, even: once as “UEFI: USB” and once as “USB HDD.” The techs picked the one that sounded familiar. “USB HDD” felt comforting. It booted to a black screen and then back to the boot menu. They concluded the image was bad.

They rebuilt the USB. Same result. They tried different sticks. Same result. The real issue: the laptops were configured to disallow Legacy boot entirely. “USB HDD” was the Legacy path. The UEFI entry worked, but only if selected. Nobody had told the build team that the new fleet was UEFI-only and Secure Boot-on.

Once they selected “UEFI: USB,” the installer loaded immediately. The fix was operational: update the runbook to explicitly instruct techs to choose the UEFI entry, and update the imaging process to verify /sys/firmware/efi in the live environment before proceeding. The postmortem conclusion was not “people should know better.” It was “we shipped a process that depended on tribal knowledge.”

Incident #2: An optimization that backfired (NTFS for speed, UEFI for sadness)

A different organization built Windows installer USBs for an internal refresh program. Someone noticed that writing a FAT32 stick was slower and sometimes failed when the install.wim exceeded 4 GiB. The “optimization” was to format the USB as NTFS and copy the files, because NTFS handles big files and copying is faster than image writing.

It worked on most desktops. Then it hit a batch of small-form-factor machines with firmware that refused to boot UEFI from NTFS on removable media. The boot menu still listed the stick, but selecting it just returned to the menu. Technicians blamed the hardware batch and opened a vendor case.

The vendor response was boring: “UEFI firmware is only required to support FAT for removable boot.” NTFS support is optional. Their devices didn’t implement it. The “optimization” was effectively a compatibility regression. The fleet now had two classes of hardware, and the USB worked on one class.

The fix was also boring: go back to FAT32 and split the WIM, or use a tool that builds a dual-partition stick (small FAT32 ESP for boot + NTFS partition for large install files) with a bootloader that can read NTFS. The postmortem lesson: speed optimizations that change filesystem format are not optimizations; they are product decisions with blast radius.

Incident #3: The boring practice that saved the day (checksums and a known-good stick)

A financial services team kept a “break-glass” USB kit for server recovery. The kit included a vetted Linux rescue ISO and two specific USB stick models purchased in bulk. The runbook required verifying the ISO hash, then writing the image with raw write, then verifying the first MiB with cmp.

It sounded like ceremony. It was. And it worked.

During an ugly outage, they needed to boot a machine that had a corrupted bootloader after a failed disk replacement. The first USB they grabbed didn’t boot. Instead of spiraling, the on-call followed the runbook: they checked the stick layout, confirmed UEFI mode, and tested the stick on a second host. It failed there too.

They moved to the second stick—same ISO, same procedure—and it booted immediately. The first stick was physically failing. Because they had deterministic verification steps and a spare known-good model, they didn’t waste an hour reinventing blame. They restored the bootloader and ended the incident. The lesson wasn’t sexy: redundancy and verification in the “simple stuff” reduces MTTR like nothing else.

Fast diagnosis playbook

This is the order that finds the bottleneck quickly. Don’t freestyle. Follow the chain from “can firmware see it” to “can it execute it” to “can the bootloader continue.”

First: confirm the machine’s boot mode and policy

• Check firmware settings: Is Legacy boot disabled? Is Secure Boot enabled? Is USB boot allowed?
• In the boot menu: do you see separate entries for UEFI vs Legacy for the same stick?
• Decision: If the environment is UEFI-only, stop trying Legacy media. If Secure Boot is enforced, stop trying unsigned bootloaders.

Second: confirm the USB was written correctly (not “copied” incorrectly)

• Verify ISO checksum.
• Confirm stick layout with lsblk and fdisk -l.
• Confirm presence of \EFI\BOOT\BOOTX64.EFI for UEFI boot.
• Decision: If the layout is wrong, re-create the stick using a method appropriate for that ISO.

Third: determine which failure class you’re in

• USB not listed at all: hardware/port, firmware USB boot disabled, dead stick.
• USB listed but returns to menu: Secure Boot rejection, wrong architecture EFI, missing fallback path, firmware can’t read filesystem.
• Bootloader starts then errors: corrupted write, missing files, kernel/initrd mismatch, bad config, bad ISO.
• Installer starts but can’t see disks: storage drivers, RAID/HBA mode, VMD, RST, or controller settings—not a USB problem.

Fourth: validate from inside a working live environment

• Confirm mode with /sys/firmware/efi.
• Check Secure Boot state with mokutil.
• Inspect UEFI boot entries with efibootmgr (if installed).
• Decision: If your mode isn’t what you think, fix that before anything else.

Common mistakes: symptoms → root cause → fix

1) Symptom: USB doesn’t appear in the boot menu

Root cause: USB boot disabled, bad port (front panel hubs can be flaky), dead stick, or firmware only enumerates USB at cold boot.

Fix: Enable USB boot in firmware; try a rear motherboard port; try USB 2.0 port if available (some firmware chokes on USB 3.x init); power-cycle fully; test stick on another host.

2) Symptom: USB appears, but selecting it returns immediately to the boot menu

Root cause: Secure Boot rejection, missing BOOTX64.EFI, wrong EFI architecture (x86_64 vs ARM64), or UEFI can’t read the filesystem (NTFS/exFAT).

Fix: Use FAT32 for the ESP; ensure \EFI\BOOT\BOOTX64.EFI exists; use a signed boot chain or disable Secure Boot (if allowed); ensure correct ISO for the hardware architecture.

3) Symptom: Boots on one machine, not on another

Root cause: One boots in Legacy mode, the other in UEFI mode; or one enforces Secure Boot; or one firmware supports NTFS boot and the other doesn’t.

Fix: Standardize on UEFI boot and FAT32 ESP with fallback path; document which boot menu entry to select; avoid NTFS-only UEFI boot assumptions.

4) Symptom: GRUB starts, then “unknown filesystem” or “file not found”

Root cause: Partial write, bad stick, or GRUB config points to the wrong UUID/device because the media layout differs.

Fix: Re-create the stick with raw write; verify with cmp; replace suspect hardware; avoid “manual remixing” of ISO contents unless you understand the bootloader config.

5) Symptom: Windows installer USB boots in Legacy but not in UEFI

Root cause: Stick formatted NTFS with no FAT32 ESP; firmware requires FAT32 to boot UEFI from removable media.

Fix: Build Windows media with a FAT32 boot partition; if files exceed 4 GiB, split WIM or use a dual-partition approach with a FAT32 boot partition.

6) Symptom: Installer boots, but target disk isn’t visible

Root cause: Storage controller mode (RAID/VMD/RST), missing driver, or NVMe behind a vendor abstraction.

Fix: Adjust BIOS storage mode (AHCI vs RAID) as required; load vendor driver in installer; update firmware; validate with lspci and lsblk in the live environment. This is not solved by rewriting the USB five times.

Checklists / step-by-step plan

Plan A: Make a Linux installer USB that boots UEFI reliably (recommended)

1. Download the ISO and the vendor-provided checksum value.
2. Verify checksum with sha256sum. If mismatch: re-download.
3. Identify the USB device with lsblk. Confirm it’s removable and the size matches.
4. Unmount partitions on that device.
5. Raw-write the ISO with dd using conv=fsync.
6. Re-read partitions with partprobe and confirm layout.
7. Confirm UEFI boot file exists: mount the FAT partition and check \EFI\BOOT\BOOTX64.EFI.
8. Test on two machines: one modern UEFI-only, one older mixed-mode. Record which boot menu entry works.

Plan B: Build a custom UEFI boot USB (for rescue media or internal tooling)

1. Start with a known-good USB model. Buy multiples. Seriously.
2. wipefs -a the device to remove conflicting signatures.
3. Create GPT, then an ESP FAT32 partition (at least 512 MiB; I prefer 1 GiB for convenience).
4. Place your EFI binary at \EFI\BOOT\BOOTX64.EFI.
5. If Secure Boot is enabled in your environment, ensure the EFI binary is signed appropriately or provide a signed shim chain.
6. Validate from a test host using efibootmgr -v and by selecting “UEFI: USB” in the one-time boot menu.

Plan C: Support both UEFI and Legacy without tears

1. Prefer vendor hybrid ISOs that explicitly support both modes.
2. If you must customize: build separate UEFI and Legacy sticks, label them physically, and stop pretending one stick can satisfy every firmware edge case.
3. Document which mode is required for installing the OS image you ship (UEFI recommended). Enforce it in the install checklist.

Operational hygiene checklist (the boring stuff)

• Keep one “known-good” USB stick sealed as a control.
• Keep hashes in your internal runbook for approved images.
• Record firmware settings required (Secure Boot policy, Legacy boot policy, SATA/RAID mode).
• When debugging, change one variable at a time. The universe punishes parallel guessing.

FAQ

1) Why does raw-writing an ISO sometimes create multiple partitions?

Because many installer ISOs are “hybrid” images that include partition tables (often MBR, sometimes GPT). When written to a disk, the OS sees those partitions.

2) Why can’t I just copy the ISO file onto a USB and boot it?

Firmware typically doesn’t boot from an ISO file sitting on a random filesystem. It boots via boot sectors (Legacy) or EFI executables on a FAT filesystem (UEFI). Multiboot tools add a bootloader that understands ISO files; plain firmware usually doesn’t.

3) GPT or MBR for a bootable USB?

For UEFI, GPT with an ESP is clean and predictable. For Legacy BIOS, MBR matters. Hybrid Linux ISOs often use MBR because it’s widely compatible. If you’re building custom media for modern fleets, GPT + FAT32 ESP is usually the right default.

4) My USB is FAT32 but still won’t boot in UEFI. Why?

Common reasons: missing \EFI\BOOT\BOOTX64.EFI, wrong architecture (ARM vs x86_64), Secure Boot rejecting the binary, or buggy firmware that needs the stick inserted before power-on.

5) Secure Boot is enabled. Do I have to disable it to boot Linux installers?

No, not necessarily. Many mainstream installers ship a signed shim and signed bootloader that work with Secure Boot. Custom-built EFI binaries often won’t unless you sign them and the firmware trusts the signing key.

6) Why does the boot menu show two entries for the same USB?

One is the UEFI boot path and one is Legacy/CSM. Pick the one that matches how you intend to install. If you want a UEFI install, choose the UEFI-labeled entry.

7) The installer boots, but after installation the machine won’t boot. Is the USB wrong?

Usually no. That’s typically an install-mode mismatch (installed in Legacy without proper MBR setup, or installed in UEFI without an ESP), or target disk boot order/NVRAM entry issues. Verify whether the installer ran in UEFI mode and whether the target disk has an ESP.

8) Why do some Windows USB creation methods fail on certain PCs?

UEFI is required to support FAT for removable boot, but not required to support NTFS. A Windows USB that relies on NTFS boot may work on some firmware and fail on others.

9) Is exFAT a good choice for bootable USBs?

For UEFI boot: usually no. Many firmware implementations don’t boot from exFAT. Use FAT32 for the boot partition.

10) What’s the single best sanity check once I’ve written the USB?

Mount the ESP (or the FAT partition) and confirm \EFI\BOOT\BOOTX64.EFI exists. Then test the stick on a second machine. If it only works on one host, you’re not done.

Conclusion: practical next steps

If you want a bootable USB that actually boots, stop treating it like arts and crafts. Treat it like a deployment artifact. Verify the input (checksum), use the right creation method for the ISO type, and confirm the firmware-facing contract: a usable partition layout and a valid UEFI fallback path.

Next steps you can do today:

• Pick one approved USB stick model and buy a small batch. Retire the mystery sticks.
• Standardize on UEFI installs unless you have a specific Legacy requirement you can defend.
• Add three checks to your runbook: sha256sum match, lsblk sanity, and presence of \EFI\BOOT\BOOTX64.EFI.
• When it fails, run the fast diagnosis playbook in order. The goal is fast isolation, not heroic tinkering.

The best bootable USB is the one you tested last week on two different machines, not the one you “made once and kept in a drawer.” Firmware changes. People change. Drawers are eternal.