Permissions & KEXT Caches
I have written the following utility which simplifies and automates the process of repairing permissions and rebuilding kext caches. It will test for and prevent a number of common errors that may arise if the manual method (Which I have discussed further below) is used incorrectly. I personally suggest that you use this utility (instead of doing this manually) to reduce or eliminate the potential for user error & to save time.
Please consult the downloads page for a link to the latest version of pfix.
Further documentation and how to do this manually:
One of the most common problems with Snow Leopard on PC’s is incorrect permissions and improperly built kext caches. While it may not always be necessary it is a good idea to correct permissions and rebuild kext caches anytime you modify your extensions or install software which adds new kexts to your system.
To do this manually open a terminal and enter the following commands to repair the permissions on your “/Extra” directory:
$ sudo chown -R 0:0 /Extra
$ sudo chmod -R 755 /Extra
You may also need to repair the permissions on your “/System/Library/Extensions” directory:
$ sudo chown -R 0:0 /System/Library/Extensions
$ sudo chmod -R 755 /System/Library/Extensions
Now build the Extensions.mkext for /Extra/Extensions in /Extra with the following command.
$ sudo kextcache -v 1 -a i386 -a x86_64 -m /Extra/Extensions.mkext /Extra/Extensions
You may also need to rebuild the Extensions.mkext for the “/System/Library/Extensions” directory:
$ sudo kextcache -v 1 -a i386 -a x86_64 -m /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext /System/Library/Extensions
Then you may reboot your system. Please note that the above examples are assuming you want to repair permissions on your root volume ( / ) if you are repairing the permissions on another volume in your system make sure to adjust the path accordingly.
IMPORTANT NOTE: If running these commands from Tiger it is necessary to delete all kext caches instead of rebuilding them. The kextcache utility on Tiger is unable to build Snow Leopard compatible kext caches and as a result any Snow Leopard system which has these incompatible kext caches will fail to boot. The pfix utility (v2.0) detects the OS X version and will apply these changes automatically.
NOTE: I was originally using the find command to set directories to 755 and files to 644 instead of just chmod -R 755. While that method actually sets the correct permissions for your extensions according to the “OS X Standards” there were some failures reported due to a few kexts containing non-standard binaries that required executable privileges. You will find that the majority of vanilla kexts inside /S/L/E have their directories set to 755 and the files inside of them are 644. Thus this is the ‘proper’ method to use when correcting permissions for most of them. The few that have executable binaries inside of them however, make it impractical to achieve perfection. While this is not absolutely required for them to ‘work’ it is a good practice to learn how to handle unix permissions properly and to not have files set to executable (755) unless absolutely required for their operation.
With that said I am now advising everyone to use the chmod -R 755 method I have posted above and to use diskutil to repair the permissions on your snow leopard installation once you get it up and running. More information can be found on the pfix2.0 release page linked above and in the comments on this page.
Tags: Hackint0sh, OS X, Snow Leopard, Troubleshooting
This entry was posted on Saturday, September 19th, 2009 at 15:37 by Conti and is filed under Working with OS X, myHack Utilities. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Thanks a lot Conti for the response :) now my tiny brain when it comes to OSX86 became a bit bigger haha.
BTW im subscribe to your blog via Mail RSS so keep the OSX86 related news and fixes coming.
re: #2 YES, that’s what i did because that’s what i saw in a few tutorials floating around (including projectsnow) and it seem to work right of the bat on first boot w/o kernel panic on 32/64. It generated a 30.5MB extensions.mkext in /Extra. Thanks for the very clear explanation :)
I think I understand what you are asking in #2 better now. I believe what you did before was generate an mkext of everything in /S/L/E & E and put that all in /E – which is not nessisary. The mkext in /E should only contain the cached contents of /Extra/CustomExtensions. The kextcache for /S/L/E belongs in /System/Library/Caches as listed in my example above.
Regarding your question with disk utility I took a deeper look into this. There are roughly 80 errors (according to disk utility) with the syntax I have used. But there are roughly 2200 errors with the -R 755 syntax. I was just going to say to ignore disk utility because it is often inaccurate and everything I know about kernel extensions tells me that the syntax I have used is accurate and that 755 is the wrong syntax to use for files inside of kexts but I am a bit of a perfectionist so I dug into it further after reading your comment.
After digging into this a bit further myself I asked one of our resident experts in #snowleopard (Thanks Galaxy) just to be sure. He reassured me that indeed the kernel wants to see the files inside the kexts as 644 and to ignore the permissions verification script inside disk utility because it often bitches about things that are not really a problem. It uses a permissions database and that database is not always entirely accurate.
Thanks conti, it’s now clear except for #2..
that’s working, im using that method before i stumbled upon your blog :) , it will create a 30MB+ extensions mkext in /Extra
actually my question should be if there’s no difference between those 2 in /Extra (30mb mkext and 11kb+ mkext)?
also another question, tried using your automatic and manual script but after the mkext created, rebooted and tried running disk utility but i got lot’s of permission repaired mostly in /S/L/E.
I’d be happy to help to clarify for you :)
1: It’s actually a chown command that is assigning file ownership to a user and group (in this case root user, wheel group) not the kextcache command… But to answer your question regarding the difference between 0:0 and root:wheel – there is none. If you take a look at the chown man page
“The owner may be either a numeric user ID or a user name. If a user name is also a numeric user ID, the operand is used as a user name. The group may be either a numeric group ID or a group name. If a group name is also a numeric group ID, the operand is used as a group name.”
In my example I have used the numeric user ID and numeric group ID rather than the user name and group name for two reasons.
1) It is quicker to type.
2) I believe it is harder to accidentally type incorrectly.
2: I’m not quite sure I completely understand what you did here (that syntax you have pasted wouldn’t work right at all) but I believe you are asking why the Extensions.mkext for /Extra is so much smaller than the one for /System/Library/Extensions?
If that is what you are wondering the answer is simple. There should only be a few Extensions in /Extra/CustomExtensions but there are many in /System/Library/Extensions. Therefore the cache for /Extra/CustomExtesnsions is going to be much smaller, because there is much less information to add to it.
3: If you take a look at the kextcache man page you will see what these flags mean but I will list them here as well:
-v is for -verbose, -v 1 is the lowest level of verbosity (other than silent)
“1 (or none) Print basic information about program operation.”
-a is for -arch, -a i386 is i38 arch, -a x86_64 arch, this is required because on older operating systems like leopard or tiger will actually build either only i386 or i386 & ppc but fail to include the x86_64 parts of the extensions in the mkext (cache) file. NOTE: In snow leopard it will build i386+x86_64 by default so this would not be absolutely required unless running the commands on an earlier version of OS X.
Hope that clears things up for you, if you have any additional questions don’t hesitate to ask.
thanks for the script, works well here.
some clarification please, hope you can can reply coz im confuse looking at different guide:
1: im seeing kextcache commands using 0:0 and root:wheel? im seeing you use 0:0 but what’s the difference?
2: also tried creating an mkext using this command ” kextcache -v 1 -m /Volumes/NAME/Extra/Extensions.mkext /Volumes/NAME/Extra/Extensions /Volumes/NAME/System/Library/Extensions ” so the mkext created was about 30MB place in extra but on your’s it’s just a few KB?
3: what does the letter means? -a 1 t etc..
Thank’s a lot for the reply in advance. my system is working in either your script or the ones posted above but i really wanna understand what does it mean that’s all.. :)
Any similarities to your old script were purely co-incidental.
Though I had used a different syntax for the kextcache command in my original script and changed to this when I saw yours (I’m not sure the syntax I used before would have worked outside of snow leopard) & I should let everyone know that Apocolipse is the one who suggested that I add the prompt for destination volume to the script rather than require the users to place the script in the root of the target volume – which was a superb idea!
Nice, though you neglected to mention where the original script you based this off of was from ;)
russo: I appreciate your feedback and I see what you are trying to suggest here…
There are a few reasons I didn’t go that route.
For one thing the code you have posted is invalid syntax and will not work…
The primary reason though is I wanted people who may not have much experience working with bash to really understand what is going on in this code. While I could have easily reduced the commands to ‘one liners’ I believe it is easier to understand the examples with the syntax I have used. If you are looking for a one line command to achieve all of this – the script I have posted is the way to go.
Really nice guide. Had a question though, i tend to stick away from find on *nix because its different on every system. Is the type flag common to linux too?
Alternatively you could just do something like (this should work with any bash):
find | while read i; do if [ -d $i ]; then chmod 755 $i; else chmod 644 $i; fi; done
(Haven’t tested that code tho ;) just came to mind…)
D.
Gr8! J0b!