Running Yosemite on UEFI hardware

I use the Clover boot loader in a UEFI-only installation on the ESP with the »BootCamp« theme. The only UEFI driver I need is OsxAptioFix2Drv-64 -- without it I get ???.

The best source for up-to-date kexts I've found is to download the current MultiBeast installer. The »Contents/Resources« folder of »MultiBeast.app« contains packages which can be expanded using

$ pkgutil --expand FakeSMC-v6.14.1364.pkg p
$ pax -rzf p/Payload

For my Intel DH87RL, I drop FakeSMC.kext and AppleIntelE1000e.kext into the corresponding folder OEM/DH87RL/kexts/10.10 on the ESP.

After installing new kexts, a reboot »without caches« must be performed by selecting the boot entry with space bar in Clover and selecting the corresponding entry.

My configuration file OEM/DH87RL/config.plist contains

<?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>DefaultVolume</key>
  <string>LastBootedVolume</string>
  <key>Timeout</key>
  <integer>5</integer>
  <key>Log</key>
  <false/>
 </dict>
 <key>GUI</key>
 <dict>
  <key>Scan</key>
  <true/>
  <key>Custom</key>
  <dict>
   <key>Legacy</key>
   <array>
    <dict>
     <key>Type</key>
     <string>Windows</string>
     <key>Hidden</key>
     <true/>
    </dict>
   </array>
  </dict>
 </dict>
 <key>KernelAndKextPatches</key>
 <dict>
  <key>Debug</key>
  <false/>
  <key>KernelPm</key>
  <true/>
 </dict>
 <key>RtVariables</key>
 <dict>
  <key>MountEFI</key>
  <false/>
 </dict>
 <key>SystemParameters</key>
 <dict>
  <key>InjectKexts</key>
  <string>Detect</string>
 </dict>
</dict>
</plist>

Deploy Windows RE on system partition

I have been fighting with REAgentC to allow me to install the WinRE image to the system partition (8).

I have gone through numerous errors like »the product has been uninstalled«, »there is insufficient space on the device«, »the operation cannot be completed due to a file system limitation« and the pair of »cannot find the file/path specified« or »file cannot be created because it exists«.

I think the »cannot be created« error was the result of copying an existing boot.sdi ramdisk along with the winre.wim. This is wrong, REAgentC creates the ramdisk.

One thing I've noticed is that at least on an MBR disk, an NTFS partition is required in order to successfully enable WinRE on the system partition. If it's FAT32, I got misleading errors about »insufficient space« until I enlarged it, which then told me it could not complete the operation due to »file system limitations.«

If REAgentC is confused by the current contents of %systemroot%\System32\Recovery\ReAgent.xml, replace by a blank file:

<?xml version='1.0' encoding='utf-8'?>
<WindowsRE version="1.0">
    <WinreBCD id=""/>
    <WinreLocation path="" id="0" offset="0"/>
    <ImageLocation path="" id="0" offset="0"/>
    <OsInstallLocation path="" id="0" offset="0"/>
    <InstallState state="0"/>
    <OsInstallAvailable state="0"/>
    <WinREStaged state="0"/>
    <OperationParam path=""/>
    <OsBuildVersion path=""/>
    <OemTool state="0"/>
    <BootKey state="0"/>
    <IsServer state="0"/>
    <ScheduledOperation state="4"/>
</WindowsRE>

With the recovery partition on R:, the commands

md r:\Recovery\WindowsRE
xcopy /h %systemroot%\System32\Recovery\winre.wim r:\Recovery\WindowsRE
reagentc /setreimage /path R:\Recovery\WindowsRE /target %systemroot%
reagentc /enable
succeed and eventually produced this file:

<?xml version='1.0' encoding='utf-8'?>
<WindowsRE version="1.0">
    <WinreBCD id="{30f4463f-add1-11e4-97b2-e8db73286102}"/>
    <WinreLocation path="\Recovery\WindowsRE" id="196858822" offset="1048576" guid="{00000000-0000-0000-0000-000000000000}"/>
    <ImageLocation path="\Recovery\WindowsRE" id="196858822" offset="1048576" guid="{00000000-0000-0000-0000-000000000000}"/>
    <OsInstallLocation path="" id="0" offset="0" guid="{00000000-0000-0000-0000-000000000000}"/>
    <InstallState state="1"/>
    <OsInstallAvailable state="0"/>
    <WinREStaged state="0"/>
    <OperationParam path=""/>
    <OsBuildVersion path="7601.18700.amd64fre.win7sp1_gdr.141211-1742"/>
    <OemTool state="0"/>
    <BootKey state="0"/>
    <IsServer state="0"/>
    <ScheduledOperation state="4"/>
</WindowsRE>

Note that it's apparently impossible to issue the »/enable« command from Recovery Environment because it doesn't support the »/target« switch.

And here are the relevant boot loader entries created by REAgentC for this case:

Windows-Start-Manager
---------------------
Bezeichner              {bootmgr}
device                  partition=\Device\HarddiskVolume1
description             Windows Boot Manager
locale                  de-de
inherit                 {globalsettings}
default                 {current}
resumeobject            {30f44639-add1-11e4-97b2-e8db73286102}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30

Windows-Startladeprogramm
-------------------------
Bezeichner              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  de-de
inherit                 {bootloadersettings}
recoverysequence        {30f4463f-add1-11e4-97b2-e8db73286102}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {30f44639-add1-11e4-97b2-e8db73286102}
nx                      OptIn
detecthal               Yes

