Akshunhiro Posted June 17, 2010 Share Posted June 17, 2010 OK, couldn't find any answer on my previous posts so thought I'd create my own thread so hopefully someone can tell me why this is happening. I haven't come across this before and I have managed to work around it but I want to understand why this is happening. So my setup has been working flawlessly since 10.6.2. 10.6.3 caused me to lose sleep/shutdown/restart ability but no biggie, just hold down the power button for a few seconds to shut the system down completely but now since 10.6.4 I have a new niggle that I'd like to sort out. I recently setup a Software Raid0 with Chameleon as my TB was about to fill up and I wasn't using Windows 7 anymore so wiped my other TB and striped them. All was well and good, the Chameleon manual explains how to set it up with Software Raid which essentially means duplicating the EFI and OS X Boot partition with Chameleons boot files. Now these Partitions are IDENTICAL. They both have /EFI/Extra/Extensions and I also use DSDT.aml (did this a while ago which fixed sound) and I also have a SMBIOS.plist to inject correct model number etc. So, the idea is I can boot from either drive at POST and it will load Snow Leopard and, it did. After installing the update yesterday, I noticed I was still on the old kernel (10.3) so I rebooted with -v to see what was loading and found alot of 'refusing new kext' errors and worked out it was still loading the old files. I had a play with it for a while but couldn't get anywhere so suddenly thought I'd try booting through my other drive and wallah, it loaded the new kernel and kexts. Why would this have made a difference? Both drives partitions are identical and have the same files, same boot information for Chameleon. I instantly thought it HAD to be Chameleon but upon loading Snow Leopard again, I copied over the files from the EFI partition to the drive I thought was causing the problem but it was still the same. Here is the full error text. This happens for alot of kexts. Refusing new kext com.apple.kernel.mach, v7.9.9: a loaded copy with a different executable UUID is already present. Refusing new kext com.apple.kpi.mach, v10.4: already have loaded v10.3 Seems to me it has something to do with UUID but I'm using the correct method as per Chameleon which involves adding "rd=uuid boot-uuid=YOUR UUID" to kernel flags which is sourced from the final drive info under disk utility. I have com.apple.Boot.plist on both partitions under /EFI/Extra so it should be working fine with either drive but only one drive is giving me this problem for some reason. I've also noticed I can't seem to boot into 32 bit mode. It just sort of stalls before loading the loginwindow. I haven't been too patient and waited it out for a huge amount of time though but not sure what's going on with that. I've only ever used 64 bit mode as it boots to that by default. Good news is though, My system is still functioning as it should and had no drama's once booted into the updated system. Didn't even lose audio (probably thanks to DSDT) and GFX is working well. Update 1: OK, just did a couple of restarts and noticed that each drive is loading a different kernel. When it loads 10.3, it won't load the 10.4 kexts so maybe this is Apple's fault as they haven't set it up correctly to copy the new kernel to each partition? I think it goes in /Volumes/Boot\OS X. Is that correct, so it should just be a matter of copying the new kernel from one drive to the other? Update 2: Well, just copied over the kernel and it was indeed the older kernel on the other drive but I'm still getting the 'refusing new kext' errors... Link to comment Share on other sites More sharing options...
Akshunhiro Posted June 17, 2010 Author Share Posted June 17, 2010 Anyone? Link to comment Share on other sites More sharing options...
Akshunhiro Posted June 18, 2010 Author Share Posted June 18, 2010 ¿ Link to comment Share on other sites More sharing options...
Akshunhiro Posted June 22, 2010 Author Share Posted June 22, 2010 Link to comment Share on other sites More sharing options...
ntsmkfob Posted June 22, 2010 Share Posted June 22, 2010 Have you looked in /var/log/update.log to see if there were any errors during the update? Many of the new kexts will be tied to the new kernel, so can't be loaded unless the new kernel is loaded. Try doing a few things like repair permissions, clear all caches to force rebuilds. Good luck. Mine completed with : Jun 15 22:49:35 MacSL /System/Library/CoreServices/Software Update.app/Contents/MacOS/Software Update[266]: Installed "Mac OS X Update" (10.6.4) Jun 15 22:49:35 MacSL /System/Library/CoreServices/Software Update.app/Contents/MacOS/Software Update[266]: PackageKit: ----- End install ----- Jun 15 22:58:11 MacSL Software Update[186]: JS: 10.6.4 Jun 15 22:58:11 MacSL Software Update[186]: JS: 10.6.4 Jun 15 22:58:12: --- last message repeated 1 time --- Jun 15 22:58:12 MacSL Software Update[186]: JS: Firmware is up to date. Jun 15 22:58:12: --- last message repeated 3 times --- Jun 15 22:58:12 MacSL Software Update[186]: JS: 10.6.4 Jun 15 22:58:13 MacSL Software Update[186]: JS: model = MacPro3,1 Jun 15 22:58:13 MacSL Software Update[186]: JS: 10.6.4 Jun 21 00:47:51 MacSL Software Update[1070]: JS: 10.6.4 Jun 21 00:47:52 MacSL Software Update[1070]: JS: 10.6.4 Link to comment Share on other sites More sharing options...
ToBeMac Posted June 22, 2010 Share Posted June 22, 2010 I got the same problem today after updating to 10.6.4, kernel updated ok to 10.4 but i noticed those "Refusing new kext" at boot. My SMBios and boot.plist both have the UUID injected properly already. What i did is that i added PlatformUUID.kext to E/E and those messages are gone! Hope it helps those with the same problem, and the experts to figure out the actual reasons behind what happened. GoodLuck. Link to comment Share on other sites More sharing options...
Recommended Posts