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

1. Make sure "patch-ahci-mlion" is on your desktop.

2. Open Terminal.app. (/Applications/Utilities/Terminal.app)

3. Enter the following three lines, one at a time, pressing enterafter each one.

cd ~/Desktop 
chmod +x ./patch-ahci-mlion
./patch-ahci-mlion

4. Done!

 

If you want to revert the change, run

sudo mv /System/Library/Extentions/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorage.kext/Contents/MacOS/IOAHCIBlockStorage.orig /System/Library/Extentions/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorage.kext/Contents/MacOS/IOAHCIBlockStorage

 

Hope this helps!

Link to comment
Share on other sites

  • 4 weeks later...

bcc9, you are the best!. For several days i was trying to resolve a issue related with my Video Card HD3000 (artifacts after reboot). This happend because, I was forced to put Flag: UseKernelCache=No. Otherwise I could not boot (Error: Still Waiting for root device). Now thanks to you, i can set this Flag to Yes!! The patch is awesome, and the implications for me. Go far beyond.

 

THANK YOU!

Link to comment
Share on other sites

Hi everybody, I have a problem with "Still waiting for root device" that is driving me absolutely mental.

 

After spending a while in windows, I will get this error and I can't seem to figure out how to fix it, it tends to just fix itself but it's not working anymore. I have had a working osx installation for a while but now I've suddenly started seeing this error. Grrr!

 

I'm running a 3570k on a z77 Gigabyte UEFI motherboard, with 10.8.3 and clover bootloader - I've tried booting without the cache, tried debug=8 and ahcidisk=1, tried clover and chameleon, nothing seems to work, I always, without fail get the still waiting for root device error. I can't get into osx at all. I am running off a Samsung 840 SSD.

 

I've also tried booting with the installer usb I made, and now I can't see the drives in the osx installer anymore, although they are on chameleon and clover.

 

Any ideas would be appreciated so much!

Edited by benjyyyy
Link to comment
Share on other sites

  • 2 weeks later...

The patch is awesome, and the implications for me. Go far beyond.

Thank you. Implications far beyond? Sounds ominous. :)

 

 

just boot skipping the loading of kernelcache (-f flag for chameleon/chimera, WithKexts flag for clover, ForceLoadKernelcache=0 for XPC) and you will get into OSX installation.

then apply the patch and boot with kernelcache thereafter.

Thanks for replying, yes, exactly. If you can't boot with the kernel cache turned off, then you're having a different problem than the one described in this thread, more likely one of the general root device issues described in this thread:

http://www.insanelymac.com/forum/topic/278075-about-still-waiting-for-root-device/

 

PS: Moderators, it would be good for that FAQ to reference this thread (or even a new more newbie friendly explanation of this issue).

 

Hi everybody, I have a problem with "Still waiting for root device" that is driving me absolutely mental.

 

benjyyyy, since you're seeing the error even without a cache, you're probably having a more general boot device issue such as described in the FAQ I just referenced.

 

Link to comment
Share on other sites

It's nice to still have you actively involved bcc9! Thanks for your input and hard work. Do you anticipate changes to your script with the upcoming 10.8.3 update?

I should be able to put together a new version that just gets all the necessary patches from an auto-generated config file. Then there shouldn't need to be any release-to-release maintenance necessary until if&when Apple restructures this kext significantly.

I did already write the auto-gen part before all the hubbub with tonymac folks copying this patch without credits. Just have to find time to package things up, which I'll try to do now (don't need to wait for the 10.8.3 release actually).

 

  • Like 2
Link to comment
Share on other sites

Here is a new version of the patch script for folks to try.

I'll move this to post #1 once there's some feedback that it's working OK for folks.

The zip includes 3 files:

patch-ahci-mlion.pl		The patch script itself, as before
patch-ahci.config		The config file with the patches, includes 10.8, 10.8.1, 10.8.2 patch addresses already.
patch-ahci-mlion-addrs.pl	A new script to generate the config file

This new script can be used to auto-update the patch configuration when a new OSX release comes out. This script requires xcode command line tools to determine its patches. Users who do not have xcode can simply download an updated version of patch-ahci.config from anyone else who has run the config file generation script for the new OSX release.

 

