Do hard drives need a GUID partition table (GPT) to boot in UEFI mode?

Solution 1:

(U)EFI-based systems, by specification, can only boot from GPT-style disks. The traditional BIOS can boot from MBR-style disks, and in some cases (depends on the manufacturer), they can also boot from GPT. However, as per the UEFI specification, the disk should have a GPT partition table.

This MSDN article describes it well:

Systems that support UEFI require that boot partition must reside on a GPT disk. Other hard disks can be either MBR or GPT.

Solution 2:

No. The globally unique identifier (GUID) for the EFI system partition in the GUID Partition Table (GPT) scheme is C12A7328-F81F-11D2-BA4B-00A0C93EC93B, while its ID in the master boot record (MBR) partition-table scheme is 0xEF. So it perfectly works as it must from the spec.

"Officially the UEFI 2.x spec requires support for both GPT and MBR partitions. Pages 324 (9.3.6.1), also 72, 113–115, 539, etc"

And also "The UEFI specification requires MBR partition tables to be fully supported. However, some UEFI implementations immediately switch to the BIOS-based CSM booting upon detecting certain types of partition table on the boot disk, effectively preventing UEFI booting to be performed from EFI system partitions contained on MBR-partitioned disks". https://en.wikipedia.org/wiki/EFI_system_partition

Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821341

Solution 3:

Is EFI booting something hardware specific?

Yes. Some implementations, especially older ones or those from OEM-locked-down motherboards are more likely to be restricted or buggy.

Do the HDDs need to have a GPT partition table in order for them to boot in UEFI mode?

Technically no, but in your case, "probably, plus you need some other things(notably EFI files and EFI variables)". Here's the long answer (also for anyone else stumbling upon this in the future):

A frequent question that people ask is "Can I UEFI boot from an MBR disk?" The answer is "yes, but it's very tricky." While it's technically possible in the right environment, many things will prevent you from doing so, such as a UEFI environment that adheres very tightly to the spec, or the Windows installer that will insist on installing to the correct type of partition table.

First things first, optical media is not part of this discussion at all. It generally uses a system like ISO9660 or UDF, which lies completely outside of the MBR/GPT realm.

Secondly, removable media tends to be handled a little bit differently than fixed disks. Most UEFI implementations will be much more tolerant of removable ad-hoc UEFI bootable disks than they will be of fixed disks.

That being said, here's how a typical UEFI system will enumerate the bootable devices:

• If UEFI booting is enabled:

  • Look in EFI variables to see if there's any configured boot entries.

    Most OSes will create pointers to their boot files within the EFI variable system. These variables are stored in the EFI NVRAM.

    Most OSes will also take the extra step of creating an EFI System Partition and storing their boot files there instead of on the main OS volume. This improves flexiblity a little, but also works around a glaring problem with the typical UEFI system: Only FAT32 partitions are natively supported.

  • Look for any removable drives with an EFI file like "\EFI\BOOT\BOOTX64.EFI" Remember, most UEFI systems can only read from FAT32, so if your removeable drive is NTFS or something else, it probably won't find the boot files.

  • Enumerate all optical drives, regardless of whether they have EFI bootcode or not.

• If BIOS or CSM booting is enabled:

  • Enumerate all fixed disks, regardless of whether they have a valid MBR
  • Enumerate all removable disks, regardless of whether they have a valid MBR
  • Enumerate optical drives, regardless of whether they have a bootable disc.

There are a few other things not covered by the above, like Option ROMs, PXE boot, etc.

And now some observations on the above process. For starters, optical drives tend to show up all the time, regardless of boot mode. This is usually because neither BIOS nor UEFI systems want to wait for the disc to spin up before continuing with boot. They also tend to show as bootable in both modes simultaneously, so if you have a disc that can boot both ways, you can select one or the other from your BIOS's boot menu.

Because it's a bit hard to programmatically determine whether a drive (fixed or removable) contains valid MBR bootcode, if a system has BIOS or CSM boot available, it tends to just allow booting from any of the disks currently present. However, this is probably the answer to one part of your issue: While most systems should treat a USB stick almost like a fixed disk, perhaps your system is treating it differently. For example, some BIOSes will treat a USB device exactly like a fixed disk, and you may need to adjust the "hard disk boot order" or some such control in the BIOS. Or perhaps your BIOS is locked down or broken, and does not realize that it can be booted in BIOS mode. Some additional pointers: Try pluggin the drive into a USB 2.0 instead of 3.0 port, and enable USB compatiblity options in the BIOS. Some BIOSes have trouble natively working with devices behind third-party USB or ATA controllers, like you find on machines that don't have USB3 integrated into the chipset.

With the advent of EFI, it's now easy for a system to determine what boot devices should be available (by looking at the EFI variables containing boot entries), as well as determine if a specific drive actually contains bootcode (by looking for the presence of a BOOTX64.EFI file). However, this leads to some interesting caveats. While officially an EFI system is supposed to only look for EFI files in GPT disks, most of the time it'll look elsewhere as well. For example, you can copy a Windows 7 or newer installation disc to a FAT32 USB stick, and it'll probably boot just fine in EFI mode. The UEFI is smart enough to check for the presence of the "\EFI\BOOT\BOOTx64.EFI" file in all removable disks, even though no corresponding EFI variable is present in the NVRAM. Most UEFI systems will also boot from an MBR disk just fine, as long as there's EFI variables with the details about where to go and what to do. For example, right now I'm using a Dell laptop that came from the factory with Windows 8.1 booting in UEFI mode with Secure Boot, but the disk was partitioned as MBR.

Some other funny things that can happen: If you install an EFI aware OS like Windows or Ubuntu, it'll create the appropriate EFI variables when installing its bootloader. Then, if you remove or wipe the drive, the system will have the EFI variables, complete with the name of the OS, but cannot boot to them because it cannot find the disk that the variables reference. Also, if you take a fully functioning EFI-bootable disk from one computer to another, it may not boot as seamlessly as an MBR one will. Many UEFI implementations will not allow you to even attempt booting from a fixed disk in UEFI mode if corresponding variables are not present in the NVRAM. This is why your RAID array or other fixed hard drives may not appear in the boot menu as UEFI entries until they have all the proper structures in place, like the EFI variables.

However, given your exact set of issues, I'd chalk most of your problems up to a broken BIOS more than a problem with your setup. Notably, for a USB drive to appear as a UEFI device but not a BIOS device is very strange. Have you turned off Secure Boot and enabled any CSM or BIOS boot options? Also, for your optical drive to show up as a BIOS option but not a UEFI option seems a bit strange, though not unheard of.