Contribute
Register

"Still waiting for accelerator to start..." and "Still waiting for root device..."

Status
Not open for further replies.
Ok, so I unplugged everything SATA except the SSD that I put OSX on. Booted up, same issue "Still Waiting for Root Device". -f still gets me in. So does this narrow down what would be causing the problem?

-f is booting without kernel caches / kext caches. Try rebuilding the via Kext Wizard or terminal commands and see if you can boot into the OS. If you can't, you may want to look into it further or just add -f to your boot-args.
 
-f is booting without kernel caches / kext caches. Try rebuilding the via Kext Wizard or terminal commands and see if you can boot into the OS. If you can't, you may want to look into it further or just add -f to your boot-args.

Ok, cool, I will try that. How would I make my audio work though? When I boot with -f, my audio DSDT seems to have stopped working.
 
hi man,

i was struggling with the same exact problem your having for 2 days. fortunately i have the same build as you do except for the graphics card which i don't think that the problem has to do with anyways.

i did everything you did, removed hdds, usb sticks, tried to delete some kexts and change bootflags etc with no luck....what resolved the problem for me was to "rebuild caches" and "repair permissions" using kext wizard AFTER installing the following with multibeast:

-ddst free
-3d party sata
-trim enabler
-usb 3.0
-evoboot
-fakesmc (not the plugins)
-nullcpupowermanagement
-voodootsync 6 cores

i didn't install any audio drivers as i have a firewire audio device. also my network card seems to work out of the box so i didn't install any network drivers.

in extra/org.chameleon.plist i added: kext-dev-mode=1 npci=0x2000 under kernel flags.

after your done installing multibeast stuff and modifying the org.chameleon.plist, download kext wizard 3.7.1.1 and open it, select your hard drive and rebuild caches+repair permissions. restart and your good to go.

this is what worked for me i restarted 6 times to make sure that it wasn't a coincidence :)

hope this helps you out

cheers
 
Thanks much egmusician! I shall try your solution out. Although, if it doesn't work, do you think I should just go with a nice USB audio solution like the Focusrite Scarlet or something? It might eventually be a necessity anyways if I purchase professional monitors in the future. Literally the only problem I'm having with -f is no audio. And thusly no video editing capability due to Quicktime's error -101.

Also, after i have installed everything, rebuilding the cache and permissions with Kext Wizzard has no affect for me. So just to clarify, you used the rebuild cache and permissions functions immediately after you installed the multibeast goods? Was there a reboot in between there?

Thanks much all.
 
hi man,

i was struggling with the same exact problem your having for 2 days. fortunately i have the same build as you do except for the graphics card which i don't think that the problem has to do with anyways.

i did everything you did, removed hdds, usb sticks, tried to delete some kexts and change bootflags etc with no luck....what resolved the problem for me was to "rebuild caches" and "repair permissions" using kext wizard AFTER installing the following with multibeast:

-ddst free
-3d party sata
-trim enabler
-usb 3.0
-evoboot
-fakesmc (not the plugins)
-nullcpupowermanagement
-voodootsync 6 cores

i didn't install any audio drivers as i have a firewire audio device. also my network card seems to work out of the box so i didn't install any network drivers.

in extra/org.chameleon.plist i added: kext-dev-mode=1 npci=0x2000 under kernel flags.

after your done installing multibeast stuff and modifying the org.chameleon.plist, download kext wizard 3.7.1.1 and open it, select your hard drive and rebuild caches+repair permissions. restart and your good to go.

this is what worked for me i restarted 6 times to make sure that it wasn't a coincidence :)

hope this helps you out

cheers

Ok, so I reinstalled, booted in for the first time and ran multibeast. I did however install my network and sound drivers and 1080p boot mode. I modified the org.chameleon.plist to the same parameters as you said (which were my normal parameters anyway). Then I used the copy of Kext Wizzard that I had on one of my hard drives to rebuild caches+repair permissions.
Reset
Booted in again, and implemented my dsdt for working audio.
Reset
"Still waiting for root device"
Ugh....

