myFix 1.2

This version is now deprecated, consult the downloads page for a link to the latest version.

This release is a bugfix for users who want to run myfix on legacy intel and OS X 10.5 systems that can only run i386 code. I sometimes forget that some people use i386 only kernels, such as legacy intel kernels used for first generation atom systems or core duo’s. Thus in my haste to get myFix released I compiled it as an x86_64 binary, which will run fine for anyone on a Snow Leopard or Lion vanilla kernel, but people on Leopard or legacy intel systems will get a “Bad CPU type in executable” error when they try to launch myFix. Additionally I noticed some bugs in my /Extra/Extensions.mkext generation for users running myFix under OS X 10.5 “Leopard” so I fixed those too.

Please make sure to review the release notes for myFix 1.1 and 1.0 for a complete explanation of features.

A complete list of the changes from myFix 1.1 are as follows:

  • -Compiled as i386 binary rather than x86_64 binary
  • -Corrected some syntax errors for users running myFix under OS X 10.5 “Leopard”
  • -Added running kernel version and arch to output logs to help with debugging in future bug report submissions

myFix 1.1

This version is now deprecated, consult the downloads page for a link to the latest version.

This release adds a function which resolves a common issue that people have faced in the past… SleepEnabler problems and SleepEnabler related kernel panics after running OS X Software Updates.

When myFix is run it will test to see if /Extra/SleepEnabler.kext exists – if it does it will automatically define the correct pmVersion in your /Extra/ or /Extra/org.chameleon.Boot.plist (org.chameleon.Boot.plist is the new location for this boot configuration file on all new builds of chameleon). Additionally if the target is the root device (the device your OS is currently running on) it will automatically configure the flags that you would previously have to open System Preferences > Energy Saver and check the boxes for manually (which previously, if left unchecked, would result in a reboot on wake from sleep).

This function is compatible with most xnu-sleep-enabler builds. The obvious advantage to including this feature in myFix is that you will no longer have to remove or replace SleepEnabler.kext when updating to a new version of OS X. You can simply run myFix before rebooting, after an update, or from your USB Installer.

This function currently supports 10.6.0-10.6.8 and 10.7.0 pmVersions, if you are running a different version of OS X than this it will set pmVersion=0 to disable SleepEnabler completely. I will release updates to myFix that will add support for newer versions of OS X as they become available.

Please make sure to review the full release notes for myFix here.

A complete list of the changes from myFix 1.0 are as follows:

  • -Added fix SleepEnabler function
  • -Added check for Boot.plist
  • -Cleaned up output log slightly

myFix 1.0 (pfix 4.0)

This version is now deprecated, consult the downloads page for a link to the latest version.

This is a complete rewrite of the pfix utility and the beginning of something more. pfix 3.1 was a solid performer, I received no bug reports, but truth is it was a little messy. I had seen many issues with the way kextd/kextcache functions in Snow Leopard and users rebooting prior to the system prelinked kernel caches being completely built. So to ensure fail proof operation I coded it to build all of the caches manually, not just the Extensions.mkext. This wasn’t the ideal way to do things, but it required minimal time on my part to simply fix bugs in 3.0/2.x rather than rewrite it in a new format.

That said, with OS X 10.7 about to be officially released to the wild it was time for a rewrite, not only to clean up the old code but to expand functionality to the new version of OS X.

One of the biggest complaints I received about pfix 3.1 was that it took so long to execute… Why wait so long when you can just chown/chmod and then touch /System/Library/Extensions? Well the reason is simple really – it is not the fault of pfix – it is the fault of Snow Leopard’s kextcache. It takes a ridiculously long time to rebuild the system prelinked kernel caches if there is a problem with them or they don’t exist after having been deleted. If you were to simply touch /System/Library/Extensions and then reboot imediately, kextcache would not be finished and it will take you up to 15 minutes to boot your system, if it boots at all. Good news is, Lion doesn’t have this problem.

So what have I changed? Well not only will myFix detect the OS version it is running on, but it also detects the OS version of the target and adjusts the functions and syntax for mkext creation accordingly. I have extended support for it to run on Leopard and Lion. I have dropped support for running it on Tiger. I have also added full support for Leopard and Lion as target’s. So now you can use myFix from Leopard, Snow Leopard, and Lion to repair any Leopard, Snow Leopard, or Lion volumes.

Additionally instead of running all the commands manually I let kextd/kextcache do it’s job – after the initial permission repair (and optional diskutil repairPermissions) it will simply touch /System/Library/Extensions – and then it will WAIT until kextcache is finished. In some cases it will still take a while for kextcache to finish, but by waiting it will let you, the user, know when it’s safe to reboot so that you do not reboot your system prematurely and have a problem. In most cases however it will actually finish quite quickly. By adding the optional flag to skip the diskutil repairPermissions step it will go even faster, however, I do suggest you let diskutil repairPermissions run as chmod 0755 is *NOT* the correct permissions for many of the files in /System/Library/Extensions.

