I've been playing around with the GRUB2 boot loader a bit recently, and I've run across some interesting references. To summarize what I've found, it's possible to use GRUB2 as the only boot loader to boot both Linux and OS X. That is, there's no need for PC-EFI, Chameleon, Boot Think, etc. GRUB2 will also boot Windows, although it does need the help of the 2nd-stage Windows boot loader (BCD, I believe it's called). The end result is one menu for all your OSes. This configuration also reduces the chances of problems from one boot loader overwriting another one's files.

So, let's back up a bit. GRUB2 is the next generation of the GRUB boot loader. (The original is now called "GRUB Legacy.") GRUB2 is still officially in beta, but I've been using it on my multi-boot laptop for a while (currently SUSE Linux 11.0, OS X 10.5.6, and Windows 7 RC). GRUB2 is designed to be more modular than GRUB Legacy, it's multi-platform, and it's got various other enhancements. Two of these are limited EFI emulation support and support for loading XNU kernels.

I'm going to assume in the following that you know a bit about Linux, software compilation, and GRUB or GRUB2 installation and configuration. If you don't, try Googling on these topics to find some tutorials.

My initial tests, using a GRUB2 RPM intended for Fedora 10 systems, were less than successful. To get OS X booting, I had to download the grub-1.97~beta3.tar.gz source code tarball from the GRUB Web site and compile it locally. (I compiled under Linux. A quick attempt under OS X failed, but it's conceivable this problem could be overcome.)

If you're familiar with GRUB but not GRUB2, you should be aware that the configuration file name and syntax have changed. The new filename is /boot/grub/grub.cfg. Some of the configuration file changes will be obvious below, but note that GRUB2 numbers partitions differently. What was (hd0,0) in GRUB Legacy is (hd0,1) in GRUB2, with corresponding changes to other partition numbers. Below are the three entries I'm using to boot Linux, Windows, and Mac OS X:



If you try something similar, pay careful attention to system-specific items, such as the disk and partition identifiers and the video mode. After setting this up, typing "/usr/local/sbin/grub-install /dev/sda" installed it for me, including copying a boatload of files to the /boot/grub directory. The explicit path to /usr/local/sbin ensures that I installed my locally-compiled GRUB2 rather than the distribution's standard GRUB. The new files in /boot/grub hold the modular GRUB2 components, such as filesystem drivers, the EFI emulation code, etc.

A few random comments:

• The system boots in verbose mode, similar to passing the "-v" parameter via Chameleon or some other traditional OSx86 boot loader. I haven't yet figured out if it's possible to get a more GUI boot out of GRUB2.
• My test system is running a Voodoo kernel. I know of no reason other kernels wouldn't work, but I've also not tested them.
• My system has a hybrid MBR, which GRUB sees as GPT. I haven't tried this on an MBR-only system. I have no reason to think it wouldn't work, but I thought I'd point out this detail.
• On GPT disks, GRUB2 likes to have a small (a few tens or hundreds of KB) partition of type "BIOS boot partition" in which it can install its second-stage boot loader. It will work without this partition, but such a partition is recommended.
• I haven't yet investigated ways to pass additional parameters to the system (-f, -x, etc.).
• GRUB2 allows you to edit its entries on the fly, so you can make boot-time changes. IIRC, you press the 'e' key when the menu comes up and you can edit the menu item.
• I've reconfigured my system to use an HFS+ /boot partition (in Linux) so that I can edit the grub.cfg file in either OS. This seems fine so far, but it's only been set up this way for a short time. FAT might also work, but my experience is that some GRUB and GRUB2 configurations rely on symbolic links, which aren't supported in FAT. Oddly, the OS X Disk Utility deleted my EFI System partition and reverted my hybrid MBR to a plain GPT setup when I used it to format the /boot partition. Both problems were easily rectified, but annoying.
• GRUB2 is not yet common on emergency disks. GRUB-2 includes a grub-mkrescue command that I believe creates emergency boot disks (USB flash drives, CD-ROMs, etc.), but I've not yet tested this.
• So far I've tested this on only one system. I've got another multi-boot system with which I might test this configuration, but I haven't gotten around to it yet.

Overall, I wouldn't recommend that everybody ditch Chameleon, Boot Think, etc. in favor of GRUB2. It might be worth considering such a configuration if you dual-boot with Linux or some other OS that relies upon GRUB or GRUB2, though. This will give you one boot loader configuration file and a reduced risk of problems from one boot loader stepping on another's feet, as it were. If possible, I recommend keeping a second boot path option available -- in other words, a GRUB2 option to boot via Chameleon, Boot Think, PC-EFI, or whatever. This might be handy if GRUB2 suddenly stops liking your XNU kernel or something.

I'm surprised this post hasnt caught more attention, considering how groundbreaking this is: a fully developed boot loader and boot manager that can load windows, linux, os x with just a single installation and code, it could potentially wipe chameleon (and of course other "things" like the open-source-without-public-source "Boot Think" or the always coming-soon and closed source and maybe future pay-ware once its finished "XPC") from the scene.
From that page linked it seems almost everything is already supported in grub2: loading extensions and mkexts from /Extra locations, even loading plist only extensions without code, injecting efi properties, replace dsdt and even other acpi tables, even supports writing variables to a fake nvram, only thing missing could be DMI patching for proper SMBIOS working...
Anyway, I can report I tried the grub2 package from Fedora 11 and I also failed, even though it seems to be more updated (1.98) but the datecode is older (from 2008, but latest grub2 source package seems to be 2009/10).
I installed it in a USB drive and it didnt boot succesfully in my system but the USB stick worked in qemu).
I think it could be because the fedora package is compiled without certain modules needed like xnu support or efi emulator. Did you install grub2 to OS X HD or to a another drive?
Could you provide a compiled binary of latest version? I was going to do that but I stopped, I think Fedora uses some kind of patch to rename grub2 binaries (to grub2-install, grub2-setup and the like...) and I was afraid I would break my Fedora installation. I'm not sure if we can use that kind of binary just by replacing it in the installation, or do we need to update the boot.img files?
BTW I think your problem with the second system is not caused by grub2 but some hardware incompatibility in the system installed, it could be caused by the ethernet card there not being supported at all, so OS X could be missing a MAC address to create the platform uuid. It could be fixed by using a PlatformUUID.kext or UUID.kext, some SMBIOS enablers can also do that. See this thread on voodoo forum for more info.
I'll be getting the next Kubuntu version due out in a few days which reportedly switched to pure grub2 as the only boot loader and I will try again and report back.

