Does rEFInd need code in the MBR to boot windows on a Mac?

Question

I have read many posts regarding installing and booting Windows on Mac computers. Many procedures use rEFInd to boot a BIOS install of Windows. The procedures do not seem to indicate any installation of code in the MBR. So either the assumption is there is already code in the MBR from a previous install or rEFInd does not require such code to boot Windows. Does anyone know the answer?

Answer 1

Both rEFIt and rEFInd will place a copy of SYSLINUX MBR boot code in the MBR if the MBR is not already bootable and if appropriate boot code exists in a partition. That said, boot code should exist in the MBR, although it might be destroyed by partitioning tools that assume the first 440 bytes of the MBR on a GPT disk should be zeroed out, as is normally the case for EFI-bootable GPT disks.

This brings up another point, though: Windows 8 (and presumably Windows 10) installs pretty well in EFI mode on many Macs. When installed in this way, no BIOS-mode boot code is necessary, in either the MBR or in the Windows partition(s). An EFI-mode installation is likely to be safer because there's no need for the dangerous hybrid MBR that Macs use to dual-boot OS X and earlier versions of Windows. The catch to this type of installation is that Disk Utility and some other OS X tools will create a hybrid MBR if you try to prepare the disk for Windows -- for instance, by setting up a FAT partition. When the Windows installer, booted in EFI mode, sees the hybrid MBR, it will complain that it can't install to an MBR disk. You can work around this problem by using any number of tools (such as gdisk: Type x, then n, then w), but it can be frustrating and confusing if you don't understand the nature of the problem or how to fix it.

Answer 2

When the CSM is used, one option is to load the MBR boot code as a BIOS would.

The logic: the CSM must act exactly as a BIOS would in order to be compatible. The OS will put its required boot code into the MBR and the partition boot sector(s).

But that is for CSM based booting to begin with. Keep in mind that rEFInd itself is an EFI boot option. Because of that, rEFInd will be loaded by the (U)EFI as a standard binary EFI executable (PE 32- or 64-bit, depending on the EFI), like any loader for an EFI operating system. When the rEFInd menu is displayed, no CSM has yet been loaded. Because rEFInd is booted as an EFI executable there is no need for the CSM.

With the EFI booted rEFInd as a starting point, rEFInd itself will continue to look for bootable options, i.e. partitions, other EFI loaders or kernels. For BIOS-based operating sytems rEFInd will determine if an option is at all bootable exactly as a CSM would, by checking for a MBR (hybrid) partition with boot code from your BIOS-based operating system. If it is missing or currupt, the OS will not boot. (A reason might be that something went wrong when installing the operating system to the MBR partition.)

So the short answer is: no. Only when booting a disk (not a partition!) from the CSM the MBR boot code will be loaded. rEFInd, started as an EFI boot loader, isn't required or even able to start the MBR.

