Yosemite successfully boots once, but not again

[mgelax]

My first attempt at building a Mac is going a little bumpy. I eventually got everything installed, but it took a bit to get multibeast working correctly. After all is done post-installation, the machine boots up wonderfully the first time. When I turn it off and then turn it back on, it fails. When the Apple symbols shows and it's loading, it goes slowly, then all it shows is the no/not symbol (0 with a slash through it).

I have a Gigabyte GA-Z97N-WIFI with the i5 4690k, no video card. The SSD is Crucial M500 240GB. I can remove the SSD and run multibeast on it again (from another Mac) and then it boots up perfectly, but only once.

Here are my MultiBeast settings:
<paste>
MultiBeast Configuration - 2014-12-13 11:04:20-----------------------------------------------------------------
Quick Start > DSDT Free
Drivers > Audio > Realtek ALCxxx > ALC892
Drivers > Audio > Realtek ALCxxx > Optional 3 Port (5.1) AudioDrivers > Disk > 3rd Party SATA
Drivers > Disk > Intel Generic AHCI SATA
Drivers > Disk > TRIM Enabler > 10.10.x TRIM Patch
Drivers > Graphics > Intel Graphics Patch for Mixed ConfigurationsDrivers > Misc > FakeSMC v6.11.1328
Drivers > Misc > PS/2 Keyboard/Mice and Trackpads
Drivers > Misc > USB 3.0 - Universal
Drivers > Network > Atheros > ALXEthernet v1.0.2
Drivers > Network > Intel > AppleIGB v5.2.9.4
Bootloaders > Chimera v4.0.1
Customize > Boot Options > Basic Boot Options
Customize > Boot Options > Generate CPU States
Customize > Boot Options > Hibernate Mode - Desktop
Customize > Boot Options > Kext Dev Mode
Customize > Boot Options > Use KernelCache
Customize > System Definitions > Mac Pro > Mac Pro 3,1Customize > Themes > tonymacx86 Black
</paste>

Any thoughts? I can get more details if needed.

 

[MIcahTautkus]

I'm having a similar issue . Try booting with -v to get a verbose readout and tell us what the last stop of text is.

 

[AGuyWhoIsBored]

My first attempt at building a Mac is going a little bumpy. I eventually got everything installed, but it took a bit to get multibeast working correctly. After all is done post-installation, the machine boots up wonderfully the first time. When I turn it off and then turn it back on, it fails. When the Apple symbols shows and it's loading, it goes slowly, then all it shows is the no/not symbol (0 with a slash through it).

I have a Gigabyte GA-Z97N-WIFI with the i5 4690k, no video card. The SSD is Crucial M500 240GB. I can remove the SSD and run multibeast on it again (from another Mac) and then it boots up perfectly, but only once.

Here are my MultiBeast settings:
<paste>
MultiBeast Configuration - 2014-12-13 11:04:20-----------------------------------------------------------------
Quick Start > DSDT Free
Drivers > Audio > Realtek ALCxxx > ALC892
Drivers > Audio > Realtek ALCxxx > Optional 3 Port (5.1) AudioDrivers > Disk > 3rd Party SATA
Drivers > Disk > Intel Generic AHCI SATA
Drivers > Disk > TRIM Enabler > 10.10.x TRIM Patch
Drivers > Graphics > Intel Graphics Patch for Mixed ConfigurationsDrivers > Misc > FakeSMC v6.11.1328
Drivers > Misc > PS/2 Keyboard/Mice and Trackpads
Drivers > Misc > USB 3.0 - Universal
Drivers > Network > Atheros > ALXEthernet v1.0.2
Drivers > Network > Intel > AppleIGB v5.2.9.4
Bootloaders > Chimera v4.0.1
Customize > Boot Options > Basic Boot Options
Customize > Boot Options > Generate CPU States
Customize > Boot Options > Hibernate Mode - Desktop
Customize > Boot Options > Kext Dev Mode
Customize > Boot Options > Use KernelCache
Customize > System Definitions > Mac Pro > Mac Pro 3,1Customize > Themes > tonymacx86 Black
</paste>

Any thoughts? I can get more details if needed.

Try booting without kernel cache, using boot flag "-f".

 

[mgelax]

Try booting without kernel cache, using boot flag "-f".

The -f seems to fix it. I then figured I should turn it off in the multibeast setup. I turn it off in that and then rerun multibeast on the drive (on another machine). In verbose mode I can see that kernel cache isn't actually disabled when that is set. Would I have to run a -f everytime? How would I make that permanent?

Every time It hangs, it appears to be waiting for the root device. From the previous line items, it appears that it can't load the filesystem on the SSD. Is this something that the DSDT fixes (I'm not entirely sure what that does or if I need it with a Z97)

