OS X 10.7.4 Software Update

So I waited a few days to gather some information from users on what has gone wrong with this one before posting if it is safe or if caution is advised. The verdict – caution is advised.

This is the first update that I myself have encountered a problem with so I will attempt to cover what I know as well as what others have found, and how to fix what we’ve seen break.

First problem report I heard was – a kernel panic when running the combo update.

This was related to ApplePolicyControl.kext – when the update loaded it, the system panicked and left things in a non functional state. The users resolution was to re run the combo update from a separate OS X installation, remove the problematic kext when it was done and to then run myFix. This extension is removed by the myHack “Remove Problematic Extensions” feature but that won’t help if it is loaded on a running system by a combo update.

This can be avoided however – if you have an smbios.plist that identifies your system as something that ApplePolicyControl.kext will not panic on – no panic will happen, this was the case with my own system. So you have two options:

  1. Create an smbios.plist for your system that ApplePolicyControl.kext will not panic on
  2. Run combo update from another OS X installation, targeting the 10.7.x OS X installation you want to update, when finished, run “Remove Problematic Extensions” function from myHack.

Ok, next problem – This happened on my system. When the update was completed, I rebooted. The system panicked on IOPCIFamily.kext. So I rebooted again with -f -v, no panic this time, but the system hung when trying to load AppleHDA, and claimed that kextd was not running. So first I attempted to boot into my ‘fail-safe partition’ which is basically an extra myHack OS X Install Disk for 10.7 that I have on my internal boot partition so I don’t have to dig out my USB stick every time something goes wrong. It hung at the same point….

While I am not entirely sure why the separate partition with a 10.7.0 OS X installer on it was effected by the update the reason for it happening isn’t really important – the solution is simple – I plugged in my USB myHack OS X Install Disk, ran myFix – a full one, not a quick one – and rebooted – everything works fine now. So to sum it up:

  1. Ensure your myHack OS X Install Disk is not attached or mounted on the system
  2. Run the 10.7.4 update and reboot when it is finished
  3. Boot to your myHack OS X Install Disk
  4. Run myFix, select full not quick, run, and reboot when it is finished
  5. Boot your OS X 10.7.4 installation

The last problem I have seen was reported by a user on the forum. His Nvidia GTX295 stopped working after the update. This is a problem I have seen in past updates and why in the myHack guide I always advise users to backup at minimum their /S/L/E directory prior to running any OS X updates. You may read the thread he opened on the forum HERE

The solution for this problem is as follows, and the following method can be adapted to virtually any hardware device that no longer functions after an OS X update due to Apple’s modifications of the System Extensions:

  1. Prior to running an OS X update, always backup /System/Library/Extensions
  2. In his case his NVidia graphics no longer work due to updates of the Nvidia graphics so he could either determine exactly which kext is the problem and replace only that one with the one from his 10.7.3 backup, or he could replace all of the nvidia graphics extensions including the frame-buffers
  3. Determine which extensions you want to override in /System/Library/Extensions in his case he took all of the Nvidia extensions and frame-buffers
  4. Place the extensions from 10.7.3 backup in /Extra/Extensions
  5. Run myFix, reboot
  6. Boot to OS X 10.7.4

A full list of the NVidia extensions and frame-buffers is in the thread I linked to, the clean way to do it would be to just grab the ones for your card specifically – I will be explaining to him how to figure out which ones he needs in the forum thread.

So there you have it, that is how to avoid the 3 most common problems I have seen thus far with this update. If you encounter a new one please let me know via the forum – I will update this post if needed.

Additionally, keep in mind 10.7.4 is pulling code in from 10.8 so there might be a number of issues for users who are still relying on older graphics or i386 libraries…

Dual Booting Demystified

I have had this question asked to me numerous times and some have suggested that a simple guide would be helpful to them. So here it is, a simple guide to creating a dual boot with OS X 10.6.x & Windows 7 on a single hard drive using the Chameleon bootloader. This is not the only way to achieve this goal but I am going to outline the methods I personally use which are among the simplest and easiest to duplicate.

Disclaimer: Repartitioning your hard drive can and will erase all data contained on it, resizing partitions with a utility like GParted may alter the partition table without destroying data but there is still a significant risk of failure and data loss. I strongly advise you to ensure you have backed up all important data before attempting ANY alteration of your existing partition structure. I am not liable for any data loss due to the (mis)use of this guide, I have warned you of the risks and advised you to make a backup of your data, I am not responsible for your data, you are!

