Jump to content

Kexts are being processed on every boot


KariNeko
 Share

42 posts in this topic

Recommended Posts

Hi, I'm trying out Lion DP 4 with latest updates on my Asus P6T Deluxe V2, i7 920, GTX 260 Hackintosh.

The bootloader I used is Chameleon_2.0_RC5_r1020.pkg

My only kexts in /Extra/Extensions is fakesmc.kext for now.

Obviously I have my DSDT.aml in /Extra.

Tried latest versions of Kext Utility and Kext Wizard.

 

I'm having a slow boot because the Kexts are being processed on every boot, and it takes quite some time, when it finishes then the normal boot take place. It happens on every boot. Like a when a mkext is missing.

 

If I look at /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache and /var/db/BootCache.data boot files always have a modification date from the actual boot time, is this normal?

 

Any idea of what's happening?

 

Thanks in advance,

Karina

Link to comment
Share on other sites

I was running into the same problem with DP4, and I found a post "somewhere" on some other forum. The poster was Oldnapalm. Here's the command that worked for me:

 

sudo kextcache -v 1 -a i386 -a x86_64 -m /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext /System/Library/Extensions

 

It creates kextcache and the mkext for /S/L/E.

Hope it works for you.

Link to comment
Share on other sites

Hi guys, thanks for the help. :)

 

It's working now with that solution!!!, now I'm confused, wasn't the mkext supposed to be created with Kext Utility and Kext Wizard? like in old times. :huh:

Link to comment
Share on other sites

I use the UseKernelCache=Yes on my com.apple.boot.plist and it works okay.

 

Yes, but when you use UseKernelCache how are your /E/E being processed? or did you copy them to /S/L/E ?

 

----

 

Also does anyone know an answer to my question about Kext Utility and Kext Wizard not creating the corresponding mkext that the kextload command created?

 

 

Karina

  • Like 1
Link to comment
Share on other sites

KariNeko-

Also does anyone know an answer to my question about Kext Utility and Kext Wizard not creating the corresponding mkext that the kextload command created?

 

You would need to look at the source code for Kext Utility and Kext Wizard to see what's going on. Kext Wizard does create an mkext for /E/E, but not for /S/L/E. Lion does not by default create/use an mkext.

 

helob-

Depending on which Chameleon and or Lion install method you used, some commands work for one and not others at the prompt before boot.

 

One place to begin seeing what's going or "what's new" in Lion vs Snow is to read:

 

man kextcache

Link to comment
Share on other sites

Thanks jfMac, this solved my slow boot !!

 

Kari

Link to comment
Share on other sites

I'am on Lion DP4 11A494a

 

built the kext.cache as mentioned before using

 

sudo kextcache -v 1 -a i386 -a x86_64 -m /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext /System/Library/Extensions

 

 

But I had to move prior all non-OSX kext to /E/E.

 

Because of kextbuild complaints like "kext xxx is not authentic..bla bla"

 

i.E. RTL81xxx.kext and PXHCD.kext (for Renesas USB3)

 

No need for editing apple.com.Boot.plist.

Link to comment
Share on other sites

Here's some info on using kernelcache...

 

It works well, but the down side is that all the kexts you want to use have to be in /S/L/E. So for me, i've got:

 

- AppleHDA.kext (from 10.6.2)

- RealtekRTL81xx.kext

- ALC8xxHDA.kext

- FakeSMC.kext

- JMicron36xSATA.kext

 

These kexts need to have the root:wheel ownership, and 644 permissions.

 

In your com.apple.boot.plist file, put in the following:

 

<key>UseKernelCache</key>

<string>Yes</string>

 

Once that's done - simply delete /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache and reboot your machine. It'll rebuild the kernelcache file and the bootloader will use it upon startup.

 

The upside to using this method is that the kernelcache file is rebuilt when new kexts are installed. When using an mkext file, you have to keep it up to date yourself.

 

Of course - using this method will not touch your /E/E or /EFI/E/E kexts. If you want these to be processed as a once off - just boot with the -f option and it will ignore all caches.

 

Just thought i'd share

Link to comment
Share on other sites

Hi, thanks for the information, so for now we have two options:

 

1) Use old kextcache (mkext) method, and have to manually ran kextcache -v 1 blabla to update the cache file on each extensions change. com.apple.boot.plist does not require modification.

 

or

 

2) Use new kernelcache method, placing extensions from /E/E in /S/L/E and Lion will rebuild the cache every time something changes in /S/L/E. com.apple.boot.plist modified to UseKernelCache=Yes

Link to comment
Share on other sites

Hi,

I had the kext processing on boot problem as well. Running "sudo kextcache -v 1 -a i386 -a x86_64 -m /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext /System/Library/Extensions" fixed it for me. But, after doing this I installed a kext to make my sound work. Rebooting after installing my sound driver made it process the kext files again, which was somewhat understandable... But it does it on every boot now. Re-running the above command fixed it, but then my sound doesn't work. Can anyone point me in the right direction? At this point I can either live with no sound and fast boots, or sound with slow boots. Not a very good choice to have to make. :P

Link to comment
Share on other sites

i had the exact same problem using the mkext file.

 

switching to the UseKernelCache option fixed this for me.

 

Thanks. I tried following your directions above, but after doing so it wouldn't boot. It hangs with the error: "ACPI_SMC_PlatformPlugin::registerLPCDriver - failed to locate SMC driver"

 

If I reboot with -x, I can remove the flag from the boot plist file, reboot again (and wait 5 minutes while it does so), it successfully boots.

 

