Jump to content
bcc9

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

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.

Share this post


Link to post
Share on other sites
Advertisement

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.

Share this post


Link to post
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.

Share this post


Link to post
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 ?

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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?

Share this post


Link to post
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。

Share this post


Link to post
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

Share this post


Link to post
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?

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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!!

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

z0rglub. - this new patch method did not work on my Lenovo Laptop for 10.8.1. odd. the previous patch method worked on 10.8.0.

thanks to bcc9 for sure!!! and thank you z0rglub.

Share this post


Link to post
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.

Share this post


Link to post
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 ???

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

Announcements

×