Every computer needs something to run before the operating system exists in memory. That something is firmware: code stored on the motherboard that brings the hardware to a usable state and then hands control to a loader on a disk. Two designs are still in circulation, and they hand over control in very different ways.
The legacy route
The older design, inherited from the original PC, is simple to describe. Firmware initialises hardware, then reads the very first sector of the chosen disk into memory and jumps to it. That sector holds a few hundred bytes of code — enough to find and start a larger loader elsewhere on the disk, which in turn starts the operating system.
The design's virtue is that it asks almost nothing of the disk. Its cost is that the first sector is a very small place to put a program, so real loaders are always split across several stages, each finding the next.
The UEFI route
UEFI replaces the jump-to-sector-zero handoff with something closer to a miniature operating system. The firmware understands a file system — the EFI System Partition, or ESP — and runs a program from it. That program is a normal file with an .efi extension, stored in a predictable folder.
Because firmware can read files, it can also keep a list of boot entries in non-volatile memory: this entry points at that file on that partition, with this label, in this order. Tools inside the operating system can add and reorder those entries, which is why installing a second system on the same machine no longer means overwriting a shared boot sector.
Removable media in UEFI mode relies on a fallback path. Firmware looks for a specific default file on the ESP so that a drive it has never seen before can still start. This is why a correctly prepared drive works on a machine with no boot entry configured for it.
Telling which mode you are in
| System | Where to look | What it tells you |
|---|---|---|
| Windows | System Information, "BIOS Mode" row | Reports either UEFI or Legacy |
| Linux | Whether /sys/firmware/efi exists | Present means the system started via UEFI |
| Firmware setup | Boot menu entry names | Entries prefixed "UEFI:" started in UEFI mode |
That last row is the most useful one when you are standing at a machine with a drive plugged in. Many firmware boot menus list the same physical drive twice — once as a plain device name and once with a UEFI prefix. Those two lines are not duplicates. They are two different ways to start the same drive, and the one you pick determines which path the image inside will follow.
Compatibility support and why it disappeared
For years UEFI firmware shipped with a compatibility layer that could still perform the old sector-zero handoff, usually labelled CSM or Legacy Support. It made the transition painless. It also doubled the number of code paths every vendor had to test, and on recent platforms it has largely been removed. On a machine bought in the last few years, assume UEFI only unless the firmware setup tells you otherwise.
What this means when a drive will not start
- Check whether the drive appears in the firmware boot menu at all. If it does not, the problem is the drive, the port or the boot order, not the image.
- If it appears twice, try the other entry. Choosing the wrong mode is the single most common cause of a drive that "does not work".
- Check whether compatibility support is available in firmware setup. If it is switched off and your image only supports the older route, the drive will never appear.
- Confirm the image itself supports the mode you are trying. Some older or specialised images support one route only, and the project's release notes will say so.
Which mode to prefer
Where you have a choice, UEFI is the one to build around. It is what current hardware is tested against, it supports large disks without workarounds, it keeps boot entries in a place tools can manage, and it is the foundation the firmware signature checks are built on. The older route remains useful for reviving hardware from the era that used it, which is a real and worthwhile job — but it is a compatibility exercise, not a default.
If you maintain a drive that has to work on both, prepare it so that both entry points exist. Most multiboot loaders do this automatically, placing the older boot code and the .efi files side by side so that whichever firmware picks it up finds something it understands.