26

I'm installing a new operating system on my computer. Should I install it for booting in UEFI or legacy (BIOS/CSM) mode? What are the advantages or disadvantages to using one or the other?

0

1 Answer 1

36

I've seen this question asked in various places, with only partial answers, so I'm aiming to provide something like a complete guide to boot schemes ;)

First of all, some background information you're going to need:

  • BIOS boot generally requires MBR partitioning, although some bootloaders support other partitioning schemes, like GPT.
  • UEFI boot generally requires the bitness of the OS to match the bitness of the firmware – and the vast majority of UEFI-based machines have 64-bit firmware.

Scenarios when you must use BIOS

  • You're installing an old OS that doesn't support UEFI boot (e.g. pre-SP1 Windows Vista or earlier), or
  • You need to install an OS with different bitness than that of the firmware (i.e. 32-bit OS on a machine with 64-bit UEFI, or vice versa)

Note that OSes that nominally require UEFI can often be forced to boot on BIOS-based machines by use of a specially-designed bootloader1. For example, this is the case with OS X – as any Hackintosh enthusiast can tell you.

If you plan to dual-boot and are installing the second OS...

While difficult, it is possible to convert between MBR and GPT schemes and reinstall the bootloader for a different mode.

It is also possible to have one OS booting via UEFI and another via BIOS. Sometimes you'll have no choice, e.g. if you already have an UEFI-based 64-bit Windows install, and want to install 32-bit Linux alongside it. Or some old and/or exotic OS that doesn't support UEFI. But think twice whether you really need to do it.

So, bottom line: just stick with the boot scheme you already have on your machine, unless you don't have that choice. It is almost always the right way.

How do I know what boot scheme my machine is using?

The rule of thumb is:

  • If it's a Mac, it uses UEFI; some early Intel-based models used EFI32, all models since 2008 use standard 64-bit UEFI.
  • If it's a brand-name PC that shipped with Windows 8 or later, it uses UEFI; Microsoft requires Secure Boot (which requires UEFI) to be enabled by default on all computers that conform to the Windows logo specification since Windows 8.
  • If it's a PC that shipped with Windows XP or earlier, it uses BIOS.

With PCs that shipped with Windows Vista or 7, or with Linux, as well as DIY PCs or those sold by small local businesses, you can never be sure just by sight. There are several ways to identify the boot mode in that case:

  • You can examine the partition table. If it's a GPT disk and has an "EFI System Partition" (usually before the main OS volume), it boots in UEFI mode. Otherwise, it's BIOS mode.
  • You can enter the BIOS/UEFI Setup program and search for boot priority options. If it displays entries saying EFI or UEFI, and/or they are somewhat descriptive of the operating system (like "Windows Boot Manager" or "Ubuntu"), it boots in UEFI mode. If it only shows the drive model number at most, it's BIOS mode.

If you're installing the first OS on a new machine or intend to clear your hard drive...

First of all, check if you have any choice. Enter the BIOS/UEFI Setup program and look for options like "Boot mode" that can be switched between "UEFI", "Legacy", "UEFI+Legacy", something like that. It may also be called something along the lines of "Enable UEFI Boot" or "Enable Legacy Boot", or mention the term CSM. If there is no such option in your firmware, you're out of luck and have to stick with whatever you've got – on older machines that'll be the BIOS mode; there are also some newer machines (e.g. the Microsoft Surface line) that only support the UEFI mode. If you're still unsure what you've got – search for "Secure Boot" in the settings – if it's mentioned anywhere, it's UEFI.

Assuming you have the choice... Let's see the advantages for both modes.

