GA-H87M-D3H + i7 4771 : booting without -f option

[superoro]

[SOLVED]GA-H87M-D3H + i7 4771 : booting without -f option

Hi All,

After finding a lot of very good threads/guides in the deeps this forum, I finally managed to install a fresh 10.8.5 using UniBeast and MultiBeast. It's working pretty well so far ... except that I have to use '-f' option to boot the system. If I does'nt, it will likely get stuck somewhere in the middle of the booting. The '-f' option has the big drawback of slowing down significantly the boot process.

Looking carefully to the boot logs, I noticed a difference between the failing boot (without -f) and the successful one (with -f) :

The failing one complains about a JMicronATA kext :

"Refusing new kext com.jmicron.JMicronATA, v1.0.2: already have prelinked v1.1.6"

I found here or there some threads speaking about this issue but not a clear fix. I get the impression that the kext cache has an earlier JMicron driver which might cause troubles, but I did not find how to get rid of it.

Any idea ?

 

[RehabMan]

Hi All,

After finding a lot of very good threads/guides in the deeps this forum, I finally managed to install a fresh 10.8.5 using UniBeast and MultiBeast. It's working pretty well so far ... except that I have to use '-f' option to boot the system. If I does'nt, it will likely get stuck somewhere in the middle of the booting. The '-f' option has the big drawback of slowing down significantly the boot process.

Looking carefully to the boot logs, I noticed a difference between the failing boot (without -f) and the successful one (with -f) :

The failing one complains about a JMicronATA kext :

"Refusing new kext com.jmicron.JMicronATA, v1.0.2: already have prelinked v1.1.6"

I found here or there some threads speaking about this issue but not a clear fix. I get the impression that the kext cache has an earlier JMicron driver which might cause troubles, but I did not find how to get rid of it.

Any idea ?

You probably have an issue building kernel cache. Run DPCIManager and rebuild cache, paying attention to any errors that result.

 

[superoro]

[SOLVED] GA-H87M-D3H + i7 4771 : booting without -f option

Problem found and fixed : with the help of DPCIManager, I found that the issue was related to VoodooHDA kext which was installed by default. For an unknown reason, VoodooHDA is not crashing when '-f' option is used while it is crashing when it isn't. I just removed this kext from S/L/E and regenerated the cache with DPCIManager and since, my boot is perfect.
I will use another driver for ACL882 sound.

Thanks for help !

 

[superoro]

I now have a fully functional hackintosh. For those who would share the same HW, here is what I did to install ML :

- Downloaded Mountain Lion 10.8.5 from app store
- Used UniBeast without any special option to create a bootable USB stick
- Configured BIOS with:
- Disabled VT-d
- Disabled Internal graphics and asked PCIe-1 to be used first (where my GTX 660 is plugged)
- Disabled unused HW : serial port, parallel port
- Booted on the stick and used the followng flags : -f GraphicsEnabler=No
- After installation : booted again on stick but asked to Chameleon to start on the freshly instaled HD instead of the stick
- Went through OS X configuration
- Once on the desktop : deleted VoodooHDA.kext from S/L/E
- Started Multibeast (previously downloaded on the stick) and used the following config :
- UserDSDT ot DSDT-Free Installation
- Without DSDT ACL8992
- ElliotForceLegacyRTC
- evOreBoot
- FakeSMC and all its plugins
- Latest Chimera (v2.2.1)
- GraphicsEnabler=No option

And that's it ! System up and running and 100% reliable boot.

 

[njcotjn]

Hi All,

After finding a lot of very good threads/guides in the deeps this forum, I finally managed to install a fresh 10.8.5 using UniBeast and MultiBeast. It's working pretty well so far ... except that I have to use '-f' option to boot the system. If I does'nt, it will likely get stuck somewhere in the middle of the booting. The '-f' option has the big drawback of slowing down significantly the boot process.

Looking carefully to the boot logs, I noticed a difference between the failing boot (without -f) and the successful one (with -f) :

The failing one complains about a JMicronATA kext :

"Refusing new kext com.jmicron.JMicronATA, v1.0.2: already have prelinked v1.1.6"

I found here or there some threads speaking about this issue but not a clear fix. I get the impression that the kext cache has an earlier JMicron driver which might cause troubles, but I did not find how to get rid of it.

Any idea ?

Please tell me the file "msbios. plist"