148 replies to this topic

[bcc9]

Update: Fix here, for 10.8.x:  patch-ahci-mlion.pl.0.3.zip   2.46KB   1880 downloads Description
So I've found that I need to turn off the kernelcache (UseKernelCache=no) to boot Mountain Lion DP4. Otherwise, the system hangs trying to mount the root filesystem, periodically printing "Still waiting for root device" over&over.
Now, I only have this problem with GPT partitioned disk drives. When I image the filesystem over to an MBR partitioned disk (using ditto), I can boot just fine with or without the kernelcache. All the partitions I tested were via SATA disks on the same intel SATA disk controller.

These same GPT partitioned disks can boot OSX 10.7 just fine, with or without the kernel cache, just not OSX 10.8. This is with chameleon version 1996, so I do have the current 10.8 support in the boot loader.

Most of the suggestions concerning this problem appear to be invalid.
Some are focused on general root device mounting problems (AHCI mode missing from bios, usb devices not set up right). These would seem to have nothing to do with the problem at hand, otherwise the problem should apply when the kernel cache is not used.

Others suggest 32bit vs 64bit issues, but that question goes away with DP4, as there is no 32 bit kernel/kext.

I've looked a bit deeper and I can see from the logging that the correct HFS+ UUID is picked regardless of whether or not I'm booting with the kernel cache on. (Correct "Rooting via boot-uuid from /chosen: {censored}" message is displayed).

I'm thinking that AppleFileSystemDriver.kext is failing to parse the GPT partition table when the kernel cache is used. Perhaps the kext dependencies are not being processed right, and the kernel cache is built without this kext? Anyone able to unpack /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache under mountain lion?

I've rebuilt the kernel cache (and applied the software update to dp4), but these did not fix the problem either.

I assume some hackintosh users are able to boot 10.8 via GPT partitioned disks with the kernel cache on, perhaps there are some new GPT partition layout requirements for 10.8?

[bcc9]

Update: I am able to boot from 10.8 GPT partitions with the kernelcache - sometimes.

First I converted the MBR partitioned disk to GPT (automatically using the handy gdisk). At this point I *was* able to boot 10.8 from the GPT disk with the kernel cache enabled, with or without an EFI system partition.

However, my BIOS had trouble with the EFI system partition, so I upgraded it.

On the next boot all my 10.8 GPT partitions booted fine - but just once. On subsequent boots, my first 2 10.8 GPT partitions went back to hanging trying to mount the root device (unless I boot with -f or UseKerenlCache=no) .

Perhaps 10.8 introduces new EFI dependencies that we don't know about? I don't think I can truly get to the bottom of this until the 10.8 kernel code is made available.

[bcc9]

After checking with the kernel source regarding how the root filesystem is mounted, I noticed the iokit debugging that is available after the system prints "Still waiting for root device". So I enabled that useful debugging via the boot argument: io=0x1000.

Upon booting, the debug info showed me that the system is only attaching 1 of the 3 SATA disk drives on my system; the one that is attaching is the one that boots correctly with or without the kernel cache.

So it seems that the kernel is sometimes booting without enough delay for the AHCI HDD detection to happen properly.

Does this ring a bell for anyone or am I just talking to myself here?

[fallen101]

To the Three sata devices are they one the same controller?

[bcc9]

To the Three sata devices are they one the same controller?

