@CSUFSteve: Triple boot from a Chameleon USB key? It's perfectly doable, and quite easy. I've stayed that way for a good while, and it's nice to see how a USB stick literally becomes a "key" to your system. Without the USB key plugged in, my system was booting straight into Win7 Ulti 64, which I've let take over the master boot record (not that you have much choice on install
).
Some useful hints: *Always* keep TWO USB sticks, one for experimenting with new kexts / settings / tricks / tweaks, and one with a stable / known-good / working kext selection and setup. That way, whenever you screw up something (and trust me, you will, more than once) you'll still have your safe-stick to boot up with, and get a stably working system. *Never* commit changes to both sticks at once (sometimes it's tempting), you better keep your safe-stick a little bit obsolete, but stable. This two sticks setup saved my @ss quite a few times.
I think there was a 64-bit version of MacDrive out already, but all I've had was XP64, XP32 and Linux, on my home boxes. First time I've tried Win7 was on this triple boot Hac, and that came *after* I've installed Snow already.
Now, what's more important:
About driver caches (Extension.mkext files): On my stick (or EFI / boot partition, to same effect) I only have /Extra/Extensions/ . I've left my /System/Library/Extensions/ *completely* untouched on my Snow partition. I did not edit, modify or delete anything from it. Instead, I've played with mkext files, placing *all* the kexts I need in /Extra/Extensions/ even if some of these kexts are overlapping with existing S/L/E ones.
Your boot volume may be a USB stick, EFI partition, or a separate, small non-journaled HFS+ boot partition. On this volume I have all my kexts in /Extra/Extensions/ , and I create an Extensions.mkext package, issuing a command like:
kextcache -v 2 -t -m /Volumes/YourVolumeNameHere/Extra/Extensions.mkext /Volumes/YourVolumeNameHere/Extra/Extensions/ /System/Library/Extensions/
Note that I'm including both my boot volume's /E/E/ and my Snow installation's /S/L/E/ to the build path. That way, even if I have two kexts with the same name, the one from my /E/E/ will take precedence, and still, I won't have to edit or remove the other one from /S/L/E/.
As I see Chameleon booting, if it finds an /Extra/Extensions.mkext it will load first, and Chameleon will no longer even look in /E/E/ for more kexts. Then it will load /System/Library/Extensions.mkext, do all its other mojo (dsdt, GraphicsEnabler, and the like), and boot up the system, eventually.
If I have a modified kext in /E/E/ (e.g. IOATAFamily.kext) mine will simply load first.
Later on, when the kernel will try to load the original one from /S/L/E/ it will notice that a kext with the same name already exists and is running OK, so there's no need for another instance. That way there's no more need in editing or deleting kexts in /S/L/E, leaving my Snow install nice and fresh like vanilla.
Maybe this approach is a little bit redundant. I still have to try building an Extensions.mkext from /E/E/ only, and see if I can obtain the same effect without adding /S/L/E/ to the mkext build path as well. I'll try it out on my *other* stick, and come back with the results at a later time.
Same precedence rule did NOT work for me by just placing my own kexts in /E/E/, that's why I've built an Extensions.mkext in the first place, as described above. There may be better ways to do this, if you have found one, please do post it here, this is all work in progress.
Please note that this is all new grounds to me as well, and part of it has been learned via the good old trial and error method. That said, all of your input, feedback, comments and opinions are more than welcome.
@rocksteady: Thanks a lot for the good words, and the attention we're getting here. I might be too lazy to start my own topic, so here we go, I've just combined my ideas with what's already been well said here. I hope r0m30 doesn't mind, I don't want to steal his thunder.
That said, we'll keep the ball rolling!