Advantages of UEFI

  • Faster boot and better power management.2 This is especially true for Windows – depending on various factors, UEFI with Fast Boot can be even twice as fast as legacy boot. With Linux the difference will be smaller, but still present. This is because BIOS-booted OS needs to re-initialize some hardware that might have been already initialized, the initial OS code needs to be loaded in very slow legacy modes, etc. With Linux you can also ditch GRUB (or equivalent) entirely and boot the kernel directly from the firmware, which can also speed the process up a bit. Also, things like reboots, sleep, hibernation, etc., may sometimes partially or entirely bypass the POST, further improving the overall speed of boot- and power-related operations.
  • Secure Boot option. Depending on your use case, it might be more of a hassle than an advantage (but majority of hardware allows to disable it), and also its actual security merits are limited – but still, having an additional signature check at the firmware level can be an additional protection against rootkits. Just don't assume your system is secure just because it uses Secure Boot, it's too flawed for such assumptions.
  • Better support for large drives. MBR partitioning scheme doesn't support disks over 2 TiB in size. You can still boot from such large disks under BIOS, by using hybrid partition tables and an additional bootloader partition (which most OSes create by default anyway), but it's better supported under UEFI. Also, GPT does not have that 4-partition limit of MBR, freeing you from nonsense like "extended partitions". There is almost nothing that you couldn't do on top of MBR via patchwork – but it is supported elegantly and natively, without the need for patchwork ;)
  • Native multi-boot. UEFI allows to natively declare that there is more than one operating system installed on a single hard drive – you can then choose between them from within the firmware UI, without the need for an additional bootloader. While it's not always the most convenient option to deal with multi-boot, this should decrease the number of problems such as an OS update or some anti-virus software overwriting a bootloader, etc.
  • Better software control. Some UEFI settings (in particular, the boot order) can be changed by the OS in a standard way. This enables you to order things like "shut down and reboot from CD" (or "boot another OS" in the case described above) from within the operating system, without having to enter the firmware UI.

Advantages of BIOS

  • Simpler boot process. Simpler, as in simpler by design – not necessarily simpler for the modern hardware (and that's why it's slower). With UEFI, only removable media can always be consistently booted – bootloader entries for OSes on internal drives are stored on the motherboard. That's why on an UEFI-based machine, when replacing the hard drive or moving drives between machines, you'll need a repair environment on a removable media (or in-firmware EFI shell, which is sometimes available on DIY-market motherboards, but almost non-existent in brand-name machines) to rebuild the internal bootloader configuration for the new drive. In contrast, BIOS just boots the first sector of the drive, which allows for effortless cloning and moving of hard drives between machines (provided that there are no driver-related problems, of course).
  • More flexible OS choices. Windows versions older than Vista SP1 can't boot via UEFI. Similar for older Linux distributions. Moreover, in general it is impossible to boot OS with a different bitness than the firmware – and the vast majority of UEFI-based systems are 64-bit, which means no 32-bit OSes without resorting to legacy boot. In contrast, pretty much everything can be booted via BIOS.1
  • Less bugs. UEFI implementations fairly often have subtle but fatal flaws and bugs, which can result in bricking the motherboard by removing firmware configuration or loading the wrong driver. In contrast, BIOS has been around since 1981, and at least the way it interfaces with the OS hasn't changed much during this time. In modern usage, it is a very thin layer that's only used at boot time, and also mostly unidirectional, with the OS having almost no access to whatever stays inside the BIOS. This means that it's much harder to fatally break things.

Bottom line

My advice would be to boot via legacy BIOS if you:

  • are actually setting up a virtual machine – UEFI on VM hypervisors tend to be limited and experimental; BIOS boot is much better supported
  • need to boot a 32-bit OS on a 64-bit machine
  • have a firmware known to be especially buggy
  • often swap or move hard drives between machines

Otherwise, it's better to go with UEFI. It's faster, more secure and comes with better functionality.

Footnotes

  1. It is even possible to install an UEFI environment on top of BIOS. TianoCore's DUET builds do specifically that – but such setup is usually impractical for real world installations. Unless you have a BIOS-only machine and you're installing some experimental OS that cannot be booted in any other way than via UEFI bootloader – you don't want to do that.
  2. Some early UEFI firmwares may have the UEFI bootloader "bolted on" top of an otherwise BIOS-based firmware. In those rare cases, BIOS boot may actually be faster, but that's not representative of most hardware.
4
  • Damn you type fast ;-)
    – Moab
    Aug 15, 2016 at 15:53
  • 1
    Regarding the first point, I'd say GPT requires UEFI, not UEFI requires GPT. For example an UEFI computer can boot from an MBR drive.
    – jiggunjer
    Jan 11, 2017 at 9:55
  • GRUB also supports booting via MBR sector even with GPT partitioned drives. In that case MBR contains only the code to load rest of the GRUB from GPT EFI partition. Jan 5, 2019 at 12:09
  • Another point to use UEFI (for Windows 10 for example) - you will be more agile in managing virtualization security features which could affect VirtualBox or VMVare vm-s. For example I was unable switch off Virtualization Based Security (VBS) in Windows 10 Pro until I configured UEFI and switch off VBS there.
    – drnk
    Jan 27, 2021 at 10:21

Not the answer you're looking for? Browse other questions tagged .