How to check an ISO before you write it to a USB stick

Three questions, all answerable before you start

Did the download arrive intact? A truncated or corrupted ISO writes perfectly happily to a stick and then fails somewhere in the middle of booting, in a way that looks like a hardware problem.

Is the image bootable at all? Plenty of ISOs are not. A driver bundle, a documentation disc, a game, an application image — all perfectly valid ISO 9660 files with nothing to boot.

Bootable on which firmware? This is the one that costs people an afternoon. An image can carry a legacy BIOS boot catalogue, or a UEFI boot file, or both, or the wrong one for the machine in front of you. A UEFI-only image on a machine in legacy mode does nothing, and the machine says nothing useful about why.

Answer all three from the file and a failed boot afterwards is a hardware or firmware-settings problem, which is a much smaller search.

Check the hash, properly

The publisher prints a SHA-256 next to the download. Compare it:

shasum -a 256 ubuntu.iso            # macOS / Linux

Get-FileHash ubuntu.iso -Algorithm SHA256   # Windows

Two things people get wrong here. Compare the whole string, not the first six characters — that is exactly the part an attacker would match. And note that a hash matching only proves the file is the one whose hash you looked at; if you got the hash from the same page as a compromised download, it proves nothing. For anything that matters, check the publisher’s signature on the checksum file too.

What “bootable” looks like inside the file

An ISO is a filesystem with a defined structure, and the boot arrangements live in known places.

For legacy BIOS booting there is an El Torito boot catalogue — a record pointing at a boot image, with a platform ID saying what it is for. For UEFI there is a FAT image or an /EFI/BOOT/BOOTX64.EFI file the firmware knows to look for. Modern install media generally carry both, and a hybrid layout so the same file works written to a stick or burned to a disc.

Reading these does not require mounting the image, root, or any external library. They are at fixed offsets in a documented format. Which means a tool can tell you “bootable, UEFI only, x86-64” from the file on your desktop in under a second.

The rest of the failure modes

Once the image checks out, a stick that will not boot is usually:

• Secure Boot. The image is fine and unsigned, and the firmware refuses it. Either use signed media or turn Secure Boot off for the install.
• The wrong boot mode. UEFI versus legacy, set in firmware. Many machines will only show a USB stick in the boot menu under the mode it actually supports.
• The stick. Cheap flash drives fail at exactly this job, silently. If a second stick works, that was it.
• How it was written. Dragging the ISO’s contents onto the stick as files does not produce bootable media for most images. It needs writing as an image.

The programs for this

• RescueUSB answers all three questions before you write. verify hashes the image and compares it against the checksum you give it; the bootability check reports whether it is bootable and on which firmware. It only ever reads: it never writes to a device and never modifies an image.
• ISOPilot opens an ISO and pulls one file out of it — info parses the volume descriptor, list walks every directory record, extract pulls a file out by extent. No mounting, no root, no external libraries. Useful when you need one driver out of a 4 GB image.
• ImageDeck catalogues a whole folder of ISOs: which are byte-identical to each other and how much room that is wasting, which are bootable, and what has changed since the last index.
• BootBuilder goes the other way: it hand-writes a FAT32 image from a directory tree, then reads it back with code that shares nothing with the writer, so a bug cannot agree with itself. It does not install a bootloader — the image it produces is a filesystem, not bootable media.

Free while we are in preview, one file each, Windows and Mac.