Implementation details

Partitioning schemes (MBR vs. GPT / GUID Partition Table)

The Installer on the Apple OS X DVD-ROM won't install onto disks that use the classic MBR partitioning scheme, which is what most pre-installed PCs and external drives come pre-installed with.

I know of two solutions to this:

1. Reformat the disk in order to turn it into using GPT (GUID Partition Table) scheme. This will usually erase all your data on the disk, though. This can be done with the program "Disk Utility" directly from the Installer.
2. Modify the Installer so that it installs onto MBR disks, allowing you to install OS X to an available partition with losing the data on the other partitions. This requires that the OS X Installer DVD gets copied to a hard disk (or large enough memory stick), which can again be done with Disk Utility (requires to create an interim disk image file, though), with OS X programs such as "Carbon Copy Cloner" or with my own tool "iBored". Once copied, the installer can be modified as suggested here: http://forums.msiwind.net/osx-drivers/retail-osx-install-without-reformat-install-mbr-t11802.html. After that, you can boot from the modified copy instead of the DVD.

Boot loader (PC-EFI, Chameleon)

The main boot loader is in a file usually called boot (in source code: boot2). It contains the PC-EFI code, which is a "fake" EFI BIOS providing just the minimum of functionality a OS X kernel (as of OS X 10.5) needs to start up (see Chameleon source: i386/libsaio/fake_efi.c). It also contains code to read HFS+ volumes, and is responsible for loading the kernel file and starting it. It can scan multiple attached disks, and search them for HFS+ partitions, and offer a choice to the user from where to load the kernel.

Chameleon consists of three parts to get running:

• boot0 or chain0 - These are phase 0 loaders, fitting into the first sector of a disk, the MBR (<= 446 bytes). They load phase 1, i.e. the first sector of the partition that's marked active in the MBR.
• boot1h - phase 1: It is actually two sectors long, and reads its second sector itself from its own partition. Can read HFS+ volumes. Finds a file named "boot" in the root of the partition it resides in. Fits into the first two sectors of a HFS+ volume, which are otherwise unused (the 3rd sector then contains the "H+" volume header for the HFS+ volume).
• boot - phase 2: This is the main loader as explained above. It can load the "kernel" file and extensions from any HFS+ volume.

Further information on the boot process

• David Elliott explaining a few things about running Darwin on non-Apple hardware: Darwin/x86
• Mailing list thread on how the kexts get selected and loaded by the boot loader: Understanding kexts in the early boot process.

Origins

Original boot loader was apparently part of NeXT's OS, and later released to the public under the Apple Open Source license as part of Darwin ("boot-132"). David F. Elliott made an improved version of it (see http://tgwbd.org/darwin/boot.html), adding basic EFI support, plus a way to load additional kernel extensions from a secondary source, thus eliminating the need to modify the OS X kernel and extensions it wants to boot.

Next, a programmer called "netkas" (http://netkas.org/) took David's code, fixed and improved it a bit more (e.g. added code to inject a fake boot ROM identity).

Finally, some extensions and related patches were written to support an unmodified Darwin kernel to start up on a generic PC.

The last step in this process is to collect all these and turn them into a user-friendly package, with added boot options and other improvements. This is done by various programmers, mainly at http://forum.voodooprojects.org/.

Why Error 35 might occur

The system.log (see Console.app) might contain several messages like this: _CFGetHostUUIDString: unable to determine UUID for host. Error: 35 Also, it might show: ODUEthernetAddress(): GetEthernetAddress()== 5

The reason for these messages is, I believe, that there is no default Ethernet port available (or no driver for it). And many functions in Mac OS X require to create a unique ID for the Mac they're running on (e.g. network functions need this to identify the Mac uniquely in any network, as well as Time Machine). And since every Mac is equipped with an Ethernet port, and each physical Ethernet port gets a world-unique ID (called a MAC address), this 6-Byte code is used by those functions to create the unique ID for the Mac (a UUID is an even more sophisticated ID of similar kind).

To fix this issue, we need to supply a fake Ethernet port with a possibly unique MAC address.

There are some solutions to this on the 'net, but they may make the mistake of using a fixed MAC address. This won't hurt unless you try to connect two Macs with the same MAC address over the network. To avoid this clash, try to find a MAC address specific to your computer or LAN that is unlikely to be used by someone else or by another computer in your environment.

MAC addresses can be found in any network device: Routers, WLAN stations, even Bluetooth uses them. If your PC has actually an Ethernet port, and it only does not work under OS X due to the lack of a driver, then its MAC address is still the best choice. Usually, a PC / Laptop has its MAC address(es) printed on a label somewhere. Or, if you can boot into Windows, you can find it in the network properties.

For now, I simply fixed the problem with something like this: http://sneosx86.freeflux.net/blog/archive/2007/11/10/_cfgethostuuidstring-error-workaround-fix.html

Back to the main Hackintosh page