Installing OSX (Snow Leopard) + Linux (Slackware 13.37 x86_64) on a GUID/GPT disk, with Software RAID enabled (ICH8R) - Part 5

Focusing on Linux + LILO setup, to (hopefully) conclude this series.

At this stage, you are supposed to have a standalone GPT/GUID disk, with a bootable OSX (Chameleon, Chimera), as well as free space for a Linux installation.

More disk partitioning

First order of the day is to pick up the latest Slackware distro (13.37 at the time of this post) and fire it up. Earlier versions of Slackware cannot handle GPT disks, and I don't believe they include gdisk either, so make sure you pick the very latest.

Now, since we seeded the partitioning from OSX and left some free space, when firing up gdisk (using sdc here as sda+sdb are used by Windows 7 in ICH8R RAID1) you'll be greeted with the following:
# gdisk /dev/sdc
GPT fdisk (gdisk) version 0.6.14

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sdc: 234441648 sectors, 111.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 592CD063-7F0A-4F52-81EC-A58C5D3F859C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 8-sector boundaries
Total free space is 175418693 sectors (83.6 GiB)

Number Start (sector) End (sector) Size Code Name
1 40 409639 200.0 MiB EF00 EFI System Partition
2 409640 59022927 27.9 GiB AF00 Snow Leopard

Command (? for help): n
Partition number (3-128, default 3):
First sector (34-234441614, default = 59022928) or {+-}size{KMGTP}:
Last sector (59022928-234441614, default = 59022928) or {+-}size{KMGTP}: +30G
Current type is 'Linux/Windows data'
Hex code or GUID (L to show codes, Enter = 0700):
Changed type of partition to 'Linux/Windows data'

Command (? for help): p
Disk /dev/sdc: 234441648 sectors, 111.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 592CD063-7F0A-4F52-81EC-A58C5D3F859C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 8-sector boundaries
Total free space is 112504133 sectors (53.6 GiB)

Number Start (sector) End (sector) Size Code Name
1 40 409639 200.0 MiB EF00 EFI System Partition
2 409640 59022927 27.9 GiB AF00 Snow Leopard
3 59022928 121937487 30.0 GiB 0700 Linux/Windows data

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!

Do you want to proceed, possibly destroying your data? (Y/N): y
OK; writing new GUID partition table (GPT).
The operation has completed successfully.
  • Note 1: You'll notice that there's a 200 MB EFI System Partition. If you want OSX to be happy, even if the OSX bootloader shouldn't need it, better leave it alone.

  • Note 2: You'll have noticed that when firing gdisk, it mentioned something about a "protective MBR". This is because GPT and MBR can coexist on the same disk, and therefore an MBR-only aware utility could potentially destroy data. We'll put the MBR+GPT coexistence to good use later on in this post.

  • Note 3: If you leave OSX's disk utility create the partition for the Linux system and try to change the type in gdisk, the installer might not see your Linux system partition as a valid target. If that occurs, you should delete the non OSX/EFI System partitions in gdisk (d command), and recreate them.

Slackware and LILO setup

The Slackware install is as straightforward as usual, so I'm not going to comment on it. At the end, just install LILO on the MBR of your standalone OSX/Slackware disk (here /dev/sdc) as you'd normally do. Reboot, and you oughta be able to access your newly installed Linux system.

So how about we add OSX boot to our etc/lilo.conf and be done with this whole exercise then? The OSX bootloader (Chameleon, etc.) should be able to take the relay after LILO handoff. And while we're at it, we'll also add Windows boot from /dev/sda.
Off we go then and add the following at the end of /etc/lilo.conf:
other = /dev/sda
label = Windows
other = /dev/sdc2
label = OSX
And now the fun begins...

LILO troubles
# lilo

Reference: disk "/dev/sdb" (8,16) 0810

LILO wants to assign a new Volume ID to this disk drive. However, changing
the Volume ID of a Windows NT, 2000, or XP boot disk is a fatal Windows error.
This caution does not apply to Windows 95 or 98, or to NT data disks.