You're probably right about lack of modules causing problems. On my second system, I had to jump through some hoops to get the software to compile with XNU and/or EFI emulation support (I don't recall the details of what was giving me compilation troubles). Unfortunately, I started that after writing my first post, so it didn't get included. What I had to do was to edit the configure script to change every instance of "mcmodel=large" to "mcmodel=small", except for instances in strings that are printed for the user. As I recall, the mcmodel=large configuration is useful on systems with over 4GB of RAM, but it's incompatible with the XNU and/or EFI emulation code.

On my working system, I compiled everything under Linux and put the GRUB2 files in the standard Linux location (/boot/grub), which was originally an ext2 partition. I changed it to be HFS+, though, since I wanted to be able to edit the files from OS X. This is a weird configuration, but it works for me.

You should be able to safely install a locally-compiled binary on your system, since it will install the binary code in /usr/local rather than in / or /usr. You'll then be able to select which utilities you use by preceding the binary name with a complete path (e.g., "/usr/local/bin/grub-install"). The real risk is in the boot loader code itself -- the stuff that goes in the MBR, the boot partition's boot block, etc. I recommend having an emergency disk (System Rescue CD or the like) standing by -- but you'll either need to have a GRUB Legacy configuration handy or have GRUB2 for your emergency disk; the last I checked, most emergency disks provide GRUB Legacy but not GRUB2. A tip: You could set up a "regular-use" /boot partition with a GRUB2 configuration and an emergency /boot partition with a GRUB Legacy configuration. If you install GRUB Legacy in the emergency /boot partition's boot sector, that'll provide you with an emergency way in; you can use System Rescue CD to re-install the MBR portion of GRUB Legacy, using the emergency /boot partition as a reference. When you successfully reboot Linux, you can then re-install GRUB2 using your normal /boot partition as a reference.

