Conti

The idea here is to have an /Extra on each OS partition, there are several reasons for this, independent configuration on a per OS/Partition basis for example without the use of 10.(6/7/8) subdirectories... But others I will get to in a moment. I don't think having an Extra on your OS partition should trouble anyone, although I myself used to do it the same way you are describing I have switched to having an Extra on each OS Volume (of which I have about 4 on this system alone). The issue in altering the functionality is, when you simply want to run myfix, for example - say you want to test some new extensions only on one partition, myfix is going to look in /target/Extra/Extensions for the new extensions that need merging with /target/system/library/extensions/ - while this could be done from /someothervolume/Extra - it would have to be defined each time you run it, and would not allow for testing fully independent configurations across the different OS partitions. Currently only during Extra installation does myhack acquire a custom path for an Extra directory - new functions would need to be added to myfix, and when run from single user mode - volumes outside of / aren't even available - which is probably the biggest issue. There are a couple of other things planned in the myHack 4.0 branch that would also rely on /Extra/ being available on each booted OS volume... So that makes me even more reluctant to add support for this configuration. There is probably a few creative solutions that would extend at least some support for this kind of functionality, the question is, how many users really want this functionality? And does anyone really *need* it? (aside from users running raid boot volumes and using EFI partition for loader, but that is an entirely separate matter which I have not even began to address yet and isn't high on my list of priorities)...

Glad to hear it

I sent you the new build via email, please test and let me know as soon as you can, I won't be releasing this build officially - but I will include the change in 3.2 if it works as expected. Thanks

That is odd, I downloaded the zip file you linked to, I will review it after dinner. // Edit - come to think of it, I think I know why this is failing during OS X post install - it's defining the OS Version of the target during target selection, but that code doesn't execute in OS X post install, I will fix it after dinner and post a build for you to test.

No problem. I just thought I'd mention it. I'm glad you did, as a bit of a perfectionist myself, anything that can polish things off and improve the overall experience is something I'm always interested in.

The warning is the boot sector not being able to be flushed, it is better to use the instructions I posted on the post you linked to and boot directly into the installer, run myHack from the utilities menu, and run the chameleon installation from there - this way it can unmount the targeted device and wipe the boot sector in addition to the installation of chameleon itself. Also you don't really need to run myfix from the terminal, it can be done from the myHack app - either way works though. Glad you got it sorted anyway

If you are still getting that error on OS X post install you must still have myHack 3.0 on your OS X install disk - here is a log output from myHack 3.1 using the extra directory you sent me yesterday by email: And here is the result on the myHack OS X Install Disk (Which previously had a generic extra installed thus the lspcidrv.kext and RemovedExtensions directory): As you can see this is definitely the 10.6 extensions you had in your Extra. Here is the results when I use an old one of my own Extra's for my i7 build - without any 10.x subdirectories - immediately after using yours, I haven't touched the Extra on the myHack OS X Install Disk by hand inbetween: And here is the result on the myHack OS X Install Disk: Everything merged correctly once again. Now as far as why the permissions and dates are getting a little screwy it has to do with the way I am merging things from inside the myHack bundle, if you explore myHack.app/Contents/Resources/ you'll see what is going on - there are several options in terms of how I can correct it, the first was to set all the permissions correctly inside of the bundle prior to distribution of the myHack.app - however those permissions are not always preserved correctly when users unpack and install myHack. Another is to transfer each file individually rather than merging directory trees - this is inconvenant to say the least. Another would be to preserve permissions and dates on the origin file, I have to look into it more. As it is not a critical issue but mostly cosmetic I pushed it back a little - I am going to see about doing something with that in the next release but I wanted to get 3.1 out asap.

http://myhack.sojugarden.com/2012/05/myhack-3-1/ and there you have it

This is a known issue with 3.0, it has been resolved in 3.1 (which will be released very soon, I posted a partial changelog of what was done so far, at the time I posted it, HERE). It was not the admin password it was an issue with the build of pkgutil bundled in myhack - the build was incompatible with snow leopard. All lion installers have blank screens under customize, I attempted to resolve the issue a few months ago but it is something *Apple* did - it looks like they started to write the localizations for each menu entry in OSInstall.mpkg and then just gave up half way through and set display=false on all of them. I suspect the customize installation screen on real macs is handled in the binary now - or perhaps they intend to remove it in the future. Even if I set display=true the localizations don't show up and basically all the titles and descriptions are empty and all you have is a bunch of checkboxes with no information. To resolve this fully would take weeks of defining the correct localization data and writing the missing ones by hand for every os version from 10.7 - so I've left it alone. In regards to using hacked bios, it is not something I have ever suggested or recommended (except in cases where you want to remove a whitelist), but if you are having no issues with it so far I wouldn't say it is necessary to revert it. Of course you can revert it at any time should you choose to do so. NOTE: I removed your log on purpose so as not to confuse anyone in the future. This will not be an issue with 3.1+ and it will be released within the day.

Nice post, by all means please attach them to the post, with as unreliable as 'hosting sites' have been these days I'd rather keep them some place I know they won't go dead

Several other users reported the same to me today on IRC. Though you dont have to boot with UseKernelCache=No - simply boot with "-f" (without the quotes), as stated in the release notes we've patched chameleon so that -f will ignore both the kernelcache and the kextcache instead of only the kextcache as it did in the past.

That is what I suggested to do two posts above, but I guess the 10.7.3 one didn't work out for you, glad you got it sorted though.

Is your HDD on SATA and is AHCI enabled? If not, can you enable AHCI? If not, you can try to use IOATAFamily.kext as described in the guide - it's not recommended though and certainly won't work on ML but may work on Lion (I've never tested it, but I have deployed it a few times on 10.6). If it is in AHCI mode but you still have the issue, it might be a bad HDD.

Appreciate the feedback blackosx, in regard to the /Extra/10.8/Extensions issue you mention - this isn't really ideal to use anymore - given the fact that myfix merges everything in /Extra/Extensions with /System/Library/Extensions you can simply use a different /Extra on each partition which will function independently across each partition/os version on that partition. That said I may be able to add a bit of code to detect for /Extra/10.(6/7/8)/Extensions and migrate it to /Extra/Extensions. I noticed the 'Drag to applications directory to install" text is cut off under my Snow Leopard test VM but it looks fine to me on Lion/ML - I'll see about tweaking it so that it will not get cut off though. /usr being visible after running myHack was not intentional I believe it is a side effect of installing myfix and lspci under /usr - I will see if there is a way to correct this. In case you are interested I've already began working on 3.1 thanks to some useful feedback from users - here is my running changelog of what has been done so far: Bugfix: Correct issue with myhack OS X post install patch of OSInstall.pkg when myHack OS X Install Disk is created on a Snow Leopard system Bugfix: lspcidrv.kext and RemovedExtras won't get moved to ExtraBackups when installing a new Extra Disabled the Create OS X Installer option from myHack while running on an OS X Installer Disabled Cancel buttons on myHack OS X post install dialogs If cancel button is pressed on Extra file selection dialog, return to Generic Extra/Use Your Own menu instead of exiting myHack Revised Snow Leopard installation source detection - Instead of looking in /Volumes/Mac OS X Install DVD/ all volumes mounted in /Volumes are scanned Disable kernelcache on OS X Installers Enable kernelcache on user supplied extras instead of just the generic one Removed log output for enabling ownership on devices Removed pkgutil from bundled utilities Removed strings from bundled utilities Stripped ppc arch from bundled utilities

The first error screen you posted can be resolved by running sudo chmod 0755 /usr/sbin/* but since it's an OS X installer it will be mounted read only so you would have to boot into single user mode and mount the drive read+write to do so. The second error screen is because you are using an outdated version of SleepEnabler.kext for your system version - remove SleepEnabler.kext from /Extra/Extensions/ (or anywhere else it may be, which it shouldn't be) and run myfix. Easiest thing would be to simply remove the SleepEnabler.kext, run myfix to rebuild system caches, then boot the internal disk as previously described - then install chameleon from there.

Use the pendrive to 'boot' but at the chameleon menu select your internal OS X drive and pass the following boot flags: UseKernelCache=No -v -f

Well it's not a bug with myHack at all, it's simply one of the many lovely little problems ML may have in store for us, but since it's a developer preview I don't think it's really worth the effort to look into it too much. You might consider trying to rollback AppleACPIPlatform.kext or perhaps IOACPIFamily.kext too from ML to the 10.7.3 version - you can copy it from your 10.7.3 /S/L/E to the 10.8 /E/E and run myfix - if it breaks something completely you can remove it. It might require a bit of playing to figure out what is going on but since this doesn't happen on my own system there isn't much I can do from my end to help you. If the problem doesn't exist when booting using only the Generic Extra - one of the other extensions you have in "Your Extra" might be to blame, this is also something worth considering.

After, strange that it didn't work - try to install myhack utilities, then load the Lion OS, open a terminal, and run myfix -t / -i That will install Chameleon from myfix - copy and paste the output here if there is any problem.

How does the system run under Lion 10.7.3? Does it exhibit the same boot delay?

There is now a single known bug with myHack 3 - it seems that the post installation doesn't run correctly on myHack OS X Install Disks that were created under Snow Leopard. So the temporary resolution is to: -Boot to the myHack OS X Install Disk -Go to the utilities menu and run myHack -Choose the Install Chameleon option, target your internal disk. -Exit myHack when the process is complete. -Run myHack from the utilities menu again -Choose the Install Extra option, target your internal disk. -Exit myHack when the process is complete. -Reboot to the internal disk. This should resolve your issue. I will be installing Snow Leopard again soon to see if I can reproduce this bug myself and to see if I can find a way to resolve it.