Important Note: There are a lot of people who use GUID partition types for their hackintosh drive. While this arguably has some advantages when using OS X exclusively I personally advise against the use of GUID partition types, particularly when dual/multi-booting. It will only complicate matters and offers NO advantages over a standard MBR partition scheme in my opinion. This guide assumes you are using an MBR partition scheme – if you are using a GUID partition scheme I encourage you to switch it back to MBR or the instructions here may fail. (The instructions here should actually work for a GUID partitioned disk – but I have not tested them so if you choose to attempt it don’t be upset with me if it fails. If you happen to be one of those people who have their heart set on using a GUID partition scheme and you do test this method – please let me know your success/failure so I can include the information in this guide, be sure to include any additional instructions that you used (if any) so I can present the information as accurately and completely as possible.) **Important note: Older operating systems (Windows XP, older versions of linux, etc) will not function on a GUID partitioned device.

Note: This guide assumes you are using fdisk440 – NOT the standard fdisk that ships with OS X. You can find fdisk440 in the Tools bundle of the myHack app or Chameleon bootloader.

Section 1 : Basic Instructions

Step 1) Allocate space. Personally I plan in advance if I have the intention of dual-booting. So when I booted my trusty myHack USB Installer to install OS X on my system I used disk utility to create two partitions, the first being an HFS+ partition for OS X, the second being a FAT32 (MS-DOS) partition which I will later prepare for Windows 7 Installation. Since my drive is 1TB in size I just created two 500GB partitions for simplicity sake but adjust this to meet your individual needs. If you did not plan in advance you have three options, make a backup of your files and reinstall, make an image of your partition(s) and restore it after repartitioning the drive, or use a utility like GParted to resize the partition(s). Resizing partitions can take a very long time depending on how large they are so personally I’d just backup my files and reinstall but you decide what option works best for you.

Step 2) Install OS X. ( Please tell me you know how to do this by now ;p ). Yes, you can also install Windows 7 first but the methodology will be slightly different – I install OS X first so for the sake of this guide you should too. Ensure to boot to OS X and complete the post installation configuration and installation of myHack (Chameleon, pc efi, kexts, etc) to the installation drive and verify that it is booting without the USB drive attached and functioning properly before moving on to step 3.

Step 3) Install Windows 7. This should be fairly self explanatory but I will explain a few of the important details so you don’t get stuck. Boot the Windows 7 Installation DVD, begin the installation as normal. When you get to the “Which type of installation do you want” section choose “Custom (Advanced)” it will then ask you “Where do you want to install Windows” – choose the FAT32 (MS-DOS) partition we created in step 1 and click on “Drive options (advanced)”. Click format. Click OK. Click Next and proceed with the installation as normal. You have to format it with the Windows 7 installer before it will allow you to install Windows 7 on it because Windows 7 requires an NTFS formatted partition which is flagged as active. It will reboot a couple of times during the installation process, you will notice that the system will now boot directly to Windows 7 and you will no longer see the Chameleon boot prompt. After you have Windows 7 setup to your liking and are ready to fix the dual boot move on to step 4.

Step 4) Repair MBR. Windows 7 has infected your MBR… In the past you could simply set the active partition on the drive and it would boot to it but if you were to change the active partition now your system will hang at boot.We have to repair the damage Windows has done… Insert your handy dandy myHack USB Installer and use it to boot your OS X Installation (Boot to the USB Installer but at the Chameleon boot prompt select the OS X installation on the internal hard drive instead of booting to the Installer itself). Actually it doesn’t really matter if you boot the installer or the installed OS as we are only going to be using the terminal to repair the MBR but the internal hard drive boots more quickly and is more responsive in general so I choose it to save time. Once you have booted open a terminal and run the following commands (which I will guide you through step by step).

First lets get a list of the disks in your system so we target the correct one by running the “diskutil list” command.

myHack-Pro:~ Conti$ diskutil list
/dev/disk0
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:     FDisk_partition_scheme                        *1.0 TB     disk0
1:                  Apple_HFS myHack                  500.2 GB   disk0s1
2:               Windows_NTFS                         500.0 GB   disk0s2
/dev/disk1
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:     FDisk_partition_scheme                        *8.0 GB     disk1
1:                  Apple_HFS Mac OS X Install DVD    8.0 GB     disk1s1

