For easy reference: How to mount a Chameleon EFI volume

I recently decided to use Carbon Copy Cloner to move the SnowFalcor partition (OS X 10.6.3) I've been using for the past few weeks, onto the fastest of my hard drives. However, that means changing the default boot partition in the com.apple.Boot.plist file on the hidden EFI partition of the drive I boot with. But it having been a good while since I've had to mess with this stuff (and that's a freaking wonderful thing, lemme tells ya :), I had forgotten how to do that. So, from Terminal:

sudo -s
mkdir /Volumes/EFI
mount_hfs /dev/diskXs1 /Volumes/EFI

Then either edit or create the following key-and-string pair:

<key>Default Partition</key>
<string>hd(x,y)</string>

Use the command diskutil list to see what your volumes' identifiers are, and replace x to be the disk number and 'y' to be the volume number (e.g., for a volume labeled disk0s1, x would be 0 and y would be 1).

Don't forget to unmount the EFI volume before rebooting, otherwise it can cause problems later on. To unmount, run this command in Terminal:

sudo umount /Volumes/EFI

Best Hackintosh Build 2010

But I can't help but wonder what kind of build I would have at the moment, if the whole hackintosh thing had even occurred to me a few months ago. Anyway, a search for "best hackintosh build" quickly yielded a respectful, yet sincere and straight-forward, clearly articulated question as to what exactly you should get in order to have a kickass OSx86 in twentyten. And it goes something like this:

Motherboard: "Pretty much all Gigabyte GA-P55-UDx, says mdnz01, who reports running a GA-P55-UD3—presumably something like this one, which is $150 - $15 rebate & free shipping on Newegg. Indeed, they have a whole page of the GA-P55 models by Gigabyte (actually, on a side note, I think their trademark is actually all caps: 'GIGABYTE'... I just thought that was interesting... I guess they have to do something, right?)

So personally, I've got the Yorkfield Q9550 which is a Core 2 Quad running at 2.83gHz. I bought it in August of '09 for $219 on Newegg, and it feels pretty good to look on there this morning and see that, not only is it still for sale—not discontinued or anything—but it's actually more expensive! I got it on sale almost 9 months ago and today it would have cost me 50 bucks more. Cool.

And then, it would seem that it's the same price as an i7 Bloomfield, which at 2.66 actually has a  slower clockspeed. Apples and oranges, to be sure, but considering the currently overinflated prices for i7-compatible mobos and DD3 memory, I think I did okay, even if I'd done it today :)

So, I probably would have gotten something like the GA-EP45-UD3L. Why are they so much cheaper? I could not find a GIGABYTE mobo for my processor that was $100. I guess it does seem to have less ports, but I'm still not exactly sure where my extra $40-50 was going in my Asus P5Q PRO TURBO (they went the other way around and made the model all caps. I'm sleep deprived enough that these trademarks are a little startling as I type them out! ...ask yourself: should you continue reading the words of someone in such a mental state?? :P)

And finally, the graphics card. The Achilles' heel. The supreme caveat. The weakest link (just in terms of compatibility in OSx86-land. My SAPPHIRE Vapor-X Radeon HD 4870 1GB. On this install it's working great—QE/CI, OpenGL... I guess I still need to confirm that OpenCL works. I think it will, but the question will be just how well?

As I think this, I jump over to some threads discussing benchmark results using OpenCL Benchmark for Mac. Looks like the luckiest contestant over on this thread from the Aussie MacTalk forum is user dangelovich, whose benchmark tests took less than one second on his 8800GT, whereas other people—those that were lucky enough to even have the OpenCL capability ranged from 2-5 seconds on the average.

...oookay. Let's see how mine does:

VoodooHDA.kext in /Extra/Extensions = :-(

While attempting to reboot after installing VoodooHDA in /E/E didn't work. Watching the boot in -v mode, it started to print very slowly, while talking about VoodooHDA. Then I remembered this forum thread:

http://forum.voodooprojects.org/index.php?topic=399.0

Other kexts that don't do well in /E/E are:
   - lspcidrv.kext
   - Natit.kext
   - VoodooBattery.kext
   - VoodooHDA.kext
   - VoodooPower.kext
   - VoodooPS2Controller.kext
   - ClamshellDisplay.kext


...HOURS LATER: I just ditched the Ron's blog kexts after all, and simply installed the VoodooHDA.kext on iPortable here:
/Hackintosh tools/Snow Drivers/Intel HDA Audio driver/VooDooHDA 2.5.3 Snow Leopard/VoodooHDA.kext


Before reboot, I ran Kext Helper. Rebooted with -v and sound works!

iPortable + Chameleon 2.0 RC4 r684 = Blue Screen

So yeah... no go on booting without the Kingston at the moment. However, I imagine that I'll be able to boot Windows from that now.

Unforunately, I don't know what versions they used (the creator(s) of iPortable, so it's hard to say what exactly isn't working. I did try to copy the boot file from one of the images, to see if that would be enough, but I got the same result.

Booting again from the iPortable USB and all is fine.

So, I have actually decided not to use all those "Ron's blog" kexts. Graphics is working wonderfully, with QE/CI/OpenGL, and I also already have networking. I have already been using file sharing and screen sharing, with no noticeable hiccups of any kind. So I have decided to only install VoodooHDA.kext, since I do still need a sound fix.

Furthermore, I'm going to try to install that kext to /E/E instead of /S/L/E, so as to try and keep the mods separate.

So I did that in terminal by copying the kext to /E/E using 'sudo cp -r' (the -r option means 'recursive', and this is needed here because Terminal can see that the kext is really just a folder.

Here I go!

Graphics Enabled!

After returning the graphics kexts to /S/L/E (see the last post), and repairing kext permissions as well as making the plist edits, rebooted with nothing except -v in case anything happened.

I tested Quartz by trying to place a dashboard widget. If you see the ripple effect when you drop the widget into place, then you have Quartz enabled. The "Chess" test is not so reliable, as I have found that I was still able to run it.

I also successfully tested video playback using VLC. Definitely have graphics accelleration. 1080p playback on the 1280x800 monitor was smooth and flawless.

Expose is smoother than on the Macbook, which—provided that graphics accelleration is actually working—is to be expected when this machine has a Radeon HD 4870 1024MB and my Macbook has the Intel GMA 950.

I've created a fresh backup with Carbon Copy Cloner (hereafter referred to as 'CCC') and saved it to an HFS+ partition on my 1.5TB drive, my Windows 7 drive, which I'm not planning on messing with any more, other than to save my backup images.

However, I have two 2.5" SATA drives, both previous drives from my Macbook. Having cleared all important data off of one, I went ahead and reformatted it, using a MBR table, and creating a 20GB partition at the beginning of the disk. I then restored the image I just made with my graphics accelleration working.

But also, since this is a fresh disc, I wanted to go ahead and try to get Chameleon working if possible, so I can remove the Kingston iPortable USB drive from this process. Even the minuscule bootloader is obviously loading slower than usual!

So here's how I did that:

1. Formatted the disk with a MBR (see earlier posts)
2. Downloaded Chameleon-2.0-RC4-r684-bin from http://chameleon.osx86.hu
3. Used the instructions in the "doc" folder to install from terminal. You'll want to run "diskutil list" from the command line to see what the BSD name of your disk is. If you booted OS X from the same volume you want to install Chameleon on, then it will probably be disk0, but do check for yourself!

So now I will restart from the restored image, and see if I can boot without the USB drive.

So cool to see that it worked on the first try! (minus the kernel panic, I guess :)

Fine-Tuning Methodology

I just ran the first successful boot of a volume restored from an image. This was without any flag at boot (except for '-v', just because I wanted to see what was going on, but nothing to change what was happening).

I used Carbon Copy Cloner 3.3 this time, as opposed to the first time, when I used CopyCat, which is the same app used in the guide.

The main reason I switched to Carbon Copy is because it has an incremental backup option. This will be valuable, as I will likely want to do new backups every time I am about to do something even remotely risky.

Also I really don't like CopyCat's interface. It deviates from the natural OS X style in bad ways. For example, say you want to cancel the current action. So you click 'Cancel'. Then it asks you if you're sure, but the buttons provided are "OK' and "Cancel", which is confusing. What if I click "Cancel" at this point? Will it think I mean "Yes, I'm sure. Cancel!" or "No, I'm not sure. Cancel the 'Cancel'". Worse yet, what if clicking 'Cancel' in the first place was an accident? What if continuing with the cancellation is going to cause damage? Epic design fail on the part of SubRosaSoft.

Don't deviate from what the masters of interface design do, for gods sakes, unless you plan on doing it even better ;)

And now that I'm done with that little rant, here's how I'll proceed in terms of adjustments and backups:

1. First, I'll do an incremental backup to save the few adjustments I've done so far.
2. Follow the instructions in /Hackintosh tools/Snow Drivers/Video Drivers. Here are those instructions, which I've cleaned up a little bit (mispellings and minor formatting issues). The highlights and italics indicate my notes regarding my specific build:
1. Remove framebufferdisabler.kext from /Extra/Extensions/.. and System/Library/Extensions.. folders In case you were wondering: I didn't see this kext in the S/L/E folder, either
3. Unzip RemovedGraphicsKexts.zip and move all .kept .kext files to /System/Library/Extensions Note: corrected misspelling on "kext", which really threw me off the first time! ALSO, MOVE ONLY THE KEXTS, NOT THE FOLDER WITH THE KEXTS IN IT.
   
   SO, QUICK NOTE HERE: I've actually had issues with this method a couple of times. I had forgotten about the first time this happened, actually.
   OS X doesn't always like it when you're just moving moving kexts into its /S/L/E (I'll just point out one last time: that's just shorthand for the /System/Library/Extensions). After about 20 seconds, it started giving me alert windows for a lot of the kexts (maybe all of them), saying that it couldn't use them. Then, as I was trying to run Kext Utility, hoping to fix the issues (mainly permissions issues, from what I understand, and ownership), I got a kernel panic.
   Also—not at all to my surprise—it panicked again when I tried to reboot, since the kexts are still in there and I wasn't able to do anything before had hung.
   
   So I hope this doesn't happen to you, but if it does happen, do the following steps and you're done (meaning, this is a replacement for steps 3-8):
1. Reset the crashed computer and at the Chameleon boot screen use "-v -x -s" to boot in    safe mode (-v does that) with command line only (-s stands for 'single-user mode')
2. Enter the following command to mount the drive so you can go in and do stuff:
   
   /sbin/mount -uw /
   
3. Run the script called 'pfix (snow)'. The command looks gnarly because all of the spaces and some characters have to have a backslash in front of them for the command line to accept them. This is called 'escape characters', because you are bypassing—escaping out of—the default meaning these characters have in the shell environment's syntax. So these commands go to the directory where the script is, then run the script. You can use that Tab key technique; it'll always save a lot of time.
   
   cd /Applications/OSx86Tools/Repair\ \&\ Set\ Permissions\ scripts/
   ./pfix\ \(snow\)
   
   QUICK NOTE: the 'sudo' command isn't necessary here, because in this mode we are already using the root account, which is the 'superuser' ('sudo' actually stands for "superuser do", not 'pseudo', as some knucklehead had once told me XD). So FYI, if you use this script in Terminal while you're logged in as yourself, you need to use sudo.
   
4. Now we're going to go ahead and use nano to edit the plist from here. Again, normally you would use sudo in front of the command below:
   
   
   
   
   
   
   
   
   
   

   nano /Extra/com.apple.Boot.plist

5. Go ahead and change "chocolate_kernel" to "mach_kernel", which my Core 2 Quad (the Q9550) runs just fine.
6. Change "arch=i386" to "arch=x86_64" in the 'Kernel Flags' entry.
7. I assume here that you already changed "PciRoot=1" to "PciRoot=0" per my other post regarding editing plist files. If you haven't done that, do that, unless 1 works for you.
8. Add a new key + string pair to use the graphics enabler:
   
   <key>GraphicsEnabler<\key>
   <string>y</string>
   
   
9. Press Control-X (as shown on the bottom of the interface in nano) to exit. It will want you to choose whether you want to save your changes, and also to confirm what filename to use. So you press 'y' first, and then just enter since we want to save to the same filename we opened.
10. 
    
4. Repair permissions with Kext Utility.
5. Remove com.apple.Boot.plist from /Extra folder on root partition.
6. Replace with /Hackintosh tools/Snow Drivers/com.apple.Boot.plist
7. You may have to remove also bootflag: arch=i386 from com.apple.boot.plist in extra folder... 
8. If this fails to work initially try changing "PciRoot=1" to "PciRoot=0" in the com.apple.Boot.plist
9. reboot
3. Assuming reboot is successful create another incremental backup. Keep in mind that you should save the backup to another drive. For two reasons:
1. If the drive in question fails, you don't want the backup to be lost, too.
2. Backup goes a lot faster if the backup utility can read from one drive while it writes to the other.
4. Proceed with P5Q specific kexts, per the guide here:
   http://rgwoehr.wordpress.com/2010/01/30/hackintosh-p5q-pro-turbo/
   Downloading the kexts at the end of the post was kind of a pain, so here they are in one .zip file:
   http://www.mediafire.com/?timfnmzmwnb
5. Assuming reboot is successful, run another incremental backup.
   

First edit to apple.com.Boot.plist

For the first edits to the version that comes with the iPortable USB image, I changed the following (highlighted stuff).






EthernetBuiltIn
y
Graphics Mode
1280x800x32
Kernel
chocolate_kernel
Kernel Flags
arch=i386 PciRoot=0
Timeout
5




So basically I just changed the "Graphics Mode" to match the screen I currently have connected to the machine, but most importantly, I added "PciRoot=0", to match my configuration.

I will test the use of the vanilla kernel, 'mach_kernel', which I have not seemed to have a problem with. It is suggested to use it unless your processor is not supported. Also, I'm going to go ahead and change the architecture to x86/64 by replacing "arch=i386" (32-bit), to "arch=x86_64".

A replacement .plist is included here:

/Hackintosh tools/Snow Drivers/Video Drivers/Removed Video Kexts/com.apple.Boot.plist

However, I'm not going to use that one. It would be nice if you could simply edit the .plist from where it is located, but you have to use the 'sudo' command from terminal in order to do that. Therefore, I just use the nano text editor which is available from the terminal. Just enter "sudo nano" and the path.


For example:

1. Open Terminal
2. Type 'sudo nano' and a space
3. Enter a forwardslash (the one next to the right-side Shift key on an ANSI US keyboard and an uppercase 'E'. Now, you should be able to press tab, which tells Terminal that you want it to guess what the rest of the path is, based on what you typed so far, against the possible paths. Since we know that so far, there is only one directory in the root that starts with an upper-case E, it will finish it for you.
4. Enter another forwardslash, and another 'c' or 'co' should do it. Hit tab again and it'll finish the whole pathname for the .plist file. If so, press Enter.
5. You'll be asked for the root password, which is the same as your password in OS X. If you run this command again right after this session, it might not even ask you again. But if you wait too long or close Terminal and open a new session later, it will once again make sure you have permission to do this.

Otherwise, just copy the .plist to the Desktop, use the Property List Editor included with iPortable, and then drag it back to /Extra, and Finder will ask you for your password. Same result either way.

Okay, graphics!