Also, now it seems as if the bluetooth device isn't loading properly.
logs show:
<paste>
Dec 14 11:52:43 MACHINENAME kernel[0]: **** [IOBluetoothHCIController][ProcessBluetoothTransportShowsUpActionWL] -- Error!! -- Something went wrong in the setup process. Could not communicate with Bluetooth Transport successfully -- 0xa800 -- 0x1800 ****
Dec 14 11:52:53 MACHINENAME kernel[0]: [[0xffffff80119f6000] OpCode 0x0C03 (Reset) from: kernel_task (0) Synchronous status: 0x00 (kIOReturnSuccess) state: 2 (BUSY) timeout: 10000] Bluetooth warning: An HCI Req timeout occurred.
</paste>


Side question: do I have to remove old multibeast settings or does just re-running it overwrite the previous settings? Is there a definitive guide on multibeast and how it works or is that just kind of a wild wild west application? There are lots of people that specify settings for one specific MB, but I can't find a guide that explains what each does and where it sets the values on the filesystem.

Thanks for the help! I am new to building a Mac, but very experienced with BASH and Linux systems, so I will understand some things and may get confused on the Mac-specific explanations.

New MultiBeast Settings
MultiBeast Configuration - 2014-12-14 12:07:33-----------------------------------------------------------------Quick Start > DSDT Free
Drivers > Audio > Realtek ALCxxx > ALC892Drivers > Disk > 3rd Party SATA
Drivers > Disk > TRIM Enabler > 10.10.x TRIM Patch
Drivers > Misc > FakeSMC v6.11.1328
Drivers > Misc > USB 3.0 - Universal
Drivers > Misc > VoodooTSCSync > VoodooTSCSync 4 CoreDrivers > Network > Atheros > AtherosL1cEthernet 1.2.3Drivers > Network > Intel > AppleIntelE1000e v3.0.4.1aBootloaders > Chimera v4.0.1
Customize > Boot Options > 1080p Display ModeCustomize > Boot Options > Basic Boot OptionsCustomize > Boot Options > Generate CPU StatesCustomize > Boot Options > Hibernate Mode - DesktopCustomize > Boot Options > Kext Dev Mode
Customize > System Definitions > Mac Pro > Mac Pro 3,1Customize > Themes > tonymacx86 Black

 

[NapalmCandy]

I had a similar problem, I reinstall Yosemite (because I was unable to boot again with any flag) and then I removed from org.chameleon.boot.plist the lines
<key>kernel</key>
<string>mach_kernel</string>

also I add the lines

<key>UseKernel</key>
<string>No</string>.

Now I boot up normally. I read on some forum that Yosemite don't use mach_kernel again and this lines it is a bug from multibeast

 

[MIcahTautkus]

I had a similar problem, I reinstall Yosemite (because I was unable to boot again with any flag) and then I removed from org.chameleon.boot.plist the lines
<key>kernel</key>
<string>mach_kernel</string>

also I add the lines

<key>UseKernel</key>
<string>No</string>.

Now I boot up normally. I read on some forum that Yosemite don't use mach_kernel again and this lines it is a bug from multibeast

Would that fix a "Still waiting for root device" error?

And mgelax, I believe -f is a temporary fix, because I'm currently on my hack typing this, and have booted in with -f, but i don't have graphics acceleration or audio....

 

[AGuyWhoIsBored]

Would that fix a "Still waiting for root device" error?

And mgelax, I believe -f is a temporary fix, because I'm currently on my hack typing this, and have booted in with -f, but i don't have graphics acceleration or audio....

Using / Not using kernel cache shouldn't affect / solve a "Still waiting for root device" error, although it may, due to some of the weird success stories out there...

-f basically means no kernel cache, that the kernel has to load all of the kexts manually instead of loading a cache that has all of them pre-built, resulting in slower boot times.

Graphics acceleration and audio shouldn't be affected by kernel cache, although sometimes it is...In that case rebuild your kext / kernel cache and see if it solves it.

 

[MIcahTautkus]

Using / Not using kernel cache shouldn't affect / solve a "Still waiting for root device" error, although it may, due to some of the weird success stories out there...

-f basically means no kernel cache, that the kernel has to load all of the kexts manually instead of loading a cache that has all of them pre-built, resulting in slower boot times.

Graphics acceleration and audio shouldn't be affected by kernel cache, although sometimes it is...In that case rebuild your kext / kernel cache and see if it solves it.

Oh cool?! How do I rebuilt it?

 

[AGuyWhoIsBored]

Oh cool?! How do I rebuilt it?

Download something like kext wizard and simply tick "Rebuild Cache" or "Rebuild Kext / Kernel Caches"

There's also a terminal command you can execute, but it's a little more tricky...