Is the above disk an NT boot disk? [Y/n]
Hell to the no! What on earth is going on here? Well, a little googling around tells you that LILO is unhappy because our mirrored disks (/dev/sda and /dev/sdb) bear the same volume ID. Two solutions there:
  • Solution 1: add a section:
    disk = /dev/sdb
    to lilo.conf to make it ignore the second mirrored disk altogether. In this case LILO will issue the warning Warning: bypassing VolumeID scan of drive flagged INACCESSIBLE: /dev/sdb but proceed.

  • Solution 2 (better): enable dmraid access to your drive. The thing is that the Slackware installer actually saw our mirrored volume alright (it listed our device automatically as /dev/md126*) but when booting our newly installed Slackware, the dm volume was no longer there. In case you wonder, this is because the Slackware installer rc.S script issues a /sbin/mdadm -A -s after fuse has been launched, which enables autodetection of mirrored drives.
    Therefore, if you just run that same command, the RAID 1 array will be detected and LILO won't complain about Volume IDs.
    # /sbin/mdadm -A -s
    mdadm: Container /dev/md/imsm0 has been assembled with 2 drives
    mdadm: Started /dev/md/WindowsRAID1_0 with 2 devices
    Probably a good idea to add that line in your system's rc.S script as well.

Now, with the Windows RAID issue being sorted, let's try again, shall we:
# lilo
Added Linux *
Added Windows
Warning: Device 0x0820: Inconsistent partition table, 2nd entry
CHS address in PT: 0:0:0 --> LBA (-1)
LBA address in PT: 0 --> CHS (0:0:1)
Fatal: Either FIX-TABLE or IGNORE-TABLE must be specified
If not sure, first try IGNORE-TABLE (-P ignore)
Son of a "£$%^&!! What's going on there?

Booting GPT partitions using MBR tools

I'll cut to the chase, our actual problem here is that LILO (as well as GRUB) is an MBR bootloader, not a GPT one. Therefore it actually uses the MBR partition table, and if you look at this table, you'll see that as far as MBR is concerned, /dev/sdc2 is nowehere to be found:
# fdisk -l /dev/sdc

WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdc: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x41b82465

Device Boot Start End Blocks Id System
/dev/sdc1 1 234441647 117220823+ ee GPT
Wait a minute, if that's the case, how comes LILO was able to boot our Linux GPT partition then? Isn't that one GPT too?
Aha! Well, the trick here is that, when booting the system, LILO doesn't need to know how the partition or filesystem is setup. Since the kernel file is always available to the Linux system you want to run LILO from (duh!), LILO can point to the actual kernel image sectors directly, so it actually bypasses the whole partition table (as well the filesystem), and just provides a list of raw blocks to read. Haven't you learned something interesting today? And that is why even a non GPT aware bootloader like LILO is able to boot from a kernel residing on a GPT Linux system partition. But of course, as soon as you leave the system partition, then LILO needs an MBR reference, to know where the start of the target partition is located, which it cannot find.

gptsync to the rescue!