I'm a bit of a noobie with this stuff, I'm afraid. Anyone have any suggestions?

 

EDIT: Fixed it! I had to put the .kext files that were in /E/E to /S/L/E, then run the command that creates the mkext. Seems to be working fine now. :P

Link to comment
Share on other sites

I was running into the same problem with DP4, and I found a post "somewhere" on some other forum. The poster was Oldnapalm. Here's the command that worked for me:

 

sudo kextcache -v 1 -a i386 -a x86_64 -m /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext /System/Library/Extensions

 

It creates kextcache and the mkext for /S/L/E.

Hope it works for you.

 

This worked for me as well in speeding up my boot. :(

I also added the -z flag.

Link to comment
Share on other sites

  • 2 weeks later...

Hi

 

I'm not really into it all in depth this osx86 stuff. I can follow a guide and figure simple things out but all the codes and command lines are jibberish to me. I am however the kind of person that when possible I prefer to understand the reasons why someone does what it does and why the fix fixes it. So any explanations will be welcomed.

 

I too am having the long boot time problem. Can someone explain what is causing this?

 

In my boot.plist file there was the -v flag by default. When I removed this - none of the pretty text appeared telling me it was loading ever kext - but it still took ages to boot - So i guess it was loading all the files.

 

I understand that one of the solutions here involves moving kext files from /E/E to /S/L/E

 

I was under the impression that putting files in this folder would make it harder to update in future. I thought the beauty of /Extra was it was a folder that would never be touched by any updates and therefore, if you leave the rest of the install alone, theoretically you should be able to update with Software Update without issue?.

 

Is putting files in /S/L/E not going back in time and causing more problems down the road?

 

Why is this happening on CHameleon RC5 and didn't happen on RC2?

 

If someone could post a short guide explaining the best and most future proof way of getting around this long boot up time, that would be greatly appreciated.

 

Thanks.

Link to comment
Share on other sites

zip (right-click, compress) and attach kernel.log and system.log. Run Console.app and save a copy of each. Use the full editor to attach files.

 

Examining those logs will hopefully reveal what is happening during the boot process. Anything else will be pointless, timewasting guesswork.

 

Placing kexts in /S/L/E is not necessarily a step back, as long as the kernel extensions you put there are not modified Apple-provided kernel extensions you'll be fine.

 

OS X updates do not overwrite or tamper with non-Apple kernel extensions (or legacy "plist-only" type kexts) so it doesn't really matter if they are in /E/E or /S/L/E.

 

However I strongly doubt that the location of your kernel extensions has any effect on the time it takes to boot your Hackintosh.

Link to comment
Share on other sites

Hey

 

Thanks for the reply.

 

I have just copied my Lion install to my main internal hard drive - I am now solely using Lion.

 

The difference in bootup speed between an internal SATA drive and the external USB drive has improved things a lot.

 

Basically what happens now is - When it boots it does show all the kexts loading - but obviously loads them a lot faster off the internal drive. Is it normal for it list all the kexts if you're not using the -f flag?

 

-v flag is enabled in my bootplist file btw.

 

log files attached. thanks

Archive.zip

Link to comment
Share on other sites

When it boots it does show all the kexts loading - but obviously loads them a lot faster off the internal drive. Is it normal for it list all the kexts if you're not using the -f flag?

 

No. I don't know how this works in Lion because I have not paid any attention, but if its doing that on normal boot it sounds like it is not creating the kernel extensions cache for some reason. You may have to build one manually. I know this involves typing one command in Terminal but I can't be specific, search.

 

I don't know about Lion but it's probably like Snow Leopard where booting with -v causes fsck to run a disk check, which slows down the boot process a little bit, but generally not enough to be annoying. Besides, running fsck once in a while is not a bad idea.

 

But as you can clearly see, your boot process is hanging at "DSMOS has arrived". That message has to do with Apple's AES encryption and why everybody must use fakesmc.kext.

 

Look at the timestamps at the following events, five minutes pass here, then another nine minutes.

Jul 14 15:17:18 localhost kernel[0]: DSMOS has arrived
Jul 14 15:17:23 localhost kernel[0]: com_lnx2mac_RealtekRTL81xx: Ethernet address 00:1f:d0:a3:0a:a0
Jul 14 15:17:23 localhost kernel[0]: IOUserEthernetController: Ethernet address 00:19:0e:03:7e:1b
Jul 14 15:17:32 localhost kernel[0]: NTFS driver 3.8 [Flags: R/Wo

 

Grab the latest fakesmc build + plugins from one of my posts in the 10.6.8 release thread at the news sub forum - make sure to not install fakesmc plugins that you don't need. This version will work from /Extra/Extensions. Try it and see if anything improves. Don't install any plugins at first, only fakesmc.kext itself.

 

If this is not a fakesmc/decryption issue, then it's probably related to your Realtek Ethernet. Try disabling your ethernet in your BIOS, this will cause the driver not to load and you will notice immediately if your issue is related to your ethernet hardware/configuration/driver because it will not take 15 minutes to boot.

 

Also try unplugging your NTFS drives and plug in your OS X drive to SATA port 0. See if it makes any difference. Also the logs say your system partition is low on disk space, you should fix that.

Link to comment
Share on other sites

Hi Gringo.

 

Thank you for that info. I will give the fakesmc update a go. I mean the boot up time is not super bad right now I guess. Just seems longer than it did in Snow Leopard.

 

I'll give the tips you just gave a go. Thanks again.

 

Interesting about the disk space. My system partition is a 160gb drive and has 140gb left?

Link to comment
Share on other sites

 Share

×
×
  • Create New...