Jump to content

Waiting for root device when kernel cache used; only with some disks +FIX


bcc9
 Share

158 posts in this topic

Recommended Posts

Curious tidbit, before the patch I could boot off the internal drive after restarting from the external 10.8 drive first. It just wouldn't start up after shutdown.

Interesting, so cold boot exhibited the timing issue but warm boot did not. I guess this would be because the drive winds up being in a different state at kernel boot time between those two cases.
Link to comment
Share on other sites

Hi, please, can you explain how use this script?

Thanks in advance.

Click on it, enter your admin password, reboot. Script is only for 10.8 GM and I didn't add checks for OS version... I (or someone else) could make an installer package for this to make the installation newbie friendly. I probably won't get to that unless this problem remains outstanding once 10.8.1 comes out.
  • Like 1
Link to comment
Share on other sites

:wink2:

bcc9 this script is also for asus main ?

Only for error still waiting for root device?

I'm not sure the set of motherboard that need this fix. Hundreds have downloaded the fix, but only a couple have reported back on what motherboard/chipset they needed the fix for. Perhaps it is most systems with sandy bridge chipsets, whose BIOS doesn't include UEFI support.

 

Yes, as far as I know, the only symptom is the "Still waiting for root device" error.

Link to comment
Share on other sites

I'm not sure the set of motherboard that need this fix. Hundreds have downloaded the fix, but only a couple have reported back on what motherboard/chipset they needed the fix for. Perhaps it is most systems with sandy bridge chipsets, whose BIOS doesn't include UEFI support.

 

Yes, as far as I know, the only symptom is the "Still waiting for root device" error.

 

Ah ok....for this problem i use IoAhciBlockstorage.kext ....you thing that i need ?

Link to comment
Share on other sites

Ah ok....for this problem i use IoAhciBlockstorage.kext ....you thing that i need ?

Not sure I understand the question. If you're
  • booting from a SATA disk
  • from an intel SATA controller
  • and the system hangs with "Still waiting for root device", unless you boot with the kext cache turned off

then I think you need this fix.

 

Or if you're booting with a "legacy" bios, and there is a UEFI bios available for your motherboard, you may be able to simply upgrade your BIOS to solve the problem.

Link to comment
Share on other sites

Click on it, enter your admin password, reboot. Script is only for 10.8 GM and I didn't add checks for OS version... I (or someone else) could make an installer package for this to make the installation newbie friendly. I probably won't get to that unless this problem remains outstanding once 10.8.1 comes out.

Thank you for creating a patch. Apple released a new update 10.8.1. The original patch has been unable to achieve the desired effect. Patch to upgrade ioahciblockstorage to repair power problem

Link to comment
Share on other sites

Thank you for creating a patch. Apple released a new update 10.8.1. The original patch has been unable to achieve the desired effect.

The patch of course will need to be updated for any new releases for which the problem persists. (Well we could get fancy with otool to make the patch adapt dynamically to future releases). Does the problem in fact remain with the stock 10.8.1 beta?

 

Almost forgot, another longer-term workaround could be a wrapper to IOAHCIBlockStorage

Link to comment
Share on other sites

Almost forgot, another longer-term workaround could be a wrapper to IOAHCIBlockStorage
Can you elaborate?

 

I actually need to solve the same problem on a non-AHCI Optiplex 745 (see signature). The effected kext is AppleIntelPIIXATA.kext (inside IOATAFamily.kext): with k-cache off or -f booting fine, wit k-cache on "Still waiting for ...". It does not matter if the kext is loaded from within IOATAFamily or directly from S/L/E.

 

Since I guess you would not know immediately which bytes of that kext to patch, a wrapper sounds as if it would come in handy. (I pretty much doubt that the "somewhat fragile debug=8 ahcidisk=1 workaround" would in any way apply to AppleIntelPIIXATA).

 

Do you have any suggestion?

Link to comment
Share on other sites

The patch of course will need to be updated for any new releases for which the problem persists. (Well we could get fancy with otool to make the patch adapt dynamically to future releases). Does the problem in fact remain with the stock 10.8.1 beta?

 

Almost forgot, another longer-term workaround could be a wrapper to IOAHCIBlockStorage

 

I am sorry my English is not very good. I can probably understand what you mean. So you mean the long-term solution to achieve.

wrapper to IOAHCIBlockStorage I am willing to be tested。

Link to comment
Share on other sites

The patch of course will need to be updated for any new releases for which the problem persists. (Well we could get fancy with otool to make the patch adapt dynamically to future releases). Does the problem in fact remain with the stock 10.8.1 beta?

 

Almost forgot, another longer-term workaround could be a wrapper to IOAHCIBlockStorage

This is the IOAHCIBlockStorage.kext from the 10.8.1 update, I very much hope you can help me to re-fix to help me solve this problem. Bluetooth and optical disk drive and repair the lostIOAHCIBlockStorage.kext.zip

IOAHCIBlockStorage.kext.zip

IOAHCIBlockStorage.kext.zip

Link to comment
Share on other sites

This is the IOAHCIBlockStorage.kext from the 10.8.1 update, I very much hope you can help me to re-fix to help me solve this problem. Bluetooth and optical disk drive and repair the lostIOAHCIBlockStorage.kext.zip

I'm still trying to come up with a better fix, perhaps it's best to stay away from 10.8 update previews in the meantime?

Also, I'd like to point out that with the tonymac threads copying this work without proper attribution it's a bit of a negative motivator.

(see my post over there if you care about the details)