As you can see I have two disks in my system, /dev/disk0 is the 1TB with two 500GB partitions on it, one Identified as Apple_HFS type and has the name I assigned it (myHack), the other is identified as Windows_NTFS type (This is Windows 7). /dev/disk1 as you can see is the 8GB USB Installer which I used to boot the system. You’re results will be different but the important thing to identify here is the /dev/disk# that contains your OS X & Windows 7 installations and the partition number of each of them, in my case OS X being on /dev/disk0 partition #1 and Windows 7 being on /dev/disk0 partition #2.

Next we are going to write a new MBR to /dev/disk0 by running the “sudo fdisk440 -u /dev/disk0” command. (Replacing /dev/disk0 with the /dev/disk# your dual boot is installed on if different). If this is your first time using sudo on this system it will give you a warning message, ignore it… You will be prompted for your password, enter it and continue.

myHack-Pro:~ Conti$ sudo fdisk440 -u /dev/disk0

—————————————————–
—— ATTENTION – UPDATING MASTER BOOT RECORD ——
—————————————————–

Do you wish to write new MBR? [n] y

As you can see it displays a warning that it will update the MBR and it prompts you for confirmation. Enter “y” and hit enter to confirm as I have in the example above.

Now we are going to change the active partition to the one OS X (and Chameleon) is installed on. Run the “sudo fdisk440 -e /dev/disk0” to open the disk in edit mode.

myHack-Pro:~ Conti$ sudo fdisk440 -e /dev/disk0
Enter ‘help’ for information
fdisk: 1>

You are now in edit mode, be careful here one wrong move and you’ll wipe the drive blank and be back to step1! Lets type “print” to view a list of the partitions on this drive and confirm that we are editing the correct drive and set the correct partition to active.

fdisk: 1> print
Disk: /dev/disk0    geometry: 121601/255/63 [1953523055 sectors]
Offset: 0    Signature: 0xAA55
Starting       Ending
#: id  cyl  hd sec –  cyl  hd sec [     start –       size]
————————————————————————
1: AF    0   1   1 – 1023 254  63 [        63 –  977027392] HFS+
*2: 07 1023 254  63 – 1023 254  63 [ 977027499 –  976495527] NTFS
3: 00    0   0   0 –    0   0   0 [         0 –          0] unused
4: 00    0   0   0 –    0   0   0 [         0 –          0] unused
fdisk: 1>

Ok so as we can see here partition 1 is HFS+, partition 2 is NTFS and that little asterisk before the 2 (*2: 07 1023 254  63 – 1023 254  63 [ 977027499 –  976495527] NTFS) means that this partition is flagged as active, if we were to reboot right now Windows 7 would boot as a result. We want that active flag to be on partition #1 so OS X / Chameleon loads and lets us then choose which of the partitions to boot from a nice graphical menu. Now that we have properly identified all the partitions lets type “flag 1” to flag partition 1 as active. (Change the “flag #” partition number if your configuration is different!)

fdisk: 1> flag 1
Partition 1 marked active.

Done, now all we have to do is write the changes to the disk and reboot the computer. Type the “quit” command to write the current MBR to disk and exit fdisk440.

fdisk:*1> quit
Writing current MBR to disk.
Device could not be accessed exclusively.
A reboot will be needed for changes to take

Step 5) Finish. Thats it, you’ve done it! Un-mount and remove the myHack USB disk and reboot the system with the internal disk. If all has gone well you will be greeted by the Chameleon boot prompt and you can easily select between OS X (which will be the default option) and Windows 7. Congratulations! Continue onto section 2 to learn more.

Section 2 : Troubleshooting & Multi-Boots

 

Section 2:a – Time synchronization

This is the most common problem that will be encountered when dual booting or multi booting with OS X on a PC. OS X sets your hardware clock to UTC (Coordinated Universal Time), windows and many Linux distributions on the other hand typically default to setting your hardware clock to “Local Time”. The “time zone” you are located in is considered local time – for example I am personally located in the UTC+9 time zone so when I set my clock in OS X it sets the hardware clock to UTC time (which will be 9 hours earlier than my local time). When I reboot into Windows or Linux they will assume my hardware clock is local time thus the clock will now be displaying UTC time which is 9 hours off from my local time. Fortunately this is very easy to resolve.

