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>GenericAHCI</key>Well, well, well, is that our 0x0106 generic AHCI class right there?
<dict>
<key>CFBundeIdentifier</key>
<string>com.apple.driver.AppleAHCIPort</string>
<key>Chipset Name</key>
<string>AHCI Standard Controller</string>
<key>IOClass</key>
<string>AppleAHCI</string>
<key>IOPCIClassMatch</key>
<string>0x01060100&0xffffff00</string>
<key>IOProbeScore</key>
<integer>800</integer>
<key>IOProviderClass</key>
<string>IOPCIDevice</string>
<key>Vendor Name</key>
<string>Unknown</string>
</dict>
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.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:
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
- 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)
- 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 issuingmount
- 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. - Navigate to the Info.plist file we want to edit with
cd /System/Library/Extensions/AppleAHCIPort.kext/Contents/
and run nanonano Info.plist
- Change the
<string>0x01060100&0xffffff00</string>
line in the<key>GenericAHCI</key>
section to<string>0x01060100&0xffffff00 0x01040000&0xffff0000</string>
- Save the file (Ctrl-X then 'y' to save it)
- navigate to the /System/Library/ directory with
cd /System/Library/
. This is the directory that contains the Extensions.mkext file - 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. - 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:
- When OSX installs, it will extract and install its own unmodified AppleAHCIPort kext (from the
Essentials.pkg
found inSystem/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! - 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...
Great Tutorial! Im looking to do this process on my msi laptop which has two hard drives and support for raid 0. i hope it works, trying tomorrow
ReplyDeletehey so i managed to get to the part where I had to edit the info.plist file, but i am doing it in Lion. the problem im having is that the original line says "0x01060100"&";0xffffff00"(so after the "&" there is "amp;" in between the VID:PID.
ReplyDeleteI tried inserting "0x01060100&0xffffff00 0x01040000&0xffff0000" and "0x01060100&"amp;"0xffffff00 0x01040000&"amp;"0xffff0000"
and both tries did not reveal my two RAID 0 partitions. (the & was being removed by this text box when trying to post so I used quotes to show what i was writing)
Any suggestions? (I would forever be grateful fr your help)
YEah I seconded that i have tried both strings with and with out the "&"
ReplyDeleteI am having issues rebuilding the kext cache.. it wont do it at all.. says error in line 26 which is the line you show how to modify... I have done it exactly how your wrote it without the underlying amp appearing!
ReplyDeletesorry line 36
ReplyDeleteI haven't tried Lion yet, but it looks like Apple may have done something with regards to escaping the ampersand as well as how one may handle multiple device IDs from one driver. I suppose that if Apple uses the escaped ampersand, then this is what needs to be used for Lion (and there is no reason why it shouldn't work when adding another ID), thus the problem may have to do with handling multiple IDs.
ReplyDeleteCan you check other .plist files from Lion to see how they handle multiple IDs?
hi all,
ReplyDeletegreat tutorial,
can see now all partitions and both disks of raid1 ....but how can i install it as raid1 in osx...on both disks?? can just see the disks separate...