GRUB2 as the only boot loader: it's possible!

[srs5694]

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:

 

menuentry "openSUSE 11.0 - 2.6.25.20-0.5" {
set root=(hd0,3)
linux /boot/vmlinuz-2.6.25.20-0.5-default root=/dev/sda3 showopts
initrd /boot/initrd-2.6.25.20-0.5-default
}

menuentry "Windows 7 RC" {
set root=(hd0,7)
chainloader +1
}

menuentry "Mac OS X" {
set root=(hd0,6)
insmod video
insmod vbe
gfxmode="1280x800x32"
xnu_kernel /mach_kernel rd=disk0s6
if [ /System/Library/Extensions.mkext -nt /System/Library/Extensions ]; then
   xnu_mkext /System/Library/Extensions.mkext
else
   xnu_kextdir /System/Library/Extensions
fi
}

 

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.

[thorazine74]

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.

[srs5694]

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.

[NEO_AMiGA]

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:

 

menuentry "Mac OS X (on /dev/sda2)" {
	 insmod hfsplus
	 set root=(hd0,2)
	 search --no-floppy --fs-uuid --set a0297dea90ce0b44
	 insmod vbe
	 do_resume=0
	 if [ /var/vm/sleepimage -nt10 / ]; then
		if xnu_resume /var/vm/sleepimage; then
		  do_resume=1
		fi
	 fi
	 if [ $do_resume == 0 ]; then
		xnu_uuid a0297dea90ce0b44 uuid
		if [ -f /Extra/DSDT.aml ]; then
		   acpi -e /Extra/DSDT.aml
		fi
		xnu_kernel /mach_kernel boot-uuid=${uuid} rd=*uuid
		if [ /System/Library/Extensions.mkext -nt /System/Library/Extensions ]$
		   xnu_mkext /System/Library/Extensions.mkext
		else
		   xnu_kextdir /System/Library/Extensions
		fi
		if [ -f /Extra/Extensions.mkext ]; then
		   xnu_mkext /Extra/Extensions.mkext
		fi
		if [ -d /Extra/Extensions ]; then
		   xnu_kextdir /Extra/Extensions
		fi
		if [ -f /Extra/devtree.txt ]; then
		   xnu_devtree /Extra/devtree.txt
		fi
		if [ -f /Extra/splash.jpg ]; then
		   insmod jpeg
		   xnu_splash /Extra/splash.jpg
		fi
		 if [ -f /Extra/splash.png ]; then
		   insmod png
		   xnu_splash /Extra/splash.png
		fi
		if [ -f /Extra/splash.tga ]; then
		   insmod tga
		   xnu_splash /Extra/splash.tga
		fi
	 fi
}

 

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

 

panic(cpu 0 caller 0x2ac8d5): "Incompatible boot args version 1 revision 4\n"0/SourceCaches/xnu/xnu-1456.1.25/osfmk/i386/AT386/nodul_dmp.c:542

 

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'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:

 

menuentry "openSUSE 11.0 - 2.6.25.20-0.5" {
   set root=(hd0,3)
   linux /boot/vmlinuz-2.6.25.20-0.5-default root=/dev/sda3 showopts
   initrd /boot/initrd-2.6.25.20-0.5-default
  }

  menuentry "Windows 7 RC" {
   set root=(hd0,7)
   chainloader +1
  }

  menuentry "Mac OS X" {
   set root=(hd0,6)
   insmod video
   insmod vbe
   gfxmode="1280x800x32"
   xnu_kernel /mach_kernel rd=disk0s6
   if [ /System/Library/Extensions.mkext -nt /System/Library/Extensions ]; then
	  xnu_mkext /System/Library/Extensions.mkext
   else
	  xnu_kextdir /System/Library/Extensions
   fi
  }

 

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.

[DB1]

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

 

panic(cpu 0 caller 0x2ac8d5): "Incompatible boot args version 1 revision 4\n"0/SourceCaches/xnu/xnu-1456.1.25/osfmk/i386/AT386/nodul_dmp.c:542

 

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.