Part 1) Windows

To correct this problem in Windows 7/Vista we will need to edit the registry. Note: These instructions will not work for Windows XP.

At the windows desktop do the following:

If you would rather not edit the registry manually simply download and run this utcfix.reg file I created to import the data directly into your windows registry.

Windows 7 UTC Registry Fix 1.0
Download Windows 7 UTC Registry Fix 1.0
Downloaded 3127 times.
Size: 299 bytes
  • Exit all Windows-based programs.
  • Click Start, type regedit in the Start Search box, and then press ENTER.
  • If you receive the User Account Control dialog box, click Continue.
  • Locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\TimeZoneInformation
  • In the right pane, right click anywhere on the empty space and create a new DWORD (32-bit) Value. [NOTE: On 32-bit versions of Windows 7/Vista , you will only see D-WORD]
  • Name it RealTimeIsUniversal [NOTE: This is CaSe Sensitive so make sure it is exactly as shown here.]
  • In the right pane, right-click RealTimeIsUniversal in the Name column, and then click Modify.
  • In the Value data box, type 1, and then click OK.
  • On the File menu, click Exit to close Registry Editor.

This tells windows that your hardware clock is set to UTC and it will adjust for your time zone accordingly (the same way OS X does).

Next simply reboot into OS X and make sure your time is set correctly. The next time you reboot into Windows you should see the correct time – if not ensure that you have properly configured your time zone via the regional and language options in the control panel.

Part 2) Linux

To correct this problem in Linux requires a different process. Not all Linux distributions will be configured to set your hardware clock to a local time zone, some actually do use UTC by default but if you notice a time discrepancy do the following.

First we are going to open /etc/conf.d/clock in a text editor. In this example I will be using nano but if you do not have nano you could also use vi, pico, gedit, kate, or whatever text editor you like.

Open a terminal and type the following to open the file:

sudo nano /etc/conf.d/clock

(type your password)

Find the CLOCK= value.

It will likely appear as follows:

CLOCK=”local”

Change it to:

CLOCK=”UTC”

Save your changes and exit your text editor… (In nano it is ctrl+o to save changes and ctrl+x to exit.)

Now before we reboot we should make sure that we have set the correct local time zone. You may do this with a GUI tool… I do the following in my own flavor of Linux, it should apply to many but not all Linux distributions – consult your own distributions documentation if the following does not apply to you. I will be using my own time zone in the following example, you will have to adjust the commands to apply to your own location.

First you will want to locate your own time zone file in /usr/share/zoneinfo. I am in UTC+9 (Korean Standard Time) so my time zone file is located in /usr/share/zoneinfo/Asia/Seoul

Copy your time zone file to /etc/localtime by running the following command in a terminal.

sudo ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime

Now open the /etc/conf.d/clock file back up and locate the TIMEZONE= value and set it to your own local timezone, for example mine looks like this:

TIMEZONE=”Asia/Seoul”

Save changes and exit your text editor. Now you should be all set to reboot.

Section 2:b – Windows BSOD when AHCI mode enabled

This issue typically arises on windows installations that existed before enabling AHCI mode in the bios. The cause of this issue is the AHCI driver (Msahci.sys) in Windows 7/Vista being disabled. This driver must be enabled before you change the SATA mode of the boot drive.

Why would the Msahci.sys driver be disabled?

During the Windows 7 or Windows Vista installation process, any unused storage drivers are disabled. This behavior speeds up the operating system’s startup process. When you change the boot drive to a driver that has been disabled, you must enable the new driver before you change the hardware configuration.

How can I enable the Msahci.sys driver?

Well first you will have to disable AHCI mode in your bios temporarily to be able to get back into Windows… Go ahead and boot windows normally (it may prompt you to load recovery console because it will have detected that there was a BSOD the last time you attempted to boot the OS, you do not need to enter the recovery console so select boot windows normally and continue). After you get to the windows desktop do the following:

If you would rather not edit the registry manually simply download and run this ahci.reg file I created to import the data directly into your windows registry.