I do not expect to have to maintain patch-ahci.config going forward. Which is good as I do not want to maintain it and likely won't have time to. Users are free to post updated versions of the patch config for others who do not wish to install the xcode command line tools.

 

Example usage of the patch script:

% ./ahci-generate-patch-config.pl
No existing patch config file was found; a new one will be generated.
Adding patch for OSX 10.8.2:
$patch = \{
		 'relocation_offset' => 19083,
		 'kprintf_arg' => 37490,
		 'kprintf_relocation_index' => '1003',
		 'IOSleep_relocation_index' => '488',
		 'osx_version' => '10.8.2'
	 };
% ./ahci-generate-patch-config.pl
Patch for this OSX version already present in config file
% 

patch-ahci-mlion.0.4.zip

  • Like 4
Link to comment
Share on other sites

Hello bcc9 first of all, thanks for your work.

 

Today I upgraded to 10.8.3 and have tried the latest update of your script.

 

In the configuration file, i can look:

 

{

'relocation_offset' => 22475,

'kprintf_arg' => 0,

'kprintf_relocation_index' => '1006 '

'IOSleep_relocation_index' => '490 ',

'osx_version' => '10 .8.3 '

}

 

But I could not patch, I receive the following error:

 

Unexpected patch count: 1 (2 expected)

Aborting with IOAHCIBlockStorage NOT patched

 

Is it related to 'kprintf_arg' => 0?

 

Thanks in advance for your answer

Link to comment
Share on other sites

I've made the observation, that the patch isn't neccessary for 10.8.3 anymore on my Gigabyte UD3H B3 Boards with F12 BIOS. Last times after major upgrades (10.8.0, 10.8.1 & 10.8.2) machines didn't boot, this time booting is possible without any problems without patching the kext inside IOAHCIFamily...

Link to comment
Share on other sites

Hello bcc9 first of all, thanks for your work.

 

Today I upgraded to 10.8.3 and have tried the latest update of your script.

 

In the configuration file, i can look:

 

{

'relocation_offset' => 22475,

'kprintf_arg' => 0,

'kprintf_relocation_index' => '1006 '

'IOSleep_relocation_index' => '490 ',

'osx_version' => '10 .8.3 '

}

 

But I could not patch, I receive the following error:

 

Unexpected patch count: 1 (2 expected)

Aborting with IOAHCIBlockStorage NOT patched

 

Is it related to 'kprintf_arg' => 0?

 

Thanks in advance for your answer

 

I was hoping this would fix my Kernel cache issues but sadly I got the same error......

