Tuesday, November 8, 2011

Installing Mac OS X

Installing OS X on a non-apple hardware is easier than it sounds, as long as the hardware is compatible.

Method at tonymacx86

Tonymacx86 provides a standard method for installing Mac OS X on a Sandy Bridge system. This method worked fine for basic funtionality, and only a few more tweaks were needed for sound and network to work.
What you need besides the computer is:
  •  a blank CD, for iBoot and Multibeast
  •  an OS disk purchased from Apple

The method makes it very important not to restart after updating to 10.6.8. That is precisely where my computer crashed, so I had no choice but to restart anyway. That did not seem to cause any problem, though.

From the Multibeast installer, you are presented with two options: EasyBeast and UserDSDT.



EasyBeast

This is the cookie cutter method of installing Mac OS X. No headache, but apparently you cannot expect all components to work at their best.
After installing with EasyBeast, I had a kind-of-working-hackintosh, with no sound and no network. The graphics card seemed to work fully, with no need to tweak by hand.

Motherboard specific DSDT

Tonymacx86 publishes ready made DSDT for a number of motherboards.
Since not all functionalities of my motherboard were enabled, this seemed to be the road to take.
The DSDT are automatically generated and not necessarily tested. Be sure to use a DSDT that matches you BIOS version, or upgrade your BIOS. I had troubles with the DSDT for version F6 of my BIOS, so I had to run with F5.

If you plan on building a hackintosh, I would recommend to select a motherboard that has a published DSDT.

What does Multibeast do?

Multibeast lets the user select packages to install. As far as I understand, it:
  • adds kexts (short for "kernel extension", the mac equivalent to drivers) in the following folders: /System/Library/Extensions or /Extra/Extensions
  • updates plist files in /Extra/Extensions
  • creates your own DSDT.aml in /Extra/Extensions.

A tree

Multibeast's interface is a tree of clickable items. It installs what you select, but does not uninstall what you do not select. This can cause problems because some of the items are incompatible with one another. If you install 'item a' to test it, then later install 'item b' which is incompatible with 'a', your system might just stop booting.
You cannot try items one by one until everything works, you need to uninstall what you tried before going to the next item. See the following section about reverting changes.

Parent nodes

Multibeast items that have children are also selectable. Clicking on such a node selects all the children items, even if these are incompatible with one another. Selecting a parent item and thus all its children is a very easy mistake to make.

Reverting changes

A key skill when installing kexts is apparently to be able to remove or undo the changes you just tested.

Unfortunately, Multibeast provides no log files of what it does to your installation. A text file mentioning when and where it added what files would be very nice. Being told "you installed 5 HDAEnablers for different chips" would have saved me much time.

What you can do to revert changes that did not turn out well is to:
  • Remove the offending kexts,
  • Delete your whole /Extra
  • Rerun Multibeast and select System Utilities parent node (or both its children nodes).
You need to know what kexts to remove, which I generally do not. The description text for each item in Multibeast can be helpful, but it is not always clear which kexts were installed and where.

In order to compensate for that, I have now set /System/Library/Extensions and /Extra/Extensions under version control, using git. Now if my install breaks, I will be able to see what files have been added since the last time, and remove the changes with a single command: git reset --hard. I might write a crash course about using git for this purpose in the near future.

Adding sound and network

Sound was working with the universal VoodooHDA 0.2.72 kext. I noticed however that the levels were really low (only up to half of the VU-meter on my mixer board input). I had to crank up the stereo's volume quite a bit to get a normal sound output, and then the background noise was way too high, especially for a sound chip that advertises 108 dB signal to noise ratio (SNR). Of course 108 dB theoretical SNR is just a marketing value, but this was so far off that I knew something was wrong.

A possible explanation: the VoodooHDA kext may have used only part of the bits available in hardware for each sample. Theoretical 108 dB SNR implies 18 bits resolution ([dB] = 20 × log10(2[number of bits])).
Using only 16 of these 18 bits would give a signal 12 dB lower for the same amount of background noise. By turning up the volume of the stereo I would compensate to get 12 dB extra on the signal, thus increasing the background noise by 12 dB as well.

Tonymacx86 published an ALC HDA sound installation method that seems made for motherboards such as mine: New Unified Realtek Onboard Audio Solution: ALC8xxHDA

This did not work at once. At first try, the OS stopped booting and gave cryptical error messages.
After reviewing the content of /System/Library/Extensions, I noticed that all HDAEnabler kexts available in Multibeast were present. I did not remember selecting all these kext files, what happened is probably what I described in "Parent nodes" above: selecting the whole "HDAEnablers" item also selected all of its children.
I must have selected this parent node by mistake at some time, and they started conflicting.

The solution was to uninstall all these kexts, as described in the above section "Reverting changes", then reinstall the correct kext alone. The difference on the sound output was dramatic, I am impressed that a sound chip integrated to a motherboard (and not a specially expensive one) can have such high quality. I had already purchased an external sound card, but I wonder if this integrated sound chip would not have been enough for my modest music studio needs.

Adding network was just a matter of testing the (at the time) two available options. Interestingly, the recommended choice did not work for me.

Playing safe

There is still much that I do not understand with how the system files are organized. While I feel pretty confident about version controlling the /System/Library/Extensions and /Extra/Extensions folders, I am not aware of other locations that are susceptible to change and break.

Once happy with the state of the install it was time to create a disk image of the whole OS disk, but that is the subject of a future post.

No comments:

Post a Comment