At first glance it looks like we may have to abandon LILO. As far as I know, GRUB is unlikely to perform any better though (it's also an MBR based bootloader), but there exist projects targeted at GPT such as eLILO, though these may also require an EFI platform as well, which may also render them useless for our usage scenario.

Now, remember what I said about protective MBR tables for GPT disks and how both MBR and GPT could coexist? How about we created an MBR table that contains the same partition information as our GPT one then? Well, that's exactly what the rEFIt's gptsync tool is all about. This is a tool that can take a GPT partition table and create an exact MBR clone of it, so that MBR aware tools get the relevant information about the partitions.
Of course, this can only work if the GPT partition doesn't deviate too much from MBR compatibility requirements, which in most case (if your HDD is less than 2 TB as this is the hard limit for maximum MBR), shouldn't be a problem.
At this stage you have two options: pick up the binary gptsync executable for OSX from the Mac disk image or recompile your own from source in Linux. If you want a precompiled gptsync for OSX you can find one here (direct mirror), but considering that we're in Linux right now, we'll go the recompilation route. After having downloaded and extracted the latest refit package, just navigate to the gptsync directory and run make -f Makefile.unix. As these utilities are fairly simple, this should produce a gptsync and showpart executable in the same directory. Might be a good idea to see what showpart reports before going further, right?
# ./showpart /dev/sdc

Current GPT partition table:
Warning: Unknown GPT spec revision 0x00010000
Floating point exception
Dammit! Does no single tool work as expected out of the box these days, or is it just that I'm always one step ahead in trying cutting edge stuff? Long story short, you get this error on 64 bit Linux environments because the tools use unsigned long for 32 bit unsigned, and unsigned long is not 32 bit on x86_64. Easiest way I found to fix this is to include <stdint.h> in gptsync.h and then change the UINT8, UINT16, UINT32, UINT64 typedefs to use uint8_t, uint16_t, etc.... Once this is done:
# ./showpart /dev/sdc

Current GPT partition table:
# Start LBA End LBA Type
1 40 409639 EFI System (FAT)
2 409640 59022927 Mac OS X HFS+
3 59022928 121937487 Basic Data

Current MBR partition table:
# A Start LBA End LBA Type
1 1 234441647 ee EFI Protective

MBR contents:
Boot Code: LILO

Partition at LBA 40:
Boot Code: None (Non-system disk message)
File System: FAT32
Listed in GPT as partition 1, type EFI System (FAT)

Partition at LBA 409640:
Boot Code: None
File System: Unknown
Listed in GPT as partition 2, type Mac OS X HFS+

Partition at LBA 59022928:
Boot Code: None
File System: ext4
Listed in GPT as partition 3, type Basic Data
Much better! Off we go then:
# ./gptsync /dev/sdc

Current GPT partition table:
# Start LBA End LBA Type
1 40 409639 EFI System (FAT)
2 409640 59022927 Mac OS X HFS+
3 59022928 121937487 Basic Data

Current MBR partition table:
# A Start LBA End LBA Type
1 1 234441647 ee EFI Protective

Status: MBR table must be updated.

Proposed new MBR partition table:
# A Start LBA End LBA Type
1 1 409639 ee EFI Protective
2 409640 59022927 af Mac OS X HFS+
3 * 59022928 121937487 83 Linux

May I update the MBR as printed above? [y/N] y

Writing new MBR...
MBR updated successfully!

Final LILO tuning

Alrighty. Time for a new run at LILO:
# lilo
Added Linux *
Added Windows
Warning: Device 0x0820: Inconsistent partition table, 2nd entry
CHS address in PT: 1023:254:63 --> LBA (16450559)
LBA address in PT: 409640 --> CHS (25:127:15)
Fatal: Either FIX-TABLE or IGNORE-TABLE must be specified
If not sure, first try IGNORE-TABLE (-P ignore)
Well, actually this is not entirely unexpected considering that GPT does away with the MBR requirements of having partitions starting and ending on a cylinder boundary, so of course, if you don't fine tune your GPT partition, you're likely to have an MBR partition table that doesn't meet the MBR specs. However, in this case, we can safely ignore that issue, by making sure we have the following at the top of our /etc/lilo.conf
lba32        # LBA addressing should be default anyway
ignore-table # ignore CHS vs LBA conflicts in the MBR
This time:
# lilo
Added Linux *
Added Windows
Warning: Device 0x0820: Inconsistent partition table, 2nd entry
CHS address in PT: 1023:254:63 --> LBA (16450559)
LBA address in PT: 409640 --> CHS (25:127:15)
Warning: The partition table is *NOT* being adjusted.
Added OSX
2 warnings were issued.
Yay, at long last, our bootloader installed!
NB: if you get an "invalid block" error on your OSX partition in LILO, this means that your OSX bootloader (Chameleon, Chimera) has not been properly installed, so you will need to fix that first.

With LILO in place, you should find that you now have multiboot between Linux, Windows and OSX, and you didn't have to forfeit your ICH8R Windows partition in the slightest.

As is obvious from the length of these posts, this whole process took some fairly heavy lifting, but I hope that was worth it!

Installing OSX (Snow Leopard) + Linux (Slackware 13.37 x86_64) on a GUID/GPT disk, with Software RAID enabled (ICH8R) - Part 4

Tuning the OSX installation

Just a placeholder for now, as I still need for figure a few things. This will encompass removing the need to update AHCI for RAID everytime the system performs an update, making OSX bootable on its own, installing additiona drivers, etc.

All of the above doesn't really need to be performed before the Linux installation, but it looks tidier to keep all the OSX related posts in the same breadth... Stay tuned.


Installing OSX (Snow Leopard) + Linux (Slackware 13.37 x86_64) on a GUID/GPT disk, with Software RAID enabled (ICH8R) - Part 3

Alright, on to the actual OSX installation. This assumes that you have sorted out the matter of getting your SATA controllers detetected, and have booted your USB installation media with iBoot

Disk partitioning

From there on, this is the regular OSX installation process. After selecting your language and graciously ignoring the EULA, you should be greeted by a list of all the disks that the installation process is able to handle.
Unless you did something wrong in the previous process, you should have all your disks (though some of those may not appear until you run the disk utility - see next step). If you can't see them here at all, then you either screwed up your kext modification or your kext cache rebuilding. Shame on you!

In our case, we're going to use a new drive for the OSX + Linux installation, so the first order of business is to partition our HDD in GPT/GUID mode, using the OSX disk utility, which we prefer over using Linux's gdisk as OSX seems to have some installation quirks that gdisk alone doesn't seem to be able to address. I found out that if you use gdisk to modify the GPT partition, you're likely to have the OSX installer complaining that it cannot boot from it.

To parition the disk, simply launch "Disk Utility" from the Utilities menu at the top. Then select the destination disk and click the "Partition" button.

Now if anyone knows how one can make the OSX Disk Utility to accept user specified sizes, I'd like to hear from you as any attempt I tried to create a 40 GB single partition for OSX, while leaving the rest of the disk unused have failed. Gotta wonder what the point of providing a "Size" field is when it is blatantly ignored. The trick I used then was to go through the various "n-partitions" options, and pick the one that creates a first partition (for OSX) that is as close as possible to the size I actually want. Then just go through all the extra paritions and change their Format to "Free Space".

The points you want to pay attention to are:
  1. Label your OSX partition with something descriptive - don't keep "Untitled 1" (though you can change that later)

  2. Select "Mac OS Extended (Case-sensitive, Journaled)" for the Format (it's an UNIX based OS, it IS case sensitive dammit!). Now, if you ever plan to modify your OS files from Linux, then you may want to select a non Journaled filesystem, as the current HFS driver from Linux does not offer write access on Journaled.

  3. MAKE SURE "GUID Partition Table" (a.k.a. GPT) is used by clicking the "Options" button. Though you should be able to get away with MBR, the whole point of this exercise is to have a GPT disk to play with, so that's what we're gonna use.

Once your partitioning is set double check that you are partitioning the right disk, click Apply and quit the Disk Utility program. The newly created partition should now appear as a valid destination target for the installation process, so just select it and click "Install" (or click Customize then install, as it may be a good idea to remove additional languages or printer support if you don't have use for it). You can now go grab a cup of your favorite beverage and come back when the installation process has completed.

Dude, where's my boot?

So the install process completed successfully, the machine rebooted (more or less as the reboot process can be a bit flaky), and iBoot sees the new OSX installation alright. "VICT..., oh wait, this doesn't boot at ALL! AGHHH!!!".

Of course it doesn't you silly! To reiterate what I pointed out at the end of the previous post, the OSX installation process installs a clean, unmodified set of kexts, therefore all our good work about supporting the RAID controller on the USB key has been ignored. For the time being, we'll just fix that as we previously did, but instead of accessing the USB key, we'll do it on the OSX target drive:
  1. Boot once more into your USB installation media with iBoot

  2. go to Utilities→Terminal

  3. issue the command "mount". It should list your OSX partition, indicate that it has write acces, and tell you where it is mounted (should be in /Volumes/Something)

  4. cd /Volumes/<your_osx_partition>/System/Library/Extensions/AppleAHCIPort/Contents

  5. Issue nano Info.plist (you do have nano on your installation key, right? If not, see the first post in this series).

  6. Apply the same change as we did in previous post, namely change the <string>0x01060100&0xffffff00</string> part to <string>0x01060100&0xffffff00 0x01040000&0xffff0000</string> and save the file.

  7. Now, as previously, we need to rebuild the kext cache. The only difference is that unlike the installation media, the cache for Snow Leopard is located at System/Library/Caches/com.apple.kext.caches/Startup, so the command you want to issue is:
    kextcache -v 1 -t -l -a i386 -a x86_64 -m /Volumes/<your_osx_partition>/System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext /Volumes/<your_osx_partition>/System/Library/Extensions

  8. Quit the installer and restart the machine

  9. Remove the USB key and boot into iBoot. Then select your OSX partition. This time it should boot alright and finalize the installation process. Wilkommen, Bienvenue, Welcome to cabaret indeed! But keep that USB installation media handy, as you are likely to need it again very soon.

Installing OSX (Snow Leopard) + Linux (Slackware 13.37 x86_64) on a GUID/GPT disk, with Software RAID enabled (ICH8R) - Part 2

With both the iBoot CD and the OSX installation USB key rearing to go (see previous post), it's time to insert them both, and reboot, while making sure the CD/DVD drive is selected as your boot device. After a while, the iBoot boot selection screen should pop up, and provide you with the option to select "Mac OSX Install DVD" to boot from (which is actually our USB key) to start the installation process. NB: the name may be truncated, but if this is your first OSX install, just make sure you pick up the icon wit the Apple logo, as there should be only one.

Now, if your SATA controller was set to AHCI, or if you were using a JMicron SATA port, your target hard drive would likely be detected by the installer and you could actually proceed with the installation.
But of course, that wouldn't teach you how to add support for custom hardware on the fly, such as RAID SATA controller, would it, so where's the fun in that? Plus if you're reading this guide, you're trying to get an ICH controller in RAID mode supported.

In our case, if we try to iBoot our USB key, the installer won't see our target disk at all, so we need to address that on the USB key. The nice thing about our USB key procedure is that we can add AHCI support on the fly, and the producedure highlighted below should actually work for any SATA RAID controller (ICH9R, nVidia, whatever) that supports AHCI passthrough, not just ICH8R.

What's the big deal with AHCI vs RAID anyway?

As it turns out not much. The thing is, even in RAID mode, an ICH controller such as the one we use does AHCI passthrough. So why does the OSX installer see the disk in AHCI mode, but not in RAID mode?
Glad you asked. This is best illustrated by looking at the output from Linux's lspci both in BIOS AHCI mode and in BIOS RAID mode.

For the P5B Deluxe, here is what lspci -nn reports for our SATA ICH8R controller in AHCI mode:
00:1f.2 SATA controller [0106]: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) 6 port SATA AHCI Controller [8086:2821] (rev 02)
And here is the same, but in RAID mode:
00:1f.2 RAID bus controller [0104]: Intel Corporation 82801 SATA RAID Controller [8086:2822] (rev 02)
The important things to notice is that both the class ID and the controller VID:PID have changed, from (0106, 8086:2821) to (0104, 8086:2822) respectively.
As it turns out, the 0x0106 class ID is what the Apple AHCI driver uses to find out if a SATA controller is one it should support through AHCI (well, it actually uses 0x01060100 with a 0xffffff00 mask as we will see shortly), so that's the reason why, as soon as our class ID changes to 0x0104, OSX says "Hey, I don't know how to access this type of controller!" and gives up.

That's all very well, but that doesn't tell me how to get my RAID SATA controller recognized

Patience my friend... The key to achieving anything is understanding how it actually works, which we've done, so now is the time to get to the good part.
As you may already be aware, getting hardware recognized on OSX is done through the addition or modification of kexts. A kext, which stands for Kernel Exttension is pretty much the OSX equivalent of a driver or a Linux module. Therefore, to make our RAID controller recognized by the AHCI driver Apple uses, we will need to modify the kexts from our USB installation media to trick the installer into recognizing our non-officially unsupported hardware.

The kext of interest to us is the AppleAHCIPort.kext (makes sense), that resides in /System/Library/Extensions/ (which you will often see abbreviated as S/L/E on hackintosh forums). Most specifically, what we will want to edit is the Info.plist file found in /System/Library/Extensions/AppleAHCIPort.kext/Contents.

If you look at this file you see that it contains a section:
<key>Chipset Name</key>
<string>AHCI Standard Controller</string>
<key>Vendor Name</key>
Well, well, well, is that our 0x0106 generic AHCI class right there?

Great, then we just need to change the <string>0x01060100&0xffffff00</string> part to <string>0x01060100&0xffffff00 0x01040000&0xffff0000</string> to add AHCI passthrough support to any RAID controller (if you do have an actual dedicated non SATA RAID controller on your platform, you probably shouldn't use such a blanket approach, but instead duplicate one of the later sections), save the file, reboot, and be done with it, right?

Rebuidling the kext cache

Not so fast! If you just edit and save the Info.plist on the USB key, your RAID controller still will not be detected.
The reason for that is that kexts are executed at the kernel level, so Apple doesn't simply let you load a modified kext like this. Instead, an additional step is needed, which is the rebuilding of what is known as the kext cache. This cache is the Extensions.mkext file located in your /System/Library/ directory (where the Extensions/ directory also resides).

Note that the procedure I am highlighting below can be done from an existing Snow Leopard OS, rather than on the USB key itself, but if you do so, be midnful that there's a whole business going on with regards to permissions and ownership, which, if you mount your USB key as anybody but root (not a problem when using the OSX from the key), may result in an error message such as:
AppleAHCIPort.kext is not authentic; omitting from mkext.
Authentication Failures:
File owner/permissions are incorrect (must be root:wheel, nonwritable by group/other):
/Volumes/Mac OS X Install DVD/System/Library/Extensions/AppleAHCIPort.kext/Contents/Info.plist
In our case, we'll run everything from the key, and the default execution level is that of the root user, so it should be fairly simple:
  1. Open a terminal window by selecting Utilities→Terminal in the top menu (notice that we haven't had to accept any EULA to do so, so you are free to edit your OSX installation media from the embedded Terminal in any way you like)

  2. Remount the USB key as read/write (by default it is mounted read only) by issuing the command:
    mount -u -o rw /
    Note: Make sure you don't close your terminal session after you do that, as Terminal will not launch if the system is already r/w (which is also the reason why we do it manually). You should be able to check that the USB file system is now mounted r/w by issuing mount

  3. If you haven't done so already, copy the nano text editor, which you should have copied into the root directory to /usr/bin with the command:
    cp /nano /usr/bin
    Or you can just leave it in root and issue /nano whenever you need to edit a file.

  4. Navigate to the Info.plist file we want to edit with cd /System/Library/Extensions/AppleAHCIPort.kext/Contents/ and run nano nano Info.plist

  5. Change the <string>0x01060100&0xffffff00</string> line in the <key>GenericAHCI</key> section to <string>0x01060100&0xffffff00 0x01040000&0xffff0000</string>

  6. Save the file (Ctrl-X then 'y' to save it)

  7. navigate to the /System/Library/ directory with cd /System/Library/. This is the directory that contains the Extensions.mkext file

  8. Rebuild the kext cache with:
    kextcache -v 1 -t -l -a i386 -a x86_64 -m Extensions.mkext Extensions
    It should complete without errors (or a benign warning about the JMicronATA.kext) but if there are any issues reported about the AppleAHCIPort.kext, they should be explicitly listed.

  9. Close terminal and leave the installer (Mac OS X Installer→Quit Mac OS X Installer) then select Restart. You must restart the installation process completely (i.e. reboot) for our changes to be applied.

With all the above completed, on the second iBoot/USB installer run, you should now see all hard drives recognized, including the ones connected in a SATA connector in RAID mode, with the ability to use them as installation destination. Neat!

Before shouting "victory" though, you should be aware that:
  1. When OSX installs, it will extract and install its own unmodified AppleAHCIPort kext (from the Essentials.pkg found in System/Installation/Packages/ directory on the installation media, so what we have done will only work during installation, but the installed OSX will not actually be able to see its disk and we'll have to work around that - bummer!

  2. iBoot offers the option to ignore the cache during bootup (press the down key on the OS you want to boot, and then select "Boot Ignore Caches"), so we probably could have gotten away with simply modifying the Info.plist file and used that iBoot option instead of going through this whole cache rebuilding exercise...

Anyway, in the next installement, we'll go through the actual OSX installation process. Stay tuned...


Installing OSX (Snow Leopard) + Linux (Slackware 13.37 x86_64) on a GUID/GPT disk, with Software RAID enabled (ICH8R) - Part 1

Now that's quite a mouthful of a title. And considering that there is much to discuss, I will break this whole thing into a multipart post, so here is the first part of our series.

Introduction & Requirements

First of all, I gotta start with the disappointing news that, despite what you might anticipate from the title, this is not a guide to setup motherboard RAID (a.k.a. fakeRAID) support in either OSX or Linux (though the later is no biggie - see previous posts here for various options). The mention of RAID here is to indicate that we want to do an OSX and Linux that coexists nicely with a previous fakeRAID installation, by NOT requiring you to disable RAID settings in BIOS if they are already enabled.

In practice here, the goal is to add OSX and Linux on a separate non-RAID disk to an existing Windows 7 installation that was set to use fakeRAID (RAID 1 from ICH8R), without touching the BIOS settings.

Basically, what happened is that I recently upgraded my good old Asus P5B Deluxe based rig to a dual Samsung F3 1TB, installed Windows 7 ontop of the ICH8R RAID 1 array which I created in BIOS as a result, and since that left me with a bunch of unused SATA drives, I thought I would put one of these to good use by installing both OSX and Slackware on it (that Slackware 13.37 sure IS nice!), and use it to boot the whole lot. Sounds easy, but it actually presents a nice set of challenges, some of which include:
  • Adding extra drivers to a vanilla OSX installation media, so that it recognizes our AHCI controller even in RAID mode
  • Allow LILO (or GRUB) to boot OSes other than the main Linux system on a GPT/GUID partitioned disk (with a BIOS that is NOT EFI)
  • Installing OSX Snow Leopard from scratch, including updates and necessary drivers for your rig, but WITHOUT having to spend one's life endlessly browsing the OSX86 forums. Yes, the effort is much appreciated guys, but I have better things to do then become an expert on kexts, Chameleon, DSDT, iBoot and whatnot.
My specs:
  • Asus P5B Deluxe with 2x 1TB SATA HDDs in RAID mode (ICH8R) and 1x 320GB HDD (non RAID)
  • nVidia GPU (7950GT)
  • PS/2 keyboard, USB mouse + IDE DVD (the DVD is only going to be used for iBoot, so SATA or IDE won't matter one bit)
  • OSX Snow Leopard official installation DVD or .dmg image (build 10A421A)
  • One 8 GB (or bigger) USB key
  • An existing Snow Leopard installation. Yeah, I know it sucks, but hey.
That last item means either you need to create a VMWare image from the DVD media, or borrow a friend's Mac, but we want to create a USB OSX installation medium, which we can customize so there's little way to bypass that requirement. If you really don't have access to a preexisting OSX system, it's probably possible to create an USB key from Linux from the OSX installation DVD, but I haven't tried it so I can't comment on that. Besides, a VMWare image with Snow Leopard shouldn't be that hard to find.

My kingdom for AHCI? Surely you are jesting!

Question: What do all the hackintosh installation guides you find on the internet have in common?
Answer: They all begin with "You MUST change your BIOS settings and set your SATA controller to AHCI before you begin the installation"

Of course, this is utter nonsense. If a guide begins with "You MUST change your BIOS settings to something potentially incompatible with what you want, and risk destroying existing data as a result" (by disabling RAID mode from ICHR), then it's a lousy guide and you should stop right there. For having been a fakeRAID/motherboard RAID user for some years now, with both Intel and nVidia solutions, I'll tell you frankly: all those who say "Don't use fakeRAID: buy a dedicated RAID controller instead" are idiots. First of all, money to buy a separate controller doesn't grow on tree and secondly, with all these cores lying around, the idea that one should spend extra, when all they want is add fault tolerance to consumer grade hardware is ludicrous. We're not building an enterprise grade server here dammit! Besides, most of these solutions are rather well supported in Linux now, which means that if you screw up your fakeRAID array, you may just be able to do something about it. With a hardware proprietary non reverse engineered RAID solution on the other hand, you might not be so lucky...

Therefore, the hell with changing your BIOS settings to AHCI! If Linux doesn't bat an eyelid about accessing SATA HDDs with an ICH controller in RAID mode, why should OSX be the exception? Therefore, we'll keep our ICH BIOS settings to RAID, thank you very much, and ignore all this AHCI brainwashing.

Now, since the OSX installation media has not been designed to support ICH8 in RAID mode, if you try something like iBoot and an unmodified OSX installation media, then unless your HD is plugged on a JMicron SATA controller (which is an actual possibility on the P5B Deluxe), the OSX installer will not see it. This basically means we're gonna have to modify the OSX installation system so that it sees our ICH8R controller as AHCI ICH8 and that's also where doing the install from an 8GB (or more) USB key, that we can modify on the fly, will come real handy.

But first, we gotta create the base vanilla installer on our key.

Creating a vanilla OSX installation USB key

To do that, you need to be in your existing OSX system (VMWare, soon-to-be-ex-friend's machine, etc.). I'm going to assume that you have the vanilla OSX disk as a .dmg. The steps to create the key then are as follow:
  1. Plug in your USB key. Don't worry if it automounts.
  2. Open the OSX disk utility (Applications -> Utilities ->Disk Utilities). You should see something like "8.02 GB Generic STORAGE DEVICE Media" or something, as your USB volume
  3. Click on the "Partition" button on the left, to access the partition tab, then click on the "Current" Volume Scheme button so that you get a dropdown, and select 1 partition
  4. In options, under the partition diagram, make sure you select "GUID Partition Table". For the Format, you select "Mac OS Extended" (though it shouldn't matter)
  5. Click Apply to partition & format the USB key
  6. Once formatting is complete, select the Restore button
  7. Now double click on your OSX .dmg image to mount it (or insert your OSX DVD). A "Mac OS X Install DVD" icon should appear on your desktop
  8. Drag that icon onto the Source field of the Restore parameters in Disk Utility until a green '+' sign appears, and then drop it there
  9. For the Destination field, just drag and drop the "Untitled 1" partition, or whatever you called it, from your newly formatted USB stick
  10. Click the "Restore" button. You will be prompted for the system's administrative password.
For those who want to see it for themselves, the whole process of creating an OSX installation USB key is demonstrated by the first part of the video below (credits go to stellarola - you can ignore the Stella Magic part that comes afterwards):

The restore process will take a few minutes (15-30 mins), but, once completed, will give you the ability to install OSX from USB using iBoot.

Installing a text editor

Because we're going to do it the hard way, a must have for our USB key is a text editor, so that we can tune the USB key to our needs during the installation process (more about this in the next post). As a UNIX veteran, I swear by vi, but I do understand that not everybody is confortable with vi sequences, so to alleviate the editing process, we'll go with the more intuitive GNU nano.

One might wonder why there is no default editor on the vanilla OSX installation media, but the answer is that Apple obviously considered an installer to be read-only affair, so it made little sense adding vi or nano to the installation utilities. On the other hand, we will very much require the ability to edit files on USB, so we need a text editor for OSX. Of course, since GNU nano is GPL and therefore, anybody can legally publish a nano OSX binary to copy onto an USB key, I'm not going think twice about putting the one I conveniently recompiled from source (using Xcode 3.2) and that I am putting online here.

Once downloaded, just drag and drop the "nano" file onto your USB stick folder (where you'll see the OSX installation paraphernalia). As long as it's on the key, we're good - no need to worry about placing it into bin/ or usr/bin/ just yet. Once it's copied, you can eject the USB, as at this stage, we won't need to access another OSX system: we'll just do everything we need from USB.


Finally, the last piece we need for the installation is the latest iBoot CD (bugmenot). And while on the iBoot download page, you might as well download MultiBeast, as it will come handy to finalize our installation.

The iBoot zip basically contains an ISO which you should burn to a CD. Note that if you can't use a CD, you should be able to use that ISO image to produce an alternate iBoot loader (eg use a second USB key or TFTP), but I'm not going to detail that.