Installing Mavericks on UEFI hardware

I decided to try and build a Mavericks installer for my new Intel DH87RL based computer. My aim was to use as few extra files as possible from a plain Mavericks installation medium, and especially no tools to perform unknown tasks for me.

I create a Mavericks install medium using the suggestively named script createinstallmedia:

$ cd <Path to Install OS X Mavericks.app>
$ sudo ./Contents/Resources/createinstallmedia --volume /Volumes/<scratch media> --applicationpath "$PWD"

Try to boot...

Next, there is an initially confusing number of boot loader options: Chameleon/Chimera and Clover. According to my research, the former are legacy boot loaders for pre-UEFI boards and will utilise the compatibility module when booted on UEFI hardware -- yuck!

So Clover seems to be the way to go for modern hardware. It even offers a friendly manual installation using only terminal commands without resorting to magic tools.

I am following this handy guide.

Attempts on Asus P6T SE LGA 1366 board with Radeon HD4790

A plain Mavericks installer with a Clover boot loader and an SMBIOS for a MacPro5,1 (LGA1366) boots to a grey screen with an apple logo and a SBBOD (Spinning Beach Ball Of Death).

Adding FaceSMC.kext to /EFI/CLOVER/OEM/P6T SE/kexts/10.9 and setting "InjectKexts" to "Detect" in the "SystemParameters" section of my config.plist successfully brings up the installer. Adding "RealtekRTL81xx.kext" additionally enables ethernet.

The system boots both with my Sapphire HD4350 and an Asus HD7790, but the former chooses the wrong video mode and seems very slow while the second one seems to be better supported by Mavericks. In the installer, Safari flickers a lot with both video cards.

Next, I formatted the EFI partition that the OS X installer had created using FAT32 to enable Clover to write log files or DSDTs (FAT32 is the only writable file system for Clover).

$ sudo newfs_msdos -F 32 -v EFI /dev/disk0s1

Note: FAT32 (-F 32) is important because newfs_msdos picks FAT16 by default which isn't supported by Clover's 'boot1f' code, resulting in the messages:

boot1f: init
boot1f:error