Also, 10.8.3 did not fix the fact that I can only boot my system with -f or -v flags. :(

Link to comment
Share on other sites

 

Is it related to 'kprintf_arg' => 0?

 

Thanks in advance for your answer

Yes, kprintf_arg must not be 0 for this to work. I don't know how you two are getting this to fail. Though I didn't have 10.8.3 when I wrote the script, I tried it last night and it worked for me:

% ./ahci-generate-patch-config.pl
Adding patch for OSX 10.8.3:
$patch = \{
'relocation_offset' => 22475,
'kprintf_arg' => 38002,
'kprintf_relocation_index' => '1006',
'IOSleep_relocation_index' => '490',
'osx_version' => '10.8.3'
};

Maybe you could try again with ahci-generate-patch-config.pl -v -v -v -v

so that we can see what's going on in the failure case.

 

I was hoping this would fix my Kernel cache issues but sadly I got the same error......

Also, 10.8.3 did not fix the fact that I can only boot my system with -f or -v flags. :(

It's possible that 10.8.3 changed the timing enough that some people no longer need the patch and some people still do. I no longer need the patch in any release as I upgraded my BIOS to a UEFI version and the problem went away. So I need you guys to report back as to whether or not this fix is necessary in some cases.

 

Did my script work for you in 10.8.2? Did it work for you in 10.8.3? If not in 10.8.3, was it because you didn't have patch-ahci.config updated for 10.8.3?

 

Here's an updated patch-ahci.config that includes 10.8.3 for those who don't have otool to run ahci-generate-patch-config.pl

patch-ahci.config.zip

Link to comment
Share on other sites

I've made the observation, that the patch isn't neccessary for 10.8.3 anymore on my Gigabyte UD3H B3 Boards with F12 BIOS. Last times after major upgrades (10.8.0, 10.8.1 & 10.8.2) machines didn't boot, this time booting is possible without any problems without patching the kext inside IOAHCIFamily...

 

Same situation for my Z68AP-D3 since 10.8.3. And I've installed the combo just in case and the kext is indeed the new one.

Link to comment
Share on other sites

@bcc9

thanks for posting...

 

for 10.8.3 i was able to boot without the patch.

 

but perhaps for those that need it, I too got 0x0 for kprint_arg - here is the output from my system using xcode 4.6.

 

 

./ahci-generate-patch-config.pl -v -v -v -v
OS version: 10.8.3
Kext /System/Library/Extensions/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorage.kext/Contents/MacOS/IOAHCIBlockStorage
00000000000057a8 pushq %rbp
00000000000057a9 movq %rsp, %rbp
00000000000057ac pushq %r15
00000000000057ae pushq %r14
00000000000057b0 pushq %rbx
00000000000057b1 pushq %rax
00000000000057b2 movq %rsi, %r14
00000000000057b5 movq %rdi, %rbx
00000000000057b8 testb $1, 67937(%rip)
00000000000057bf je 0x57cf
00000000000057c1 leaq 38002(%rip), %rdi
00000000000057c8 xorb %al, %al
00000000000057ca callq 0x57cf
$relocation_offset=0x57cb;
$kprintf_arg=0x0;
IOSleep address: 00002f39
Kprintf address: 000057cb
$IOSleep_relocation_index=490;
$kprintf_relocation_index=1006;
Patch for this OSX version already present in config file

tluck@toms-mac /Extra/10.8.x-build/patch-ahci-mlion
$ ./ahci-generate-patch-config.pl
Patch for this OSX version already present in config file

tluck@toms-mac /Extra/10.8.x-build/patch-ahci-mlion
$ ./ahci-generate-patch-config.pl -v
OS version: 10.8.3
$relocation_offset=0x57cb;
$kprintf_arg=0x0;
$IOSleep_relocation_index=490;
$kprintf_relocation_index=1006;
Patch for this OSX version already present in config file

Link to comment
Share on other sites

  • 4 weeks later...

@bcc9

thanks for posting...

 

for 10.8.3 i was able to boot without the patch.

 

but perhaps for those that need it, I too got 0x0 for kprint_arg - here is the output from my system using xcode 4.6.

I missed this post or I would have responded before. Thanks for the debug output. Turns out xcode as of 4.6 now is outputting some fields in decimal, some in hexadecimal, with apparently no way to control the output style, whereas xcode 4.5 and earlier used hex operands for pretty much everything.

So that is why the patch update script was failing for some users.

 

In any case, since nobody seems to be having this problem as of 10.8.3, it looks like the extra automation work was for nothing. Maybe maintainers of some of the other OSX hackintosh binary patches can learn how to automate their release-to-release patch maintenance from this.

 

Ordinarily I'd fix the script to handle xcode 4.6, but since it's apparently not in use...

  • Like 3
Link to comment
Share on other sites

@bcc9 - i was ever so grateful for your script when i was on 10.8.0 -> 10.8.2 (i needed a looooooong delay to scan devices). confirming your assessment - as of 10.8.3, the standard kext is working without any patching and now the system boots up in record time! Thanks again.

Link to comment
Share on other sites

  • 2 weeks later...

I would also like to thank again bcc9 for his patch and script (you definitely gained more knowledge than the rest of us!) it was definitely necessary for 10.8.2. Now on my Gigabyte H61N-USB3 both SATA devices boot normally (in speed) with 10.8.3 indeed. But don't abandon it just yet, as 10.8.4 is around the corner and might bring back "old memories" :-) You never know with Apple! Thanks, bcc9

  • Like 1
Link to comment
Share on other sites

  • 4 months later...
 Share

×
×
  • Create New...