Yes, they are all via the PCH intel z68 sata controller
ioreg output (from when the system is booted via the 3rd disk), is as follows.

	| |   +-o SATA@1F,2  <class IOPCIDevice, id 0x100000184, registered, matched, active, busy 0 (30711 ms), retain 18>
	| |   | +-o AppleIntelPchSeriesAHCI  <class AppleIntelPchSeriesAHCI, id 0x1000001c9, registered, matched, active, busy 0 (30597 ms), retain 18>
	| |   |   +-o PRT0@0  <class AppleIntelPchSeriesAHCIPort, id 0x100000185, registered, matched, active, busy 0 (30014 ms), retain 13>
	| |   |   | +-o IOAHCIDevice@0  <class IOAHCIDevice, id 0x1000001ff, registered, matched, active, busy 0 (30014 ms), retain 15>
	| |   |   |   +-o AppleAHCIDiskDriver  <class AppleAHCIDiskDriver, id 0x1000002ad, registered, matched, active, busy 0 (3 ms), retain 7>
	| |   |   |	 +-o IOAHCIBlockStorageDevice  <class IOAHCIBlockStorageDevice, id 0x1000002ae, registered, matched, active, busy 0 (3 ms), retain 7>
	| |   |   |	   +-o IOBlockStorageDriver  <class IOBlockStorageDriver, id 0x1000002b1, registered, matched, active, busy 0 (2 ms), retain 8>
	| |   |   |		 +-o SAMSUNG SSD 830 Series Media  <class IOMedia, id 0x1000002b2, registered, matched, active, busy 0 (2 ms), retain 11>
	| |   |   |		   +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002b3, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |   |		   +-o IOGUIDPartitionScheme  <class IOGUIDPartitionScheme, id 0x1000002b5, !registered, !matched, active, busy 0 (1 ms), retain 10>
	| |   |   |			 +-o EFI System@1  <class IOMedia, id 0x1000002b8, registered, matched, active, busy 0 (0 ms), retain 9>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002be, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |   |			 +-o Linux filesystem@2  <class IOMedia, id 0x1000002b9, registered, matched, active, busy 0 (0 ms), retain 9>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002bd, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |   |			 +-o Apple_HFS_Untitled_2@3  <class IOMedia, id 0x1000002ba, registered, matched, active, busy 0 (1 ms), retain 10>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002c0, registered, matched, active, busy 0 (0 ms), retain 7>
	| |   |   |			 +-o BIOS boot partition@4  <class IOMedia, id 0x1000002bb, registered, matched, active, busy 0 (0 ms), retain 9>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002c1, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |   |			 +-o Linux filesystem@5  <class IOMedia, id 0x1000002bc, registered, matched, active, busy 0 (0 ms), retain 9>
	| |   |   |			   +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002bf, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |   +-o PRT1@1  <class AppleIntelPchSeriesAHCIPort, id 0x100000188, registered, matched, active, busy 0 (0 ms), retain 10>
	| |   |   +-o PRT2@2  <class AppleIntelPchSeriesAHCIPort, id 0x100000221, registered, matched, active, busy 0 (30029 ms), retain 11>
	| |   |   | +-o IOAHCIDevice@0  <class IOAHCIDevice, id 0x100000223, registered, matched, active, busy 0 (30029 ms), retain 20>
	| |   |   |   +-o AppleAHCIDiskDriver  <class AppleAHCIDiskDriver, id 0x1000002c2, registered, matched, active, busy 0 (15 ms), retain 7>
	| |   |   |	 +-o IOAHCIBlockStorageDevice  <class IOAHCIBlockStorageDevice, id 0x1000002c3, registered, matched, active, busy 0 (15 ms), retain 7>
	| |   |   |	   +-o IOBlockStorageDriver  <class IOBlockStorageDriver, id 0x1000002c6, registered, matched, active, busy 0 (14 ms), retain 8>
	| |   |   |		 +-o SAMSUNG HD103SJ Media  <class IOMedia, id 0x1000002c7, registered, matched, active, busy 0 (14 ms), retain 11>
	| |   |   |		   +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002c8, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |   |		   +-o IOGUIDPartitionScheme  <class IOGUIDPartitionScheme, id 0x1000002ca, !registered, !matched, active, busy 0 (2 ms), retain 15>
	| |   |   |			 +-o EFI System Partition@1  <class IOMedia, id 0x1000002cd, registered, matched, active, busy 0 (1 ms), retain 9>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002d8, registered, matched, active, busy 0 (1 ms), retain 6>
	| |   |   |			 +-o nlion@2  <class IOMedia, id 0x1000002ce, registered, matched, active, busy 0 (2 ms), retain 10>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002d9, registered, matched, active, busy 0 (0 ms), retain 7>
	| |   |   |			 +-o nsnow@3  <class IOMedia, id 0x1000002cf, registered, matched, active, busy 0 (2 ms), retain 10>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002d6, registered, matched, active, busy 0 (1 ms), retain 7>
	| |   |   |			 +-o x1@4  <class IOMedia, id 0x1000002d0, registered, matched, active, busy 0 (1 ms), retain 9>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002da, registered, matched, active, busy 0 (1 ms), retain 6>
	| |   |   |			 +-o x2@5  <class IOMedia, id 0x1000002d1, registered, matched, active, busy 0 (1 ms), retain 9>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002dc, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |   |			 +-o nsnow 2 2 2@6  <class IOMedia, id 0x1000002d2, registered, matched, active, busy 0 (1 ms), retain 9>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002dd, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |   |			 +-o nsnow 2 2 2 2 1@7  <class IOMedia, id 0x1000002d3, registered, matched, active, busy 0 (1 ms), retain 9>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002db, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |   |			 +-o nsnow 2 2 2 2 2 1@8  <class IOMedia, id 0x1000002d4, registered, matched, active, busy 0 (1 ms), retain 9>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002de, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |   |			 +-o nsnow 2 2 2 2 2 2@9  <class IOMedia, id 0x1000002d5, registered, matched, active, busy 0 (1 ms), retain 9>
	| |   |   |			 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002df, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |   |			 +-o BIOS boot partition@10  <class IOMedia, id 0x1000002d7, registered, matched, active, busy 0 (1 ms), retain 9>
	| |   |   |			   +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x1000002e0, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |   +-o PRT3@3  <class AppleIntelPchSeriesAHCIPort, id 0x100000225, registered, matched, active, busy 0 (0 ms), retain 8>
	| |   |   +-o PRT4@4  <class AppleIntelPchSeriesAHCIPort, id 0x100000227, registered, matched, active, busy 0 (0 ms), retain 8>
	| |   |   +-o PRT5@5  <class AppleIntelPchSeriesAHCIPort, id 0x100000229, registered, matched, active, busy 0 (38 ms), retain 11>
	| |   |	 +-o IOAHCIDevice@0  <class IOAHCIDevice, id 0x10000022b, registered, matched, active, busy 0 (38 ms), retain 14>
	| |   |	   +-o AppleAHCIDiskDriver  <class AppleAHCIDiskDriver, id 0x10000022c, registered, matched, active, busy 0 (35 ms), retain 7>
	| |   |		 +-o IOAHCIBlockStorageDevice  <class IOAHCIBlockStorageDevice, id 0x10000022d, registered, matched, active, busy 0 (35 ms), retain 7>
	| |   |		   +-o IOBlockStorageDriver  <class IOBlockStorageDriver, id 0x100000230, registered, matched, active, busy 0 (35 ms), retain 8>
	| |   |			 +-o ST3750330AS Media  <class IOMedia, id 0x100000231, registered, matched, active, busy 0 (35 ms), retain 11>
	| |   |			   +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x100000232, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |			   +-o IOGUIDPartitionScheme  <class IOGUIDPartitionScheme, id 0x100000234, !registered, !matched, active, busy 0 (19 ms), retain 9>
	| |   |				 +-o EFI System@1  <class IOMedia, id 0x100000237, registered, matched, active, busy 0 (0 ms), retain 9>
	| |   |				 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x10000023b, registered, matched, active, busy 0 (0 ms), retain 6>
	| |   |				 +-o Apple HFS/HFS+@2  <class IOMedia, id 0x100000238, registered, matched, active, busy 0 (19 ms), retain 10>
	| |   |				 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x10000023d, registered, matched, active, busy 0 (0 ms), retain 7>
	| |   |				 +-o Apple HFS/HFS+@7  <class IOMedia, id 0x100000239, registered, matched, active, busy 0 (18 ms), retain 11>
	| |   |				 | +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x10000023c, registered, matched, active, busy 0 (0 ms), retain 7>
	| |   |				 +-o Linux filesystem@8  <class IOMedia, id 0x10000023a, registered, matched, active, busy 0 (0 ms), retain 9>
	| |   |				   +-o IOMediaBSDClient  <class IOMediaBSDClient, id 0x10000023e, registered, matched, active, busy 0 (0 ms), retain 6>