Then I installed Clover to this EFI partition on the target disk with the following settings:

  • Install Clover in the ESP (because I don't want it on my HFS hard drive)
  • Bootloader: Install boot0af in MBR (because I want the 'active' partition flag to work)
  • CloverEFI: CloverEFI 64-bits SATA (I think it does not make a difference on my BIOS-based computer)
  • Install RC scripts on target volume (this was needed to make the NVRAM work, which again is required to set the startup volume and use automatic boot)

This is the config.plist file I use (yes, that's all):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>ACPI</key>
 <dict>
  <key>SSDT</key>
  <dict>
   <key>EnableC6</key>
   <true/>
   <key>Generate</key>
   <dict>
    <key>CStates</key>
    <true/>
    <key>PStates</key>
    <true/>
   </dict>
  </dict>
 </dict>
 <key>Boot</key>
 <dict>
  <key>Timeout</key>
  <integer>0</integer>
 </dict>
 <key>GUI</key>
 <dict>
  <key>Scan</key>
  <true/>
 </dict>
 <key>SystemParameters</key>
 <dict>
  <key>InjectKexts</key>
  <string>Detect</string>
 </dict>
</dict>
</plist>

The resulting system is really cute, but not really usable because the graphics support is too bad. For example, the adjustments in the Colour Calibration preference pane have no effect. iMovie doesn't even start because the requirements aren't satisfied, and iPhoto doesn't show photos in single-photo or edit mode.

Intel DH87RL with i5-4670

On this board, using Intel's »Visual BIOS«, the VT for Directed I/O (VT-d) switch must be turned off in the Security settings for Yosemite to boot successfully.

I copied my existing configuration into the /EFI/CLOVER/OEM/DH87RL/ folder and removed the RealtekRTL81xx.kext from kexts/10.9.

The drive booted fine in BIOS mode, but in UEFI mode I got an "Error exiting boot services" from Clover. From a successful BIOS boot, I added OsxAptioFixDrv and that fixed the problem.

For the network card, this board requires the AppleIntelE1000e driver in the kexts/10.9 folder.

Results with this board and the i5-4670's integrated Intel HD4600 graphics are looking much better than with the HD7790 above: colour calibration and iPhoto just work, for example.

There is still one mysterious problem: "Shut Down" in the system menu has the same effect as "Restart"...

In order to dual-boot Windows with OS X, I used Clover's "Add Clover as EFI boot option", which created a "Firmware Application" entry for Clover visible in bcdedit /enum all. I made this the default boot entry using the command

bcdedit /set {fwbootmgr} displayorder {...} /addfirst
where the last item is the identifier value of Clover's entry. This motherboard doesn't actually show a boot menu with different options as suggested by the name displayorder, but simply boots the first entry in the list. The timeout value in the {fwbootmgr} section refers to the time that the Intel logo is shown.

Abandoned initial attempts for reference

Using a guide, I extracted BaseSystem.dmg onto a USB key and inserted the Packeges folder. I then used pkgutil to extract mach_kernel and dropped it in the root folder.

$ cd
$ xar -xf "/Volumes/OS X Install ESD/Packages/BaseSystemBinaries.pkg" Payload
$ pax -rjf Payload ./mach_kernel
$ mv mach_kernel "/Volumes/OS X Base System"
$ rm Payload

At this point, the new install medium should boot fine.

In order to enable booting on generic UEFI hardware, I downloaded FaceSMC.kext from tonymacx86 and copied it to /System/Library/Extensions on the installation medium.

Perforce SCM for Visual Studio fails to start

If you get an error message when trying to start the Perforce SCM plugin for Visual Studio, the reason is most likely that the wrong set of Qt libraries are being loaded from a directory earlier in %PATH% (yes, the old DOS environment variable). Use Computer's advanced settings to move Perforce's directory to the start of %PATH% and hope nothing else breaks.

Fixing BCD entries for Windows Recovery Environment (WinRE)

Of course, we have bootrec /RebuildBCD, but it only creates bare-bones BCD entries to boot the operating system(s) it discovers.

I have since learned that you can recreate the necessary entries for WinRE using the command

reagentc /enable
provided the file %SystemRoot%\system32\Recovery\WinRE.WIM exists.

For reference, here is the manual method:

There is an excellent write-up by Mark Wharton in the Acronis forum where I got all of the following information.

Essentially, the BCD as displayed by bcdedit /enum all contains three essential sections: One Windows Boot Manager section, then a Windows Boot Loader section for each OS (including WinRE) and a Device Options referenced by the "Loader" section for WinRE that specifies the ramdisk.

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume1
path                    \bootmgr
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {95712d80-09fe-11e4-82d5-80dbd73f896e}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {95712d87-09fe-11e4-82d5-80dbd73f896e}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {95712d80-09fe-11e4-82d5-80dbd73f896e}
nx                      OptIn

Windows Boot Loader
-------------------
identifier              {95712d87-09fe-11e4-82d5-80dbd73f896e}
device                  ramdisk=[C:]\Recovery\14a69569-3069-11df-a60b-9fbdc7c34241\Winre.wim,{95712d88-09fe-11e4-82d5-80dbd73f896e}
path                    \windows\system32\winload.exe
description             Windows Recovery Environment
inherit                 {bootloadersettings}
osdevice                ramdisk=[C:]\Recovery\14a69569-3069-11df-a60b-9fbdc7c34241\Winre.wim,{95712d88-09fe-11e4-82d5-80dbd73f896e}
systemroot              \windows
nx                      OptIn
winpe                   Yes

Device options
--------------
identifier              {95712d88-09fe-11e4-82d5-80dbd73f896e}
ramdisksdidevice        partition=C:
ramdisksdipath          \Recovery\14a69569-3069-11df-a60b-9fbdc7c34241\boot.sdi

To get everything working, the recoverysequence key must contain the identifier of the WinRE "Loader" section. The latter, in turn, must reference a valid existing "Winre.wim" file and pass the identifier of the "Device options" section as a parameter.