I haven't done much to try to get my second system working with GRUB2 since my last post -- I've been busy with other things, and this is pretty low-priority for me. I suspect you're right that it could be fixed by the right kext or other configuration magic, but my knowledge of the OS X boot process is still sketchy enough that I'd be stumbling around in the dark to try to find the solution. Maybe when I've got some free time I'll track it down and fix it.

Hi Rod!

Glad to see that I'm not alone with trying to get GRUB2 working... I say trying because I can't for the love of God get it to work. I have a tripple boot system here. First I installed Win7 and after that SnowLeo. Lastly I installed Ubuntu 9.10 that ships with GRUB2 as default. I didn't knew that when I installed it but that was a (un)pleasant surprise. =/

SnowLeo is installed with the help of Contis brilliant myHack. The system is a dual XEON X5472 with geforce 8800GTS. All OSes runs brilliantly but can't get GRUB2 to cooperate. =/ As of today I boot chameleon from USB stick to boot into snowleo. Ubuntu and Win7 works fine from GRUB2.

GRUB2 autodetects the snowleo partition and adds it with these settings:



But I can't get it to start with that. I end up with a kernel panic saying:



There might be some typos in that. I typed of a crappy iPhone picture. =/ I can take another look if it's of any help...?

I would really be fine with loading chameleon from GRUB2. I don't neccesarly have to load SnowLeo directly from it.

I guess there'll be loads of people screaming for help in a few days when Ubuntu 9.10 is released. But if anyone know how to really get it working I'm open for suggestions. I have tried what's covered in this thread without success, just a nice smorgosbord of kernel panics. =/

Cheers

/NEO

I'm getting exactly same situation with a vanilla install that otherwise works fine with chameleon (same cpu KP message) , and have been trying to sort this for a couple of days now, tried mbr & gpt, inputing fsb, video, etc. to no avail.

I wonder if grub2 cannot boot snowy kernel! Have trolled the web and cannot find anyone else who has reported a successful boot on a hack box.

Rod, is it possible your partitioning method is helping somehow ? I notice your using voodoo kernel - perhaps thats more compatible!

This will be a hot topic soon - I hope the solution is not far away.

Just a wild guess but that doesnt look like a valid HFS+ uuid, they are supposed to be like this:


Try getting the real UUID from your OS X partition and changing grub.cfg code according to it.
If that doesnt even work you could also even try to hardcode the uuid in the kernel arguments line:


Also maybe you are missing some required module that is not loaded by default with Ubuntu config, you can check which ones are loaded with lsmod in grub2 command line.

Thanks for the pointers, tried these without any success. Also my grub2 was latest compiled not the ubuntu packaged. Cannot see anything obvious missing in terms of modules.

I did notice bug reports on ubuntu related to UUID and also a new report of os x boot fail so I guess I'll wait till 29th for the official release and hope it's fixed then or soon after.

Sorry it didnt work.
How does modules work exactly? I undertand even if they are present in grub's dir you still need need to insmod some of them at runtime right? Or can you do a custom compile with all the modules active? Because I'm not sure which ones are needed for OS X, maybe thats whats failing...

First, there is a GUID/UUID display format that uses something other than the usual long format with dashes. It's conceivable that GRUB2 is using that format. Unfortunately, I don't recall much about it, so I don't know if the posted UUIDs are correct for this format.

Second, since the error message is complaining about invalid kernel options, I'd try simplifying the xnu_kernel line. Model it after the one in my example, changing only the rd= option, but keeping the form I used (/dev/disk#s#) rather than trying to specify the disk by UUID.