Perhaps its also time for the site admins to come up with a collaboration agreement?

  • Like 2
Link to comment
Share on other sites

I'm still trying to come up with a better fix, perhaps it's best to stay away from 10.8 update previews in the meantime?

Also, I'd like to point out that with the tonymac threads copying this work without proper attribution it's a bit of a negative motivator.

(see my post over there if you care about the details)

Perhaps its also time for the site admins to come up with a collaboration agreement?

Tonymac steal research and development results. Expressing its condemnation. I will keep an eye
Link to comment
Share on other sites

I updated to 10.8.1 and hit this problem again. i tried your script and not sure it is doing any with the 10.8.1 version - no diffs on the binary?

 

any thoughts? or fixes for 10.8.1? gratefully,

 

tluck

 

of course this was the guts of your script.

 

 

#patch relocation table for our patch point - kprintf() -> IOSleep()

/usr/bin/perl -pi -e 's|\xeb\x4c\x00\x00\xea\x03|\xeb\x4c\x00\x00\xe8\x01|g' IOAHCIBlockStorage

#Make unconditional call to IOSleep(200) at beginning of kext

/usr/bin/perl -pi -e 's|\x74\x0e\x48\x8d\x3d\xa5\x90\x00\x00|\xbf\xc8\x00\x00\x00\x90\x90\x90\x90|g' IOAHCIBlockStorage

Link to comment
Share on other sites

For 10.8.1 try:

 

 

#patch relocation table for our patch point - kprintf() -> IOSleep()

/usr/bin/perl -pi -e 's|\xbb\x4b\x00\x00\xeb\x03|\xbb\x4b\x00\x00\xe8\x01|g' IOAHCIBlockStorage

#Make unconditional call to IOSleep(200) at beginning of kext

/usr/bin/perl -pi -e 's|\x74\x0e\x48\x8d\x3d\xb2\x91\x00\x00|\xbf\xc8\x00\x00\x00\x90\x90\x90\x90|g' IOAHCIBlockStorage

Link to comment
Share on other sites

First of all: Kudos to bcc9! Thanks for investigating the problem and engineering a very solid patch by finding the right string and the replacement pattern - great!

 

I ran into this problem after updating from 10.7 to 10.8 some weeks ago and bcc9's fix solved it. My hardware:

 

• Gigabyte UD3HB3 v1.3 F12

• 2x Samsung 830 256 GB (1x OS X, 1x Windows 7), 1x Samsung 1 TB HD 2.5"

 

All drives are connected to SATA Ports of the Intel chipset, additional SATA Ports are disabled. AHCI is enabled in BIOS of course.

 

After updating to 10.8.1 yesterday the problem occurs again and the initial patch didn't work. I've just found z0rglub's post and I can confirm that the changes are working. I've just booted with installed 10.8.1 update and patched

IOAHCIBlockStorage with z0rglub's modified patch.

 

 

Side notes:

I have 4 hackintoshs on duty, all built with Gigabyte UD3HB3 v1.3 F12 and installed 10.8. Interestingly the problem doesn't occour on all computers, two of them boot without any modification on IOAHCIBlockStorage. These ones have another disk setup (1x Samsung 830 256 GB/1x Intel 330 300 GB/1x Harddisk), everything else is identic (BIOS settings, Software versions etc.).

 

 

Thank you for you great work!!

Link to comment
Share on other sites

For 10.8.1 try:

 

 

#patch relocation table for our patch point - kprintf() -> IOSleep()

/usr/bin/perl -pi -e 's|\xbb\x4b\x00\x00\xeb\x03|\xbb\x4b\x00\x00\xe8\x01|g' IOAHCIBlockStorage

#Make unconditional call to IOSleep(200) at beginning of kext

/usr/bin/perl -pi -e 's|\x74\x0e\x48\x8d\x3d\xb2\x91\x00\x00|\xbf\xc8\x00\x00\x00\x90\x90\x90\x90|g' IOAHCIBlockStorage

 

Thanks z0rglub! Confirming this works for 10.8.1 running on Gigabyte Z68X-UD3H-B3 rev 1.3 F12 bios.

Link to comment
Share on other sites

Guys, it seem the 10.8.2 update will have an updated IOAHCIBlockStorage.kext (2.2.2), which will require patching as well as the previous versions, I've just tested the kext from the 10.8.2 beta combo update and got the Still waiting for root device message immediately after the restart.

Link to comment
Share on other sites

why don't all you guys simply use the working 10.8 patched kext? It's just a driver, nothing more - when it's working for you, it's working. Rather than aiming to click and have a non-working system, why not click (kext wizard etc.) and have a working system (no matter if the driver reads 10.8 or 10.8.1 ???

Link to comment
Share on other sites

why don't all you guys simply use the working 10.8 patched kext? It's just a driver, nothing more - when it's working for you, it's working. Rather than aiming to click and have a non-working system, why not click (kext wizard etc.) and have a working system (no matter if the driver reads 10.8 or 10.8.1 ???

 

If Apple updates the kext then it means they improved it, fixed bugs or added new hardware, so you may be losing many benefits that way. Besides when you revert a kext there could be some dependencies issues with other kexts or frameworks, so it's not a flawless solution either.

Link to comment
Share on other sites

OK that's true. If it's all still really only about the timeout then I'd suggest a different approach rather than patching: move the kext out of S/L/E, set correct perms to it on the new location, load it via startup script with a delay in the line before the kext gets loaded. This has been done to other kexts over the h'tosh years.

Link to comment
Share on other sites

 Share

×
×
  • Create New...