A drive that will not start is frustrating mostly because the machine tells you so little. But the number of things that can be wrong is small, and they sit in layers. Check them in order and you will usually find the answer within a few minutes.
Layer 1: is the drive visible at all
Enter the firmware boot menu — commonly F12, F11, Esc or F9 during power-on, depending on the manufacturer — and look for the drive by name.
- Not listed. Try another port, preferring one directly on the machine over a hub or a front panel. Confirm the drive mounts on a running computer. Some firmware also hides removable media until USB boot support is enabled in setup.
- Listed once. Note whether the entry has a UEFI prefix; that tells you which route the firmware will take.
- Listed twice. That is normal, and it is your most useful diagnostic. The two entries are the two boot modes.
Layer 2: boot mode
If the drive appears but stops immediately, the mode is the first suspect. Pick the other entry and try again. If only one entry exists and it is the wrong mode for your image, look in firmware setup for whether compatibility support is available — on recent hardware it often is not, in which case you need an image that supports UEFI.
A drive that works on an older desktop and not on a new laptop is usually a mode problem, not a hardware problem. The newer machine has no compatibility layer to fall back on.
Layer 3: signature verification
If the firmware reports a verification or security failure, the loader on the drive is not signed by a key the machine recognises. Mainstream distribution images generally are; specialised, older or self-built images often are not. A firmware update can also revoke a loader that previously worked, so an old rescue drive failing after an update points here.
The straightforward fix is a current image from a publisher that supports signature checking. The setting itself lives in firmware setup, and the vendor documents where — but on a machine you do not own, changing it may not be yours to do.
Layer 4: the image
If the loader starts and presents its menu, but the image you choose fails, attention moves to the image itself.
- Verify the checksum against the publisher's figure. Truncated downloads are extremely common and present as strange, inconsistent failures.
- Check the loader project's compatibility list. Some images need a specific option or are known not to work.
- Try a different image you have used successfully before. If that one works, the problem is the file, not the drive.
- Read the exact error text. "No such device" and "kernel panic" point in completely different directions.
Layer 5: the drive
Hardware is the last layer because it is the least likely and the most expensive to conclude. Signs that point here: transfers that fail near the end, checksums that differ each time you compute them, a drive that disconnects during long reads, or one that reports a capacity larger than it can actually store.
That last symptom deserves particular suspicion on unusually cheap high-capacity drives. Testing tools that write and read back the full capacity will reveal it, and a drive that fails such a test should be retired rather than reformatted.
Symptom to layer, quickly
| What you see | Start at |
|---|---|
| Drive absent from the boot menu | Layer 1 — port, cable, firmware setting |
| Selected, then straight back to the boot menu | Layer 2 — boot mode |
| A security or verification message | Layer 3 — signature checking |
| Loader menu appears, chosen image fails | Layer 4 — that image |
| Different failure each attempt | Layer 5 — the drive itself |
Recording what you find
If you carry a drive to many machines, keep a plain text file on it noting which models needed which settings. Firmware behaviour is remarkably consistent within a product line and remarkably inconsistent between them, and four lines of notes will save you the same twenty minutes next year.