Windows-Startladeprogramm
-------------------------
Bezeichner              {30f4463f-add1-11e4-97b2-e8db73286102}
device                  ramdisk=[\Device\HarddiskVolume1]\Recovery\WindowsRE\Winre.wim,{30f44640-add1-11e4-97b2-e8db73286102}
path                    \windows\system32\winload.exe
description             Windows Recovery Environment
inherit                 {bootloadersettings}
osdevice                ramdisk=[\Device\HarddiskVolume1]\Recovery\WindowsRE\Winre.wim,{30f44640-add1-11e4-97b2-e8db73286102}
systemroot              \windows
nx                      OptIn
winpe                   Yes

Geräteoptionen
--------------
Bezeichner              {30f44640-add1-11e4-97b2-e8db73286102}
description             Ramdisk Options
ramdisksdidevice        partition=\Device\HarddiskVolume1
ramdisksdipath          \Recovery\WindowsRE\boot.sdi

For the tools to work, the system and recovery partition must be type id 0x27 on an MBR disk. The MBR and GPT partition types are:

Recovery300MBNTFS0x27de94bba4-06d1-4d40-a16a-bfd50179d6ac
ESP100MBFAT320x27c12a7328-f81f-11d2-ba4b-00a0c93ec93b
MSR128MBNTFS0x7e3c9e316-0b5c-4db8-817d-f92df00215ae
OSNTFS0x7ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

Other tools

Helpful tools I've used (apart from REAgentC and bcdedit, obviously) include bcdboot %systemroot% /l en-us /s s: to copy the required files to the boot partition and set the desired locale and the Recovery Environment commands bootsect /nt60 %systemroot%, bootrec /fixboot and bootrec /fixmbr (the latter apparently Windows XP relics) to restore a partition's boot loader.

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.

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.

Booting GParted on MacBook Air 11" (late 2010)

I wanted to boot GParted-0.13.0-1 (kernel 3.2.0-3-486) from a USB stick on my MacBook Air 11" (late 2010) using the EFI bootloader which appears when holding down Option while turning on the laptop. However, only HFS+ partitions appear to be attached in a way that GRUB can see, but GParted's initrd cannot mount HFS+ (or even exFAT) partitions, saying hfsplus not found in modules.dep or exfat not found in modules.dep, respectively.

So I used Disk Utility to create a HFS+ as well as a FAT partition on the USB key and copied the contents of the GParted image into both partitions using

$ pax -rw

A possible optimisation would be to try and work out which files exactly are really required on each partition, but since GParted unly uses about 120MB space shouldn't be an issue even for small USB sticks.

Interestingly, whether the USB stick is partitioned using MBR or GPT doesn't make a difference.

After that, the MBA's EFI bootloader (hold down Option while turning on) shows two items called "EFI boot", the first of which should refer to the HFS+ partition. After booting, GParted's initrd then finds the required boot image on the FAT partition. GParted loads and runs successfully using default settings.

There was still another small hurdle before I could reset the SSD:

# hdparm -I /dev/sda
showed the SSD's Security state as frozen which disallows issuing the SECURITY_ERASE command. Googling revealed a trick to change the state to not frozen by putting the laptop to sleep and waking it up. Amazingly, simply issuing
# echo mem > /sys/power/state
and closing and pressing the shift key to wake it up worked perfectly. If you're working on a detachable disk, it also helps to only attach the disk once GParted has booted.

Note: I tried again using GParted 0.19.0-1 (kernel 3.14). I had to select "VGA" mode in the boot menu in order to make X start and waking up from sleep didn't work. So I used 0.13.0-1 instead.

NetBSD vesa boot

In an attempt to test Jaren McNeil's recent contributions to a boot splash in NetBSD, I updated my boot code today and typed
vesa list
at the boot prompt. I chose
vesa 1600x1200x32
and the boot messages appeared very slowly in high resolution in a frightening resemblance to Linux. Here are the relevant dmesg differences:
@@ -51,11 +51,11 @@
 ppb1: unsupported PCI Express version
 pci2 at ppb1 bus 2
 pci2: i/o space, memory space enabled, rd/line, wr/inv ok
-vga0 at pci2 dev 0 function 0: vendor 0x1002 product 0x954f (rev. 0x00)
-wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
+genfb0 at pci2 dev 0 function 0: vendor 0x1002 product 0x954f
+genfb0: framebuffer at 0xd0000000, size 640x480, depth 8, stride 640
+wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation)
 wsmux1: connecting to wsdisplay0
-radeondrm0 at vga0: ATI Radeon HD 4350
-radeondrm0: Initialized radeon 1.29.0 20080613
+drm at genfb0 not configured
 azalia0 at pci2 dev 0 function 1: Generic High Definition Audio Controller
 azalia0: interrupting at ioapic1 pin 10
 azalia0: host: 0x1002/0xaa38 (rev. 0), HDA rev. 1.0
@@ -375,18 +375,12 @@
 boot device: wd0
 root on wd0a dumps on wd0b
 root file system type: ffs
-wsdisplay0: screen 1 added (80x25, vt100 emulation)
-wsdisplay0: screen 2 added (80x25, vt100 emulation)
-wsdisplay0: screen 3 added (80x25, vt100 emulation)
-wsdisplay0: screen 4 added (80x25, vt100 emulation)
+wsdisplay0: screen 1 added (default, vt100 emulation)
+wsdisplay0: screen 2 added (default, vt100 emulation)
+wsdisplay0: screen 3 added (default, vt100 emulation)
+wsdisplay0: screen 4 added (default, vt100 emulation)
Unfortunately, the fact that radeondrm didn't attach meant that X Window wasn't accelerated which is not tolerable. Also, I learned later from Hubert's post that setting the splash image wasn't actually implemented yet (as I'd foolishly assumed). So I turned it back off in my /boot.cfg and will give it another try later.

One important lesson I learned that the /boot code doesn't actually get updated by my regular update routine, so I should make a note to issue a cp /usr/share/mdec/boot /boot every once in a while.