[thorazine74]

xnu_uuid a0297dea90ce0b44 uuid

 

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

2FF02147-61EF-3EA2-A314-FFA7FD42BC28

 

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:

uuid=2FF02147-61EF-3EA2-A314-FFA7FD42BC28
xnu_kernel /mach_kernel boot-uuid=${uuid} rd=*uuid

 

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.

[DB1]

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

2FF02147-61EF-3EA2-A314-FFA7FD42BC28

 

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:

uuid=2FF02147-61EF-3EA2-A314-FFA7FD42BC28
xnu_kernel /mach_kernel boot-uuid=${uuid} rd=*uuid

 

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.

[thorazine74]

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...

[srs5694]

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:

 

menuentry "MacOS X PATA via Chameleon 1.0.12" {
	set root=(hd0,2)
	chainloader (hd0,1)/boot/chameleon.mbr +1
}

 

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.

[Kabyl]

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:

 

menuentry "MacOS X PATA via Chameleon 1.0.12" {
	 set root=(hd0,2)
	 chainloader (hd0,1)/boot/chameleon.mbr +1
}

 

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

[NEO_AMiGA]

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:

 

menuentry "MacOS X, chameleon" {
	set root=(hd0,2)
	chainloader (hd0,6)/boot/chameleon.mbr +1
}

 

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--

[thorazine74]

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.

 

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.

 

 

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:

 

menuentry "MacOS X, chameleon" {
	set root=(hd0,2)
	chainloader (hd0,6)/boot/chameleon.mbr +1
}

 

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--

 

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

menuentry "MacOS X, chameleon" {
	set root=(hd0,2)
	chainloader  +1
}

(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:

menuentry "MacOS X, chameleon" {
	insmod hfsplus
	set root=(hd0,2)
	multiboot /boot
}

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

menuentry "MacOS X, chameleon" {
	insmod hfsplus
	search --file --set=root /chameleon.rc3.boot
	multiboot /chameleon.rc3.boot
}

[srs5694]

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!

[NEO_AMiGA]

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

 

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

 

menuentry "MacOS X, chameleon, multi" {
	 insmod hfsplus
	 set root=(hd0,2)
	 multiboot /boot
}

menuentry "MacOS X, chameleon" {
	 insmod hfsplus
	 search --file --set=root /boot
	 multiboot /boot
}

 

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:

 

menuentry "MacOS X, chameleon +1" {
	 set root=(hd0,2)
	 chainloader  +1
}

menuentry "MacOS X, chameleon +2" {
	 set root=(hd0,2)
	 chainloader  +2
}

 

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!

 

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:

menuentry "MacOS X, chameleon" {
	  set root=(hd0,2)
	  chainloader  +1
 }

(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:

menuentry "MacOS X, chameleon" {
	  insmod hfsplus
	  set root=(hd0,2)
	  multiboot /boot
 }

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

menuentry "MacOS X, chameleon" {
	  insmod hfsplus
	  search --file --set=root /chameleon.rc3.boot
	  multiboot /chameleon.rc3.boot
 }

[kr4zyc1d]

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:

 

1.install chameleon/ darwin loader (installs new(est) version of loader on the disk)
2.boot back into linux
2.use gparted to make the OSX partiton active, unflag the linux partiton (darwin loader will be called now)
3.grub-install /dev/"linux-install-partition"  (installs the grub loader to the linux partition)
5.boot back to OSX
6.fdisk -u -f /usr/standalone/i386/boot0 /dev/disk0 (replaces the previous mbr install of grub with the darwin loader)

 

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

[Kabyl]

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

sudo hexdump -C -n 512 /dev/<linux partition>

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

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

[saivert]

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.

[kr4zyc1d]

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?

[mm67]

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.

[ukchucktown]

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.

[kr4zyc1d]

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.

 

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?

[mm67]

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.

[thorazine74]

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.

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.

[kr4zyc1d]

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

[saivert]

why do you guys assume GRUB2 can boot vanilla kernels?