What did I mean by “and the beginning of something more”?

myFix will be more than simply a Permissions & Caches utility. In the future I will be adding additional functions to myFix, backup/restore functions, kernelcache support via bundled SLE extension, chameleon repair/updating, and more are all on the todo list…. Stay tuned…

So without further adieu let me present you with myFix 1.0

Basic Usage: myfix [option]
Example Usage: myfix -v 1 -t /

Option       GNU long option       Meaning
-h           –help                Show this message
-s           –skipsystem          Don’t repair /system/library/extensions
-d           –skipdiskutil        Don’t repair permissions with diskutil
-v <level>   –verbose <level>     Set kextcache output’s verbosity level
-t <path>    –target <path>       Path to target partition to run myfix on

A complete list of the changes to the pfix functions from pfix v3.1 are as follows:

  • -Completely re-written from scratch with much cleaner syntax and improved functionality
  • -Target OS version detection
  • -Added skip diskutil repairPermissions flag
  • -Added support for OS X 10.5 Leopard and OS X 10.7 Lion targets
  • -Improved support for OS X 10.6 Snow Leopard
  • -Removed support for OS x 10.4 completely

Moving Forward

In preparation of the official release of Lion I’ve freshened things up a bit around here, out with the Snow Leopard style, in with Lion! Hope you all like the new template, I didn’t spend much time on it but I wanted to “set the mood” for things to come.

Also, here is a teaser for you all – a couple screenshots from a little test I did last night – installed Lion GM on my system using a very rudimentary myHack 2.0 BETA and my existing “Extra” which consists of only FakeSMC.kext, LegacyHDA.kext, and a dsdt. Everything I have tested so far is fully functional.

Yes I have a hybrid ATI/NVidia dual graphics Setup – a small example of what taking some time to create a proper dsdt for your system has to offer.

More to come soon!

Hello world!

It’s been a very long time since I’ve really taken the time to update this site or the information on it. I’d like to just take a moment to answer a couple FAQ’s I’ve been receiving on IRC.

Where have I been?

I am very busy working on a new SaaS project. I can’t say much about it for now as my business partner and I are keeping it ‘under wraps’ until we go live with the site. It leaves me with very little time to work on side projects such at this one. I do still help when I have a little free time, mostly on IRC or by answering comments here.

Does myHack still work with 10.6.6/10.6.7/10.6.8?

Provided you grasp the basics and have followed the instructions, yes! I haven’t been updating the guide with additional update details primarily because the same general rules apply, there may be a few issues that crop up for someone here or there, but if you follow the existing update guidelines you should be able to fix anything that may go wrong quickly and easily. I myself took the time to create a good dsdt for my system so I simply run software update and have never had a single problem. The only kext modifications I have made in recent months to my own system was a TRIM hack to support TRIM on my OCZ Vertex 2 and adding the 10.6.7 ATI kext’s from the MBP update to support my new HD6870 graphics card.

Do you have any plans for the future of myHack?

Yes, when I can free up some time I may start by releasing a “Final” 10.6.x revision of myHack – I will likely drop most of the embedded kexts, particularly SleepEnabler.kext to avoid potential problems and to further encourage users to learn how to tune their kexts and dsdt’s properly. I also plan to update pfix to ensure compatibility with OS X 10.7.x “Lion”. I may or may not release a Lion version of myHack, if I do I will be getting away from the apple package maker and focusing on a more adaptable and optimized application written from scratch. I have also pondered the idea of making a live linux distro that was compatible with a terminal-only version of myHack to enable people to prepare a myHack USB installer without access to a system running OS X for about two years now so that may be in the cards for a future release.

Truly the response to this project has exceeded my expectations, I never expected more than 200,000 people to be using myHack and every time I hear of someone’s gratitude and elation at their successful retail install it makes me proud to have given something back to the community that has given so much to me over all these years. myHack has already achieved all that I had hoped it would – it inspired the community to turn away from “Distro’s” and to focus on installation tools that make retail OS X installation quick and painless for the average user with supported hardware.

To all those who have donated to the project, thank you! Though there were very few of you, it did help to cover the costs of hosting, at least partially, for these years and I am quite grateful for that.

To the people like tonymac who stole my code and others, took credit and then did this for profit, I hope your karma catches up with you. Re-bundling code and extensions in such a way as to dumb it down substantially and then adding insult to injury by not explaining how/why something works, always taking the easy way out, etc – perpetuates ignorance and reliance on amateur hacks. Your tools are no better than the distro’s of old that we sought to overcome. I hope that anyone who is unfortunate enough to have been mislead by you will find their way to a site that will better educate them and help them to learn how to do things properly so they will not have to suffer long for your mistakes.