Still Waiting for Root Device is an all-too common issue among OSx86 installs.

It affects both dvd drives (ie "Still Waiting for Root Device" when you try to boot up an osx86/retail Mac OS X dvd) and hard drives (after you've successfully installed with an osx86/retail Mac OS X dvd).

This problem occurs when your southbridge chipset does not have a working kext or "driver" to make it work properly. Most prepatched dvds (iATKOS, kalyway, JaS, XxX, etc) have some of these kexts available for installation already, but to use a retail installation, the preboot media must be supplied with the proper kext/s required by the OS.

I will repeat, just so this is crystal, damn, clear. If you are getting "Still Waiting for Root Device", you need a driver for your southbridge controller. For example, in this randomly picked HP, see how it says "Chipset: Intel P965" ?
You then look up the list of intel chipsets, and find the corresponding southbridge (in this case, ICH8R, which is natively supported). If it weren't natively supported you would say "Hmmm, I need a southbridge [where the ATA/SATA controller is] driver for my _____ chipset", and you would try to find an ATA/SATA driver for that chipset.

This can be further complicated by the fact that Apple only ever made OS X kernel extensions that work with specific chipsets, so some chipsets like certain nVidia nForce, AMD, ATI, SiS, & VIA (to name the biggest ones) either don't work properly, or have very little support, such as only IDE support or only SATA support, or AHCI support and not all three at the same time like they should. This is how it's able to install with a dvd, and then fail on the boot to the hard drive, if they are on different interfaces. If you're using one of the above mentioned chipsets and booting from the dvd is not working, try switching interfaces (ie going from an IDE dvd drive to SATA, or SATA to IDE, or last but not least, a USB dvd drive).

Common, well-supported chipsets which practically never see this problem as they are natively supported by Apple are: ICH6, ICH7, ICH8, nVIdia nForce MCP79, and most recently ICH10.

Support can be provided for many other southbridges, including, but not limited to, the following:

ICH9
MCP67

*Note*: After 10.5.7 was released the ICH10 chipset became supported natively by Apple.

The kexts that control AHCI mode are IOAHCIFamily.kext , which has two further kexts under it (IOAHCIBlockStorage.kext and IOAHCISerialATAPI.kext), and AppleAHCIPort.kext.



We see above an entry in the AppleAHCIPort.kext/Contents/Info.plist. This tells OS X a lot of information. The first key (MCP79) just establishes the name for it.

Next comes the Bundle Identifier, com.apple.driver.AHCIPort. Apple has the following to say about bundles:



You can also see the bundle identifier here in the kextstat command (the actual command I ran was kextstat | grep AHCI, I only wanted to see AHCI info.



So it's just a way of identifying it.

Chipset name comes next, same thing as the original key entry, you can see where the chipset name is shown in About This Mac, more info, Serial ATA section.



The Vendor name from the bottom has also been thrown before it by the OS, for identification purposes.

You see next the IOClass. The IOKit of OS X has some personalities/conventions, the IOClass is the name that the IOKit will instantiate when probing the hardware. If you really want to get further into this subject, the conceptual bits of IOKit matching is a good start (not light reading, you've been warned

Next comes a rather important part, the IOPCIPrimaryMatch. Anyone who knows anything about the PCI bus knows that hardware pieces have a vendor and device id. Lots more info at http://pcidatabase.com . These numbers are encoded into the hardware, and the OS looks for these numbers when matching against valid hardware. The Vendor ID in this case is 10de (the normal NVidia Vendor ID) and 0ab9 (the particular Device ID of my NVidia chipset).

It is important to note that extra entries can be made, or existing entries modified

Next comes the IOProbeScore. Loosely this can be thought of "the importance/order this kext is loaded", however it's reversed, the lower the number means the higher the priority.

Apple has the following to say (still on that page I linked to above) about the IOProvidor Class:



For the purposes of explanation, it matches against the PCI bus

Last but not least, the Vendor name, self-explanatory.