So then I booted in with -f and tired doing the same commands on Kext Wizzard again. Rebooted with no luck. Still waiting on that root device. The interesting part is that it happened earlier this time. And it was not off-set by the cuda driver install (didn't get a chance to even install it).

So now I'm thoroughly stumped. Was there something wrong with the process I used just now?
Idk if this will help but here's a list of my SATA devices:

--240 GB Kingston SSD now (this is the OS drive and is installed on SATA 0)
--250 GB Samsung EVO
--250 GB Samsung EVO (both are installed as RAID 0 at the software level and somehow reinstalling Yosemite never breaks that...)
--1TB Western Digital Black
--250 GB old Apple branded WD HDD


Thanks everyone for your continuous help. Lets see if we can finish this.
 
Ok, so I reinstalled, booted in for the first time and ran multibeast. I did however install my network and sound drivers and 1080p boot mode. I modified the org.chameleon.plist to the same parameters as you said (which were my normal parameters anyway). Then I used the copy of Kext Wizzard that I had on one of my hard drives to rebuild caches+repair permissions.
Reset
Booted in again, and implemented my dsdt for working audio.
Reset
"Still waiting for root device"
Ugh....

So then I booted in with -f and tired doing the same commands on Kext Wizzard again. Rebooted with no luck. Still waiting on that root device. The interesting part is that it happened earlier this time. And it was not off-set by the cuda driver install (didn't get a chance to even install it).

So now I'm thoroughly stumped. Was there something wrong with the process I used just now?
Idk if this will help but here's a list of my SATA devices:

--240 GB Kingston SSD now (this is the OS drive and is installed on SATA 0)
--250 GB Samsung EVO
--250 GB Samsung EVO (both are installed as RAID 0 at the software level and somehow reinstalling Yosemite never breaks that...)
--1TB Western Digital Black
--250 GB old Apple branded WD HDD


Thanks everyone for your continuous help. Lets see if we can finish this.

Try removing all of your hard drives except the one that has your OS on it.
 
No luck with that. I even tried repairing the permissions and rebuilding the kexts after unplugging the rest of the hard drives. Even removed my audio DSDT. Nothing. :rolleyes:
 
No luck with that. I even tried repairing the permissions and rebuilding the kexts after unplugging the rest of the hard drives. Even removed my audio DSDT. Nothing. :rolleyes:

It sounds like in between using MB for downloading your kexts to using Kext Wizard to rebuild cache + repair permissions and implementing DSDT that you mess up somewhere and it says that. I was going to say to remove your DSDT as it booted fine before that but you already did that ... :think:

By "Audio DSDT", do you mean like native DSDT + audio patches? You may need to make sure it's clean of any errors and such.
 
It sounds like in between using MB for downloading your kexts to using Kext Wizard to rebuild cache + repair permissions and implementing DSDT that you mess up somewhere and it says that. I was going to say to remove your DSDT as it booted fine before that but you already did that ... :think:

By "Audio DSDT", do you mean like native DSDT + audio patches? You may need to make sure it's clean of any errors and such.


Yeah, there has to be something I'm doing wrong. But whats weird is it all worked great before. Now it seems that any reset I do beyond the multibeast driver install reboot makes the root device error occur.

My process for that was grab the current dsdt using MaciASL\New from ACPI\DSDT
After getting no errors on compiling that, I moved on and implemented toleda's patch. I compiled that also with no errors. I placed the final dsdt (named dsdt.aml) in my extra folder and my desktop. Then I rebooted. So yes I think that's DSDT + audio patches.

I'm not sure where to begin, because if you'll recall, this problem also occurred when I tried installing the CUDA drivers before the Audio DSDT. But here's some of my suspicions:

-Could there be a lingering boot partition from my Clover experiments?
-Could there be a lingering boot partition t all? lol
-Lingering EFI boot partition?
-Why does this not occur immediately or after the first reboot?

Thanks for sticking with me on this.
 
Yeah, there has to be something I'm doing wrong. But whats weird is it all worked great before. Now it seems that any reset I do beyond the multibeast driver install reboot makes the root device error occur.

My process for that was grab the current dsdt using MaciASL\New from ACPI\DSDT
After getting no errors on compiling that, I moved on and implemented toleda's patch. I compiled that also with no errors. I placed the final dsdt (named dsdt.aml) in my extra folder and my desktop. Then I rebooted. So yes I think that's DSDT + audio patches.

I'm not sure where to begin, because if you'll recall, this problem also occurred when I tried installing the CUDA drivers before the Audio DSDT. But here's some of my suspicions:

-Could there be a lingering boot partition from my Clover experiments?
-Could there be a lingering boot partition t all? lol
-Lingering EFI boot partition?
-Why does this not occur immediately or after the first reboot?

Thanks for sticking with me on this.

Getting a new ACPI DSDT from MaciASL is not recommended imo, extracting ACPI tables (DSDT, SSDT, etc.) from Linux (i.e. Ubuntu) is recommended for a more accurate extraction. Try doing that and re-applying your audio patches.

If you have a lot of fragments of left over Clover files, you should just wipe your hard drive completely and start over, as those may be conflicting. Same solution for your "lingering boot partition", "EFI boot partition" suspicions.

And at this point it's almost certain that doing something in MB is preventing it from booting properly or improperly detecting your HDD.
 
Status
Not open for further replies.
Back
Top