grub2 detects Mac OSX on sdb, but doesn't install it to grub.cfg?
 

Working on a quad boot system. Two Karmic installs (I find I tend to hork one every once in a while by playing too much, so having a backup around is nice), windows 7, and Snow Leopard.

I got everything up and running, except I had Leopard installed instead of snow leopard. At that time, I had the following:
sda1->win 7
sda2->leopard
sda5->karmic 1
sda6->karmic 2
(others for swap / extended / etc)

Grub2 detected everything just fine, made a real nice grub.cfg file and away I went.

Now, I've made a change. Snow Leopard required GUID partitions and I had my stuff all set up as MBR and was /not/ about to reformat and start over.

So I added a second drive, sdb.

Now, I can boot to that drive independently. Fine.

I can boot to sda just fine and go to either Ubuntu install or windows just fine. Great.

Grub2 finds Mac OSX on /dev/sdb2. Awesome (sdb1 is a fat32 bootloader for hackintosh reasons).

It not only doesn't update grub.cfg, it leaves the old /dev/sda2 listing for my old Leopard install ... whose partition I deleted. It isn't visible anymore.

But nothing after Ubuntu 9.10 on /dev/sda6 shows up in grub.cfg? I'm at a loss. Any ideas how to get it to populate? I'd rather not hack grub.cfg and have to rebuild it by hand every once in a while especially as grub was fine with finding it.

I also now tried having grub recreate the grub.cfg file and it didn't do anything. This seems curious as well.

I moved grub.cfg to grub.old and ran update-grub. Same output as above, but no file was created. So, ok, I ran grub-mkconfig and piped that to a file, but still, while it detected the OSX partition on sdb, it didn't add anything to the file.

So I guess there's two problems I'm having ... grub is not updating the grub.cfg file /and/ it's not adding the /new/ OSX partition that it finds.

You are tunning them with sudo I trust. You don't want to be updating grub.cfg - add a personal member under /etc/grub.d/
Have a read of this.

Yeah, I've read through that thread and I've also tried adding a 35_mac there in /etc/grub.d/, which never got into the grub.cfg ... it didn't show up in after update-grub and it didn't appear in the grub-mkconfig (and yes, it was 755 ... even tried 777). The only way (lately) I've seen any kind of change to grub.cfg is if I edit it by hand, which I know /should/ get blown away during updates, but nothing appears to be able to update it!