Windows 7 AHCI Registry Fix 1.0
Download Windows 7 AHCI Registry Fix 1.0
Downloaded 603 times.
Size: 278 bytes

  • Exit all Windows-based programs.
  • Click Start, type regedit in the Start Search box, and then press ENTER.
  • If you receive the User Account Control dialog box, click Continue.
  • Locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci
  • In the right pane, right-click Start in the Name column, and then click Modify.
  • In the Value data box, type 0, and then click OK.
  • On the File menu, click Exit to close Registry Editor.

After you have edited the registry (or imported the ahci.reg file I provided above) you will need to restart your computer, go back into your BIOS setup and re-enable AHCI. When you login to Windows again, you’ll notice the installation of drivers for AHCI. Another restart will be required to finish the driver installation.

Section 2:c – Multi-Boot Configuration

This section will eventually focus on configurations that involve more than just OS X 10.6 and Windows7. I intend to add a linux example to this section as soon as I have some more time to work on it.

Conclusion

It is my hope that this tutorial will help you to easily setup your own dual boot and that it will also help you to understand the underlying principals involved.

Cheers

– Conti

How to repair your REAL Mac if you broke it with the chameleon bootloader.

This post is intended only for actual Apple (Mac) computer systems that are not booting due to accidental installation of the chameleon bootloader to the Apple computer system’s hard drive.

If you are one of the unlucky ones who ignored my numerous warnings or just accidentally pressed the wrong button while running the myHack installer from a real MAC here is an example of how to repair the partition scheme on a real MAC so that it will boot again – after accidentally installing the chameleon bootloader to the MAC’s internal hdd.

Note: I have not tested this myself – I’m not that adventurous when it comes to my real MAC, however these commands should work. Ultimately if nothing posted here works you will likely have to wipe the drive out completely and re-install OS X.

WARNING: Do not perform any of the following actions without backing up your critical data first. Fiddling with partition tables is dangerous. A simple typo could lead to complete data loss. You have been warned! [ You can backup critical data even if you can not access the system, if absolutely necessary, by removing the internal hdd and plugging it into another computer, the use of data recovery software may be required depending on circumstances. ]

GUID SOLUTION:

1) Boot your mac with an OS X Install DVD (doesn’t matter which version, whatever is installed on your system would be best).
2) Start Disk Utility
3) Select the OS X HDD/SSD that you screwed up (not specific partition)
4) Go to the Partition tab
5) Grab the lower right corner of your key partition and resize it a little bit (no matter how much/little you resize it as long as you change the partition size)
6) Click Apply. Relax, this will NOT erase your HDD/SSD, it only rewrites your GUID partition data that will fix your HDD/SSD.
7) Quit the Disk Utility and reboot.
8) Enjoy your restored Mac that should now boot normally!

MBR SOLUTION:

Boot your mac with an OS X Install DVD (doesn’t matter which version, whatever is installed on your system would be best) and use Terminal on it to run the following commands.

Once booted into the GUI, open a terminal and type

diskutil list

to get a list of all disks on your system. Assuming /dev/disk2 is your problematic disk with the MBR partition scheme, type

sudo fdisk /dev/disk2

to verify the current partitions on it (should list partitions on the disk, if not don’t worry it’s likely because of the chameleon bootloader). This command will not apply any changes. The drive with an “*” next to it is the active partition (if any). Now type

sudo fdisk -u /dev/disk2

which writes a new MBR (master boot record) while keeping current partition information.

In order to be able to boot from a partition, it must be flagged active. Type

sudo fdisk -e /dev/disk2

to open the drive in fdisk’s editing mode. It will possibly complain “could not open MBR file /usr/standalone/i386/boot0: No such file or directory”, this should be safe to ignore. The following transcript shows what to do next:

fdisk: 1> flag 2
Partition 2 marked active.
fdisk:*1> quit
Writing current MBR to disk.

You’re done! Cross your fingers and reboot your MAC…

If any of this is confusing to you please read the OS X fdisk man page for more information.

Permissions & KEXT Caches

The information on this page applies only to Snow Leopard, for Lion the permissions are the same but prelinked kernel caches are used instead of Extensions.mkext files.

Additionally the “pfix” utility is now deprecated, I have replaced it with the myfix utility instead, Please consult the downloads page for a link to the latest version of myfix.

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.

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.