Third, it is possible to chainload using GRUB2. Try copying the boot sector from the USB flash drive you use to boot into a file, as in "dd if=/dev/sdc of=/boot/chameleon.mbr bs=512 count=1" (changing /dev/sdc as necessary on your system). You can then create a GRUB2 chainloader configuration, as in:



You may need to change your device identifiers, and omit "/boot" from the chainloader line if you've got a separate /boot partition. This should at least get you booting in a two-bootloader way, though.

Incidentally, the issues with GRUB2 in a multi-bootloader configuration aren't really any different than those with GRUB. GRUB2 is more flexible in that it can (sometimes) boot OS X directly -- but as your experience and mine with my second system demonstrate, this isn't always easy, and might not even always be possible.

I had a setup where grub chainloads the OS X partition, you might want to try that instead.

And could you maybe give an example of how that would look?

Been trying with this but can not get it to work. I have saved the MBR from the working USB-stick to /boot/chameleon.mbr and I have added this in grub.config:



hd0,2 is the SnowLeo partition and hd0,6 is my Ubuntu-partition. I end up at a black screen with the text:

y-MORE--

I think I was wrong about the uuid, not sure but I believe what "xnu_uuid a0297dea90ce0b44 uuid" do is converting the uuid from linux format to the traditional hfs+ format understandable by OS X, so it must be the kernel options what are wrong as you say.




If your OS X partition has chameleon's boot sector (boot1h) you should be able to just do:

(or maybe chainloader +2 I'm not sure if it matters...).
Your OS X partition may need to be marked as active, not sure but I think "makeactive" doesnt work with grub2.
Also, as grub2 can read HFS+ this variant also should work:

Or if you have several renamed boot files in OS X's partition root you could also do this:

One more pointer: If you're familiar with GRUB, be aware that GRUB2 changes the way it refers to partitions. If a partition is (hd0,0) in GRUB, it will be (hd0,1) in GRUB2 -- the partition numbers are numbered starting from 0 in GRUB, but from 1 in GRUB2. Confusingly, a similar change does not apply to disk numbers!

thorazine74, you're a legend! =)))))

Two of your suggenstions worked. These two loads chameleon from my grub2 menu:



Huge thanks man! Of course I'd like to send big thanks to everybody else that helped out here too. =))

And just as a side note:



Both ends up at the screen with the: y-MORE-- text.

Thanks again! Guess next challange is to boot snow leo directly from GRUB2 then? Will try the tips you have posted here when I have a bit more time at my hands.

Cheers!

Hey everyone, I have a quick problem. The problem is quick, but I do not know if the solution will be or not!

I downloaded and did a fresh install of Karmic today and it works great. It gives me the option to boot to my Windows 7 install and my OS X 10.5.6 partition as well. However, when I had jaunty, I had chameleon as my boot loader and it worked great. But now chameleon does not see my karmic partition. First some background:

sda1 - unpartitioned (testing partition)
sda2 - Windows 7
sda3 - 10.5.6 XxX
EXTENDED Partition
sda5 - Karmic
sda6 - swap
sda7 - Documents partition (readable by all OS's for safe keeping of docs.)

now my normal install order is Windows, OSX, Linux. Once that is complete, I run the following commands in order to get chameleon to work:



This process worked great when I had Jaunty with Grub legacy. But now grub2 has gone and messed everything up! Can anyone enlighten me as to how complete this? Step 3 really seems to be what I need to focus on, however when I do that, I get some errors telling me that I shouldn't do it, and then I re-boot, and I see chameleon, but chameleon does not see Karmic!!! Frustrating! Anyway, thanks again in advance for any help.

Matt

Chameleon only shows partitions with a valid "Volume Boot Record", so you need to make sure about that, something like:

should show a hex dump of the VBR, an empty one like the following, means it will not be shown:

Most likely you installed Grub2 on the MBR when installing Karmic which is not something you should do.

At the end of the installation wizard right before you actually start copying files and stuff you need to hit the Advanced button and select to install bootloader only to /dev/sdaX where X is the Linux partition. /dev/sda means MBR and it's not what you want.
That's why Chameleon doesn't list the Linux partition because it doesn't contain a bootloader (it was installed to MBR).

Screenshot for better explanation:



It says (hd0) here, you should click the drop down box and select your Partition.

Hey guys, thanks for all of your help. I did the previous method first (in which I installed the bootloader to the partition during boot time). After which it was my intention to see kabyl's test, however when I rebooted after the install, it booted, I saw chameleon, and all my other partitions, except for my karmic one. Any other suggestions? Thanks again everyone.

Matt

Ok quick update. I booted to my live USB and ran kabyl's code. It unfortunately came up just as you showed it! Anyway to fix all of this?

I have exactly the same problem and I did install Grub to Linux partition, not the MBR.

/edit
Installed again, this time partitioned to ext4 and Linux shows up on boot disk list. On both times installed grub to sda2 but first time used ext3.

I started experimenting with direct boot of 10.6.1 from grub2 yesterday. I don't have a multi-boot setup yet. It booted to the grub> prompt. It would never find the kernel. I talked to the guys on the #grub irc channel today and they said native boot of 10.6 is not supported yet.

Any word on a fix? I have always done my formatting as ext4 and never got mine to show up on chameleon (with karmic that is). Are you saying that you got chameleon to show it?

Yes, Linux is shown on Chameleon and I can boot to it.

/edit
I just remembered that I am actually using PC EFI 10.5, not Chameleon RC3 anymore. Don't know if that makes any difference.

Interesting... Rod's first report talked about voodoo so you can assume it was leo but the other poster got snow's kernel running up to the panic point.

After a few days of trying different attempts, I am still having trouble making chameleon see my karmic partition. I have installed efi 10.5, and replaced the boot file and I kernel panic. I'm not quite sure where to go from here. I'm sure there is a solution for the problem, but nothing seems to be working. Is there something in Karmic that I should be doing? Thanks again guys.

matt

why do you guys assume GRUB2 can boot vanilla kernels?

Grub2 WIKI

For you guys having problems with Chameleon not showing Linux installation, this is how it works for me.
First, make sure you have a way to boot your installs if something goes wrong.. get Super Grub Disk, it will boot your Linux install if everything else fails. Also keep a pre-boot CD for OS X, you can make one with this app.. i'm mentioning a pre-boot CD because it's the only method i can trust atm.. use what ever works for you.
Tests i made were done using Ubuntu 9.10, selecting Grub to install to /.

First case.. GUID partitioned HD:
- the only problem here is that, Chameleon gets wiped out of MBR. yeah, even installing it to /.
Also, when configuring installation there's no mention of the "BIOS boot partition" creation.. i think that lead me to a second install, as the first one was not showing on Chameleon. I'm assuming Grub didn't got installed to the correct partition (or not installed at all) because of the creation of "BIOS boot partition" but, there's always the possibility i messed up can't be sure atm.
I removed this install because, this breaks all the nice things DiskUtility can do to GUID HD's like resizing, deleting, adding partitions. I only did it to test Grub.. i already knew this would break from previous tests. Don't know if it's the presence of another file system or the fact that these installations don't use the same layout as OS X installs (no 128MB unallocated space between partitions).

Second case.. MBR partitioned HD:
- no problems with MBR being wiped here and no "BIOS boot partition" creation. A lot of problems caused by Extended/Logical partitions.
The only way i got this to work was by setting up a Primary partition for Ubuntu, after XP/Windows 7 and installing Ubuntu without Swap partition. I did a install providing Swap partition (on Extended partition) and it did show on Chameleon but then, Ubuntu would take forever to boot.. and i do mean "forever", so much i didn't had the patience to wait I'm a patient guy so... If you get the blinking cursor, wait a couple of minutes, probably it's booting slow.(*)
Letting Ubuntu do the partitioning always leads to the use of Extended partition, even if i only leave XP partition.

After this tests, this is my HD layout:
- Note: HD's are not in the correct order.. OS X insists on doing that a lot lately, more than usual..


As you can see i have the Swap partition, added later to the Extended partition. The thing is, the Swap partition is not activated at startup.. a simple way to activate it is by using GParted after you boot into the system. Anyway, unless you have small RAM size or you need to do some "heavy lifting", most probably the system wont use the Swap.

As a sort of conclusion:
- doing this on GUID HD is much easier. Just install manually, Chameleon boot0 back to MBR and Grub2 to the partition if it doesn't show on Chameleon.
- if you really have to do it to MBR HD, follow my testing and keep in mind, this can work different on your machine. Installing Grub2 manually didn't help in the cases were it didn't show up on Chameleon. It always shows a "not good idea" msg when installing to partition, even when install is successful. In the cases were Ubuntu was installed to Logical partition, manual Grub2 installation was never successful.

As for the real theme of this thread, one thing is certain, Grub2 is not prepared to deal with Snow.. it's not that difficult to understand why, just look at the path for system mkext on grub.cfg entries (first post).
Atm choosing any OS X installation to boot sends me back to Grub2 prompt. I did some attempts while testing.. they all ended up in kp. Will have to test this with more time and reading.

Hope this helps..
See ya.

Edits:
- One less important thing i forgot to mention.. Ubuntu always insisted on creating a 5,8MB unallocated space before the / partition, except when i left only the first one, XP.

(*): This just happened again, after i installed some updates on Ubuntu (including a Proposed update for Grub), rebooted, tried to boot OS X and booted Ubuntu again. A new reboot and another one, were ok. But, no audio.. grrrr.. this already happened while testing and booting with Super Grub Disk. It seems it's not SGD's fault!

Unfortunately, the most common Linux GPT tools (GNU Parted and its GUI relatives) wipe out the boot loader from the MBR on GPT disks. I believe the logic is that EFI doesn't use this code, so it "should" be empty, and the partitioning tools make it so.



On a GPT disk, GRUB2 works best when a BIOS Boot Partition is present, since GRUB2 installs part of its code there. (This partition can be quite small -- 100KB is probably plenty big, although I'm not sure exactly how big it should be for GRUB2.) Without a BIOS Boot Partition, GRUB2 should still install and work, but it'll be more susceptible to failure if files get moved around on the boot partition.

I believe there's a way to create a BIOS Boot Partition in GNU Parted, but I don't recall the exact procedure. It's quite simple in GPT fdisk -- just create a partition and assign it a type code of ef02. (Note that GPT fdisk's type codes are unique to it; I used this scheme because the real GPT type codes are GUIDs, which are 16-byte numbers -- 21686148-6449-6E6F-744E-656564454649, in the case of the BIOS Boot Partition. Expecting users to type or remember such numbers is unreasonable.)



I don't know precisely what Apple's Disk Utility requires of GPT disks in order to support resizing, but the 128MB between partitions is certainly a possibility. Apple specifies this as something that should be done for its disks, although it's not part of the GPT specification. IIRC, Microsoft's tools also create such a gap between partitions, but neither GNU Parted nor GPT fdisk enforces such a rule. (You can still create such layouts, but you'll need to set the start and end points to add this gap.) Apple also recommends aligning partitions on 4KB boundaries, apparently because of HFS+ issues. AFAIK, no non-Apple tool enforces that rule, either.



On MBR disks, I think (but am not positive) that GRUB2 installs part of its boot loader in the unpartitioned space between the MBR (the first sector of the disk) and the start of the first partition, which is normally sector 63. This effectively serves the same role as the BIOS Boot Partition on GPT disks.



Most Linux distributions have taken to using simplified partitioning tools with few options as part of their install routines. IIRC, Fedora uses primary partitions exclusively unless you want more than three or four partitions, at which point it begins using logical partitions for the extras. I'm not intimately familiar with Ubuntu's installer, but it doesn't surprise me to hear that it does things differently, favoring logical partitions. FWIW, the lack of the primary/extended/logical partition distinctions is one of the big advantages of GPT over MBR.



Check your /etc/fstab file. In Linux, swap is defined there, in a line like this:



The device identifier (/dev/sda6 in this example) may be replaced by something taking another form, such as a UUID, to make the system less susceptible to device ID changes. In any event, if you don't see a line like this, you can add one. If you do see such a line, verify that the device identifier is correct.

Although a system with plenty of RAM might not need swap for most things, having it is helpful insurance in case of an unusual RAM demand. It's also used for deep sleep modes (most useful on notebooks and netbooks); Linux stores its RAM snapshot to swap for quick recovery when it wakes up.

[quote]- One less important thing i forgot to mention.. Ubuntu always insisted on creating a 5,8MB unallocated space before the / partition, except when i left only the first one, XP.[quote]

I suspect this is related to cylinder alignment code in GNU Parted, upon which Ubuntu's partitioning tool is probably based. In some GNU GNU Parted variants I've seen, there's a check box to enable or disable cylinder alignment. Turning it on produces gaps at the starts and ends of the disk; turning it off eliminates those gaps. This feature is useful for producing MBR disks that are less likely to cause problems in older OSes, but AFAIK it's completely useless for GPT disks.

Ok everyone, I have finally figured some things out and my system is up and running.

Originally I was trying to set up my system as so:

Sda1: testing blank partition
Sda2: Windows 7
Sda3: OSX
Sda4 - EXTENDED
Sda5: Karmic
Sda6: Swap
Sda7: Storage for docs

This setup worked great when I had Jaunty, but Karmic was giving me lots of trouble. After multiple installs and googling for hours, and thanks to some posts here, I quickly found out that Karmic does not like to be on an extended partition for some reason. So my thought process was simple. Swap OSX and the Karmic partitions. I did so, and I could never get OSX to boot off of the extended either. I am not sure why. However, since I hardly use the testing partition, I felt that it was in my best interest that I dump this and Keep it to three up front and swap and storage on the extended.

So I reformated and installed karmic and Os X, and restored an image of windows 7 I had to the 3 primary partitions up front on my drive.

During my Karmic install I made sure that I installed grub to that partition. The OSX install went normal as planned, and then I installed chameleon to that drive and the boot process works fine. Anyway, I hope this helps any of you that are running into the same issues that I have had. Thanks again for all of the help.

I understand that chameleon can only chain boot linux by loading a partitions boot sector with grub in it (post #17), so if grub2 cannot be installed just there in a GPT disk and it needs to be in mbr and bios boot partition, I think its imposible to make it work with chameleon at its current state.



You are surely right about grub2 not being able to deal with snow but I doubt the mkext location error would stop it, if I understand the grub code right, it will just load the kexts from /S/L/E when it doesnt find /S/L/Extensions.mkext. I changed the grub entry to this:

[code
xnu_kernel /mach_kernel boot-uuid=${uuid} rd=*uuid
if [ /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext -nt /System/Library/Extensions ]$
xnu_mkext /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext
else
xnu_kextdir /System/Library/Extensions
fi
}[/code]

and it didnt make any difference, the panic that appears seem to be related to boot arguments, the same one as reported above:



It seems to be traced to this file in the kernel source and this snipped of code:



I'm not a coder so I dont really understand whats going wrong, something related with memory remapping?

Can someone confirm if we need to load efiemu? I understand that IT IS NEEDED to boot Mac OS X kernels on non-EFI machines, the fact that osprober script that creates the built-in grub.cfg entry for OS X doesnt put it there it could be only because it is made for real macs which doesnt need it, but I'm not sure if the modules would get autoloaded when needed (i.e. if xnu_kernel finds out it cant load the kernel without efiemu, would it be loaded automatically or not?)

I tried to play with the efiemu commands but arrived no where :-(
These are the mods to grub.cfg I tried:


But it made no difference at all...
Maybe an updated grub2 package or compilation will fix it, I was just using the built-in Kubuntu 9.10 package.





I cant confirm this, I got Karmic installed to a logical partition with grub2 installed onto it, and it boots and works just fine from there, it shows up in pcefi 10.5, never tried to boot it from there though as I use BootIt NextGen to multiboot but I cant see why it would not work.