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.
Justin: Looks like NullCPUPowerManagement.kext is not loading properly did you ensure to correct permissions on the files in /Extra and to build a new kext cache? I suggest you run the new pfix v2.0 that I released yesterday as it will ensure that everything has been done correctly and provide you with some feedback in the form of a log file to aid in debugging these potential problems and more. In the future please use pastebin.org for pasting blocks of text for debugging purposes. Also when asking for help it is important to provide me with a summery of what hardware you are attempting to install on as there are some known issues with various hardware configurations.
When I followed your instructions for fixing the permissions in my S/L/E folder i got a kernel panic at the starting screen. Could you offer any suggestions? I can’t read all of it because of the restart message but this is most of what it says,
panic(cpu 0 caller 0xffffff7f8066320f): “i386_pmGetDeadline: NULL pointer\n”@/SourceCache/A;;leIntelCPUPowerManagement/AppleIntelCPUPowerManagement-90/pmDispatch.c:114
Debugger called:
Backtrace (CPU 0), Frame : Return Address
0xffffff800010be00 : 0xffffff8000204ae6
0xffffff800010bf00 : 0xfffffff7f8066320f
0xffffff800010bf20 : 0xffffff80002c0104
0xffffff800010bf50 : 0xffffff80002d1bc8
0xffffff800010bf80 : 0xffffff80002cb211
0xffffff800010bfd0 : 0xffffff80002dded2
0xffffff80a7fe3d80 : 0xffffff7f8067a4b9
and it continues on like this…Could you please help? I’ve been trying to get this to work for several weeks but so far I can’t figure it out. Any help would be greatly appreciated.
thanks,
Justin
pfix 2.0 is out and resolves all of these problems and adds features which add considerable functionality and prevent or correct issues that have not even been mentioned on here. Updated original post with new information and link to pfix 2.0 release page.
Cheers
Yes, I intend to actually rewrite pfix a bit fairly soon here but for now my suggested usage is to run pfix or use the manual commands from leopard and then once you have booted snow leopard go into disk utility and repair permissions, or use the diskutil repairPermissions command from the terminal.
Despite my desire to be a perfectionist and adhere to OS X standards as closely as possible it is clear that some kexts are not adhering to those very same standards so I believe my next revision of pfix and this guide will go back to the chmod -R 755 method, it does provide too many permissions to a large number of files and due to my GNU/Linux background it makes me uncomfortable due to the potential security issues that may arise from granting too many permissions to files should not have them. But I think it is better to have things that way and use disk utility to repair them than to not grant enough permissions to some files that need them which can result in failures like the one reported by Britney here.
Would it be possible to do your advised repair from leopard, then “sudo diskutil repairPermissions /” from inside snow after install.
I don’t understand these commands completely yet so I’m not sure.
The trouble with that is diskutil on leopard or tiger is unable to repair permissions on a snow leopard installation afaik… I could perform a test to ensure this is done whenever pfix is running under a 10.x kernel but it isn’t a 100% ‘foolproof’ solution.
Maybe something like sudo diskutil repairPermissions / at the end of pfix would be useful if the recommendation is to run repair permissions anyway. Then the recommendation wouldn’t even be necessary. Or maybe just running the diskutil command would replace two SYSTEM_KEXT permissions commands? Just a couple of ideas.
Britney
I was afraid something like this would eventually come up though this is the first report I have seen.
I thank you for your detailed analysis it is quite helpful. As to the future of pfix I have debated if I should try to integrate some sort of ‘blacklist’ to prevent potential failures like the one you have mentioned or even attempting to find a way to tie it into the disk utility’s permissions database somehow. So far nothing ‘critical’ has happened which prevented a system from booting or caused a kernel panic so I am inclined, at least for now, to leave things as they are and I would simply suggest that everyone should run Disk Utility after any major filesystem changes to ensure that all the permissions are as accurate as possible, just like we would on a real MAC.
There is also the possibility of including an internal md5 database for all the kexts in S/L/E so that the pfix utility only repairs permissions on files which it detects changes in – of course this option does not carry over very well with OS X software updates and thus would require frequent updates to the pfix md5 database to maintain as much accuracy as possible.
I haven’t decided where I should go from here but I am always open to suggestions.
Again thank you for your input,
-Conti
Thanks for the great tool Conti.
I understand your reasoning for using 644 on the files inside of the kexts but in some cases I believe the files really do need to be 755. One example is the S/L/E/smbfs.kext/Contents/Resources/load_smbfs. When this is set to 644 connecting to SMB shares never happens and the console says that is because permission is denied. Once I change load_smbfs to 755 I can connect to SMB shares.
I also ran Disk Utility repair permissions after pfix and found that load_smbfs is one of the 80+ errors you mentioned you saw. I also noticed that all of the other ones listed are individual files. I am thinking that some of these errors might cause an error similar to what I see with SMB.
Disk Utility’s database of permission might not be entirely accurate but it seem that it is for the SMB kext.
I am not sure if this is something you could address for pfix but I thought I would let you know what I am seeing.
Thanks,
Britney
Hey Conti !
great tool… helped me lot .. thanks for the good work… :)