Disclaimer: I know nothing about Mac or Win (well, not since '98).

grub2 doesn't seem to be writing the file grub.cfg properly.

I am still getting to grips with grub2 but which of your installations is handling grub2 ?
Unlikely mac and certainly not win, but either karmic1 or karmic2. But which one is it? As I understand it, they can't both be "in charge" of grub2. Otherwise, as both K1 and K2 will have a /boot/grub/grub.cfg file, which grub.cfg file is grub2 meant to be reading / updating?

I suspect the version (K1 or K2) you are currently running is not the one grub2 thinks is "daddy".
You don't say if either K1 or K2 is "broken", if neither, boot to the other one and do an update-grub.

If one of your Karmics is broken, boot to the one that works, and do a reinstall of grub from that one.

Worth a try. Let us know how you get on.

if you want to be sure....boot into each K

use root powers to manually edit each /boot/grub/grub.cfg

add one line at end.....do NOT run update-grub.....this is just a test for you to know which one is loading
Yes you can boot up either and redo grub2 into mbr as well

the line to append in sda5 is

menuentry " this is sda5 k1"

the line to append in sda6 is

menuentry " this is sda6 k2"


on reboot you see hopefully either k1 or k2....then boot into k1 and update-grub or boot into k2 depending on which one you saw pls

Right, so I /do/ know "K1" is handling my grub files. Certainly they both have the /capability/, but I've tried adding lines to the K1 grub.cfg (to try and get the Mac OSX to boot) and I'll see the menu entries just fine.

I didn't think to look in the /other/ Karmic's grub.cfg to see if it's being updated ... if so, that would seem pretty strange since it isn't even mounted ... but I can go check, for sure.

Edit: Just checked, and no ... neither grub file is being overwritten.

I mounted "K2" in /media and edited K1 to have "# ... test1" in the header .. test2 for K2.

Then I did a find for grub.cfg and found ONLY the two examples and the two grubs:
So after that, I did a "sudo update-grub" and then verified that both still included the headers I'd just manually added to them.

So no ... update-grub is not updating anything at all as far as I can tell.

In fact, the several menu entries I added trying to get OSX to boot from there are still in there. I noticed it wasn't updating when I deleted OSX from sda2 and reinstalled to sdb2 (for GUID partition reasons and snow leopard requirements). Only the right version every got detected, but the old "sda2" was always still there. No idea why.

Edit 2: And just to check the other scenario, I booted into K2 (my backup that I don't use, generally) and executed an update-grub there as well. Same results. Neither .cfg got updated.

This is all exceptionally weird as grub was working fine all along during the initial installations.

I suppose the "big change" I made was to add a second hard drive and install OSX on it using GUID partition schemes. I could (perhaps) unplug that hard drive and see if it makes any difference, but why it would, I have no idea.

You need to know that if any of the executable scripts in /etc/grub.d/ have a trailing space at the end of a line, then grub2 will fall over and die without updating grub.cfg, and without giving any error message. I know, stupid, but true.

So check all those files very carefully, then try again.

A good thought, and something I certainly didn't know, but that's not it. I have no custom scripts in there and I checked all the default ones. No dice.

create/append to /etc/grub.d/40_custom script to chainload mac pls.

I don't have a mac so not sure if you need to have a line before the chainloader to ....insmod (modulename)

http://www.tuxation.com/linux-on-mac.html

it looks like you may need some modules....YMMV



then run update-grub.....in K1.

menuentry "second partition"{
insmod hfs
insmod efiemenu
insmod part_apple
insmod part_gpt
set root=(hd0,2)
chainloader +1
}

I don't think it hurts to have more modules loaded than necessary but try above?

2) if you are happy its K1 that is your grub2....and update-grub is not changing your grub.cfg then append new menuentry to your grub.cfg with root powers and reboot to test pls

Ok ... I'm missing a few things and need to clear up at least one thing:

I don't have a mac either. I have OSX installed on my PC. The drives are set up as follows:
_SDA_ (MBR partitioned)
sda1: Win7
sda2: deleted (this used to be a Leopard HFS partition)
sda3: Extended partition
---sda5: K1
---sda6: K2
---sda7: linux swap
sda4: Fat32 data sharing partition

_SDB_ (GUID partitioned)
sdb1: FAT32 Chameleon bootloader
sdb2: HFS+ Mac OSX 10.6 (Snow Leopard)
sdb3: Fat32 data sharing partition

I had to do it this way because Snow Leopard /does/ require GUID partitioning and I didn't really feel like reinstalling windows and two ubuntus with all their settings just to get Mac working ... so I just added a second hard drive.

Currently, I can boot to OSX by telling my bios that SDB is my primary bootable hard drive and going through chameleon. I then change that back to SDA in the bios and am able to boot through grub like normal into windows or ubuntu.

That brings us to today. My hope was to use Grub to boot everything ... I'm not certain I can mod Chameleon as easily as grub to make it boot windows and ubuntu. That's my fallback plan.

Grub itself still isn't updating.

So I tried your menu configuration and wasn't able to load it. Got a "file missing". I found out that was the insmod efiemenu. I tried googling it and thought maybe you meant "efi_menu" or some variation? I couldn't get any variation to work, however, and if I simply removed it, I got just a blinking cursor :(.

An alternative I hadn't considered until now is to perhaps simply point to sdb(0,1) somehow and let chameleon load OSX from there (it has a timeout just like grub, so it'd be a couple seconds wasted on boot, but might be easier?).

I tried a few variations on that theme, but sdb(0,1) simply doesn't show up as a bootable device as far as grub seems concerned.

Maybe I can point simply to sdb somehow?

Do you mean a chainloader?

Right, so I tried a menuentry that basically just said:
and just got the "not a bootable partition" or some such error message. Am I using it wrong? Maybe I need to declare the uuid or call out something else so it knows it's a guid partition?

Or alternately, I was suggesting if there's just a way to say something like:

set root = hd1

And boot that way.

?

An update!

So I think I've found a train to begin following. I unplugged the second hard drive (with the GUID partitioning and OSX on it), ran update-grub, and voila! Grub updated just fine (of course, minus the OSX part).

So I'm wondering if the GUID partitioning scheme is breaking grub somewhere. It detects OSX on sdb and then must be erroring out. That's why it doesn't update and why grub-mkconfig doesn't have anything after "Mac OSX detected on /dev/sdb".

So what causes grub to error out on a GUID partition?

hi thanks for the updates

my bad spelling efiemu

where grub is on first mbr according to bios

menuentry "second mbr"{
insmod efiemu
insmod hfs
insmod part_apple
insmod part_gpt
set root=(hd1)
chainloader +1
}

I still don't have a snowie either...I still think loading extra modules does no harm

hfs is a must....assuming that is your format.....guid I think is handled by gpt.....efiemu is what I got from the prev link...check the spelling by looking at /boot/grub stuff pls

good luck