Interestingly, the 3rd disk, the one that always probes correctly, is the slowest.

[eep357]

jeez, how many bootable ML installs do you have? No errors building the cache when booted from any of these disks and are you rebooting using the kernel cache only after it was successfully rebuilt? I don't know that's it's related per se, but I did have a problem only under mountain lion where my GPT time machine drive would cause chameleon to freeze. Had to either unplug it to boot or reformat, but the issue would return after a few backups. The solution was to format the drive using older Apple Partition scheme which is non-bootable. Since a time machine only drive should not cause this behavior, it is a bug, but could be a chameleon with ML problem vs just a ML problem

[bcc9]

jeez, how many bootable ML installs do you have? No errors building the cache when booted from any of these disks and are you rebooting using the kernel cache only after it was successfully rebuilt? I don't know that's it's related per se, but I did have a problem only under mountain lion where my GPT time machine drive would cause chameleon to freeze. Had to either unplug it to boot or reformat, but the issue would return after a few backups. The solution was to format the drive using older Apple Partition scheme which is non-bootable. Since a time machine only drive should not cause this behavior, it is a bug, but could be a chameleon with ML problem vs just a ML problem

I only installed mountain lion once, but I copied it to two other disks to troubleshoot the "waiting for root device" issue. I multiboot, so I have a bunch of other partitions.

