How to Check if a USB Drive Is Bootable, Without Rebooting to Find Out

The usual method is to reboot and see what happens. It works, it costs you a reboot, and when it fails it tells you nothing about why.

There is a better way, and it is faster: a bootable stick has a handful of properties you can read while the machine is still running. Here they are, in the order that finds the problem quickest.

What “bootable” actually means, in two variants

A drive boots one of two ways, and the checks differ.

UEFI, which is nearly everything since about 2012, looks for a FAT32 partition containing /EFI/BOOT/BOOTX64.EFI. It does not read a boot flag, it does not care about the MBR, and it will happily boot a GPT or an MBR disk as long as that file is where it expects.

Legacy BIOS reads the first 512 bytes of the disk, expects boot code there, and follows a partition marked active.

Most Linux install images written with a proper tool satisfy both. A stick that fails to boot usually fails one of them specifically, which is why knowing which one your machine uses narrows the problem by half before you check anything.

On Linux, three commands

Find the device first, and be careful, because the wrong device name is how people erase the wrong disk:

lsblk -o NAME,SIZE,MODEL,TRAN

TRAN shows usb for removable drives. Confirm the size matches your stick before going further.

The partition table and the boot flag:

sudo fdisk -l /dev/sdX

Look for Disklabel type and, in the partition list, an asterisk in the Boot column. A missing asterisk matters only for legacy BIOS boot.

The EFI file, which is the decisive check on any modern machine:

sudo mount /dev/sdX1 /mnt
ls /mnt/EFI/BOOT/
sudo umount /mnt

BOOTX64.EFI present means a UEFI machine will find it. Absent means it will not, whatever else is on the drive.

The boot sector, for legacy:

sudo dd if=/dev/sdX bs=512 count=1 2>/dev/null | hexdump -C | tail -2

The last two bytes should be 55 aa. All zeros means there is no boot code in the MBR.

On Windows

In an elevated PowerShell:

Get-Disk | Format-Table Number, FriendlyName, PartitionStyle, Size

PartitionStyle tells you GPT or MBR. Then, with the drive letter assigned:

Test-Path E:\EFI\BOOT\BOOTX64.EFI

True means a UEFI machine has something to boot. For legacy sticks, diskpart, then list disk, select disk N, detail disk shows whether the disk is marked active.

On macOS

diskutil list
diskutil info /dev/diskN

Then mount the EFI partition and look for the same file. macOS will not boot a generic UEFI stick the way a PC does, so on Apple hardware this check tells you about the stick, not about whether that Mac will accept it.

The check none of these perform

Every command above reads structure. None of them reads integrity.

A stick can have a perfect partition table, a boot flag, and a BOOTX64.EFI of the right size, and still fail because the image was written to the wrong device, truncated, or corrupted in transfer. The structure is a copy of the first few kilobytes; the failure is somewhere in the other four gigabytes.

The check that covers that is the checksum published alongside the image, verified against the file you wrote, before you write it:

sha256sum ubuntu-24.04.iso

Compare it, character by character, with the value on the download page. A signed checksum file verified with GPG is better still, because it tells you the checksum itself was not swapped, which matters when you did not download over a connection you control.

If the checks pass and it still does not boot

At that point the drive is fine and the machine is the variable. In descending order of frequency:

• Secure Boot rejects an unsigned bootloader. Most mainstream distributions are signed; custom or older images often are not. Our Secure Boot explainer covers what it verifies and what it does not.
• The boot mode does not match the stick, UEFI firmware against a legacy-only image or the reverse. This is the single most common cause once the file checks pass.
• The USB port, particularly USB 3 ports on some firmware, and front panel ports on desktops. Trying a different port costs ten seconds and resolves this more often than it should.

If you are writing a privacy focused image, the same checks apply, and the verification step matters more rather than less: see installing Tails on a USB drive. For a stick that carries data rather than an operating system, encrypting it is a separate and worthwhile step.