Imagine rEFInd would start the MBR (and for this let's just assume that it could also make the UEFI load the CSM): if there is a flaw in the boot code and/or partitioning (like no partition set as active) or if the selected boot option (via rEFInd) isn't the one that is marked as the active partition in the MBR partition table, the MBR boot code will not load the selected partition, rendering the whole purpose of rEFInd boot selection menu null and void.

From The rEFInd Boot Manager: Using EFI Drivers, section Selecting an EFI Driver:

NTFS—Samuel Liao contributed this driver, which uses the rEFIt/rEFInd driver framework. Note that this driver is not required to boot Windows with rEFInd, since Windows stores its EFI boot loader on the (FAT) ESP, and the BIOS boot process (generally used when dual-booting on a Mac) relies only on the partition's boot sector, which is read without the benefit of this driver.

This clearly implys that rEFInd will just load the boot sector of the respective MBR partition (must be a hybrid partition though), thereby intentionally skipping the MBR.

Also, UEFI (EFI 1.x on the Mac) provides means to "legacy boot" a selected partition, which, when selected/instructed to do so, automatically loads the CSM. Not all UEFI machines have this capability. If it is missing, rEFInd cannot boot a BIOS-based operating system from an MBR partition.

From the OSDev Wiki, section UEFI class 0-3 and CSM:

PCs are categorized as UEFI class 0, 1, 2, or 3. A class 0 machine is a legacy system with a legacy BIOS; i.e. not a UEFI system at all.

A class 1 machine is a UEFI system that runs exclusively in Compatibility Support Module (CSM) mode. CSM is a specification for how UEFI firmware can emulate a legacy BIOS. UEFI firmware in CSM mode loads legacy bootloaders. A class 1 UEFI system may not advertise UEFI support at all, since it isn't exposed to the bootloader. It's only UEFI "within" the BIOS.

A class 2 machine is a UEFI system that can launch UEFI applications but also includes the option to run in CSM mode. The majority of modern PCs are UEFI class 2 machines. Sometimes the choice to run UEFI applications vs. CSM is a one-or-the-other setting in the BIOS configuration, and other times the BIOS will decide which to use after selecting the boot device and checking whether it has a legacy bootloader or a UEFI application.

A class 3 machine is a UEFI system that does not support CSM. UEFI class 3 machines only run UEFI applications and do not implement CSM for backwards compatibility with legacy bootloaders.

From The rEFInd Boot Manager: Using rEFInd section Booting Legacy OSes:

To help out when you need to boot in BIOS mode, rEFInd supports booting legacy OSes; however, the details vary between Macs and UEFI PCs. Also, be aware that some UEFI PCs lack the Compatibility Support Module (CSM) that's required for this feature to work. This is true even of some computers that can boot BIOS-based OSes natively. This can happen because the firmware is basically a BIOS with a UEFI implementation tacked on top of it; such systems rely on the native BIOS to boot, and may not provide a way for EFI applications to access the BIOS features via CSM mechanisms. If you have such a computer and if you enable a legacy boot option in the configuration file, rEFInd notifies you of its inability to present legacy boot options when it starts up.

If you are interested if you actually have some CSM entries in your EFI boot menu – not rEFInd, but real (U)EFI boot selections – you can try efibootmgr -v on Linux. This will only work when Linux itself is booted as an (U)EFI operating system. When Linux is booted as a CSM boot selection, it will have no access to the underlying EFI implementation. Only, on Linux there is not much of a difference regarding partitioning, because Linux isn't as picky as Windows and can happily use GPT partitioning when in BIOS mode.

# efibootmgr -v
Timeout: 2 seconds
BootOrder: 0000,0004,0005
Boot0000* Windows Boot Manager  HD(2,GPT,1bf25484-f461-4892-a640-a24136b1d45f,0xe1800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...e................
Boot0004* Hard Drive    BBS(HD,,0x0)P0: INTEL SSDSC2CT060A3       .
Boot0005* UEFI: SanDisk Extreme 0001    PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(4,0)/HD(1,MBR,0x97,0xb4,0x298c)/File(\EFI\BOOT\BOOTX64.EFI)

In this example there are only UEFI entries.

# efibootmgr -v
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0003,0002,0000,0004
Boot0000* CD/DVD Drive  BIOS(3,0,00)
Boot0001* Hard Drive    HD(2,0,00)
Boot0002* Fedora        HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\grubx64.efi)
Boot0003* opensuse      HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\opensuse\grubx64.efi)
Boot0004* Hard Drive    BIOS(2,0,00)P0: ST1500DM003-9YN16G

In this example, Boot0000 and Boot0004 are CSM selections (note the BIOS path) and the UEFI will boot these entries with the CSM loaded. But be aware that it is still the UEFI that invokes the boot of the selected entry!

When rEFInd is supposed to use CSM mechanisms to boot legacy operating systems from MBR (hybrid) partitions, I can only assume that this is very similar to the permanent UEFI boot entries. It may be that rEFInd uses one-time boot entries (like BootNext) for this task...