I had noticed that booting would hang for a few minutes if I used a GPT partition table and the EFI System partition was not well formed, this is why updating my BIOS was one of my first attempted fixes. I suspect this is what you were seeing when you thought chameleon was freezing.

Yes, I've tried rebuilding the kernel cache manually and also automatically. I don't believe you have to manually rebuild the kernel cache, as touching /S/L/E is supposed to be sufficient according to OSX documentation. In any case, rebuilding the cache has made no difference.

BTW, the following is the IOServicePlane tree dump produced from the io=0x1000 debugging. This shows that only the 3rd disk was probed correctly by the OS.
 debug.jpg   236.07KB   276 downloads

[eep357]

So what happens when you only have one of the disks plugged in (the one you want to boot into obviously, which I'm guessing is the Samsung F3 and not the SSD or the Barracuda)?

[bcc9]

So what happens when you only have one of the disks plugged in (the one you want to boot into obviously, which I'm guessing is the Samsung F3 and not the SSD or the Barracuda)?

Doesn't help, I tried several combinations, and- only the older seagate boots 10.8 with caching enabled.

HOWEVER, I did stumble upon a workaround!

If I boot with debug=8 ahcidisk=1, then I can boot from any of my disks/partitions with caching enabled. Looks like the extra debug logging slows down the AHCI driver just enough that it is able to finally properly attach all 3 disks at boot time.
Seems like a pretty nasty time dependent bug in 10.8.

[eep357]

Here, this may help as well. https://ata.wiki.ker...hp/Known_issues

[bcc9]

Here, this may help as well. https://ata.wiki.ker...hp/Known_issues

I don't see how. My BIOS probes all my AHCI disks just fine always, as does linux, and OSX 10.7. The problem is unique to OSX 10.8.

[TimeWalker75a]

The problem is new AHCI kexts that are partially compatible /w series 6 chipset. If you install the lateat update (security test update) from the appstore the problem will be gone for good. Had the same issue with DP4 even after the first update. Or you could swap AppleAHCI and IOAHCIFamily out /w the kexts from Lion

[bcc9]

The problem is new AHCI kexts that are partially compatible /w series 6 chipset. If you install the lateat update (security test update) from the appstore the problem will be gone for good. Had the same issue with DP4 even after the first update. Or you could swap AppleAHCI and IOAHCIFamily out /w the kexts from Lion

That doesn't sound right, Apple added sandy bridge AHCI support as of 10.6.x, about a year ago, when they introduced sandy bridge macs like the imac12. 10.7 had proper sandy bridge support as well, and I've been using OSX on a sandy bridge hackintosh (with this same hardware) since 10.6 timeframe.

So it doesn't make sense that 10.8 DP4 would be missing some sandy bridge AHCI support when those older releases had it. Yes there's evidently a bug in their driver, but that's a bit different.

Do you have any references for this problem (was this reported somewhere?) I wouldn't have bothered with 10.8 on this machine if I had known of such an outstanding issue.

Also, I updated with the latest DP4 security test update and it made no difference. The AHCI kexts and kernel cache were updated, but I still have to boot with ahcidisk=1 debug=8 or without caching.

Perhaps a better workaround than ahcidisk=1 debug=8 would be to fix chameleon to not output reams of kext read messages when booting with -v. Then booting without the cache would still be quick and it wouldn't matter much that it had been disabled.

[TimeWalker75a]

It is a bug in thei driver since it is just a preview it is not yet perfect. Until DP3 people with series 5 chipsets had same issues. Should I point out how long these chipsets have been around ?
Look at JMicron kexts for that matter - it doesnt even have a binray in it and official updater is failing to assemble proper kernel cache because of that.
The problem has been reported numerous times on various forums (I'm mostly active on AppleLife which is a Russian community). The latest update has solved the problem for me for good. I'm not sure about Chameleon though because I'm not using it, but XPC and Clover are able to boot /w caches now .

[bcc9]

Ok, well what you are describing seems to have nothing to do with the problem I've been reporting, and I still don't see any references to your claim that DP4 only has partial AHCI support for sandy bridge. That would be pretty incredible since all of the current gen macs are sandy bridge.

In any case your proposed fix doesn't work, and upon close inspection of the DP4 security test update, the IOAHCIFamily changes are just a renumber (the code in the binary remains the same). So your info seems generally incorrect.

[eep357]

I don't have your system or hardware, so of course would be far less familiar with it than you would be. So rather than try to provide you with a possible solution to fix your's, I will instead tell you of I problem I experienced with my own, different hardware that may have nothing to do with what your dealing with. At the time I was using DP2 as it had just been released along with whatever was ErmaC's newest Chameleon branch was at that time as well. My issues came when creating a bootable clone of my working installation and the problem occurred regardless of where I made the copy, be it on the same drive or a different one. All of my internal and external HDs (10 total) except for one, were GPT at the time. Without going into the symptoms, it turned out that my DSDT would not load properly if it was included in the chameleon partition as well as the partition I was choosing to boot into, even though the logs showed no issues and indicated it was loaded successfully. Removing the extra folder from my other partitions except for my primary ML/Chameleon partition and the 2 boot OSX helper partitions on my 2 Lion RAID-0 drives, returned all to normal. Chameleon should not have had any issues dumping the first loaded one and reloading from the partition I was booting into, but it did. Just thought I'd share one of my ML experiences and I hope you are able to find the solution to yours.

[bcc9]

Yes, chameleon is capable of doing surprising things with respect to its choices for the partitions to load config state from. I assure you I'm not having such a problem.

My temporary fix of slowing the driver down with ahcidisk=1 debug=8 has been working great so far.

Also, I did try clover instead of chameleon - same result (ahcdisk=1 debug=8 required to mount root filesystem when kernel cache is enabled).

[bcc9]

Unfortunately this apparent timing bug remains in 10.8 GM. My current workaround of <key>Kernel Flags</key><string>-v ahcidisk=1 debug=8</string> is still working fine, but not really what I want to be stuck with.

So I did a bit more troubleshooting on IOAHCIBlockStorage.kext, even though it was a real pain to bisect this timing bug with a binary only driver. Through some binary patch magic, I managed to find that any one of the kprintf()s in IOAHCIBlockStorageDriver::start() that are run before the first call to IOAHCIBlockStorageDriver::IdentifyDevice() are sufficient to make all my hard disks identify properly (and thus no root device mounting problem). Without the kprintf()s outputting to the console, the IdentifyDevice() is run more quickly and my faster disks don't get identified.

Seems like there should be a config option to make the driver delay during the IdentifyDevice phase. Anyone know of such an option?

[DoiX]

Hey, i have the same problem on my laptop (only one HDD), but in my case it occurred only after DP, anyway, congrats on finding a workaround!

[bcc9]

Hey, i have the same problem on my laptop (only one HDD), but in my case it occurred only after DP, anyway, congrats on finding a workaround!

What does only after DP mean?
So does the workaround work for you?