This problem started happening right after running EasyBeast. I didn't install ANY other kexts or make any other modifications. It won't boot all the way up, but if I type -v at the Chameleon screen, I get to see this:
kxld[com.apple.driver.AppleRTC]: The Mach-0 file is malformed: Invalid magic number: 0xbebafeca
Can't load kext com.apple.driver.AppleRTC - link failed.
Failed to load executable for kext com.apple.driver.AppleRTC (error 0xdc008016)
I've already tried copying the vanilla AppleRTC.kext file from the installation USB over to the hard drive, thinking maybe the installed version got corrupted somehow. That didn't help. Is there something else that needs to be done after copying the vanilla kext into the system to make it re-scan for changed kexts?
I'm running an ASUS P8P67-M Pro board with the hacked BIOS that keeps it from having a KP during the initial install.
Well, I'm not sure why it gave me so much trouble booting before I switched to the hacked BIOS then, because UniBeast wouldn't boot from USB or CD before I flashed the BIOS with that firmware. Anywho, I'll try your suggestion to make my own DSDT and see what I can come up with. Thanks :-)
OK, I followed the instructions in the link in your sig. Applied the patch to a DSDT I extracted from my machine, then saved the aml file to my desktop, and ran MultiBeast in UserDSDT mode. Now, it's booting past the kexts, but it hangs on a white screen of death. Safe mode doesn't help either.
Yeah, I did a clean install, then followed your instructions. Booting verbose shows me the entire string of kexts being loaded with no errors, and then just as it looks like it's going to finish booting, it gives a white screen of death. I was able to get past this by booting with the GraphicsEnabler=No option, but that's obviously not ideal. Any thoughts?
I installed the nVidia driver from MultiBeast, but that doesn't seem to be doing any good.
Edit: I also have installed NVEnabler64.kext, which didn't help either.
Edit2: Ahhhhh. It seems the system was having trouble with having more than one monitor plugged in at once. I tried unplugging the secondary monitor, and now I'm not getting the white screen of death anymore. w00t! Thanks for the help! :-)
Don't know if I should start a new thread for this, but just to err on the side of caution, I'll put it here first.
I've now got the whole system working as described in the prior posts. BUT...
Now, I'm getting random kernel panics from what seems to be issues with the filesystem driver for hfs+ volumes, and how it handles (un)mounting disks that have errors in their journals.
The last error that I can find in the logs that seems to coincide with the timing of the kernel panic says "hfs_mountfs: hfs_early_journal_init failed, erroring out"
It seems to only panic when it's trying to unmount these volumes JUST before shutting down, or when I'm trying to run a Carbon Copy Clone to one of the affected drives. I've tried repairing the disk and permissions, but I'm not getting any indication that it's helping.
Edit: I looked at another system log and got the following error that appears to occur right at kernel panic:
"_CSIsWirelessP2PEnabled::copyPrimaryAirPortInterf ace failed"
This doesn't make much sense at all, since I don't have an airport interface in this machine, or even any wireless network interface, for that matter. However, the wired interface has been acting wonky for about the same amount of time as I've been getting these kernel panics. How can I scrap ALL network-related kexts in one fell swoop and see if that gets stuff to stop acting up?
Edit 2: I had the wild idea to try turning off all indexing and journaling on the affected hard drives, then I went and handicapped my RAM clock and disabled SpeedStep, just in case either of those were causing the bug. Well, SOMETHING in that worked. The system is running stable now, and transfers between the drives don't crash the system, nor does trying to reboot it (as it was doing before, likely as a result of the system attempting to unmount drives before reboot). Obviously, this isn't an ideal solution, since I need journaling and indexing, but I'm going to work my way back up now, and see what happens as I re-enable each element. Once I find the weakness, I'll post back. Thanks for hanging in there with me!
ok , so i am getting the same error as you. AppleRTC invalid magic number 0xbebaface
I am not sure what I did (if anything) to break this... but here is the strange bit:
i can boot into single user mode on my rescue USB stick and then compare two AppleRTC binaries. They DO differ. I also compare all the version info plist files and they are the SAME (which implies same build, version).
If i copy the AppleRTC from the USB stick to the HD containing the lion install everything is good. I do a diff on them after the copy and they are the SAME.
When I reboot though, I get the same error and the AppleRTC file is again DIFFERENT (in the same way) as before.
I am booting with -x ....
WTF is going on ?
User DSDT is the multibeast install and the only thing that I added was the nvidia patches and, the 1000E network driver, and the Voodoo audio.