I have been a long time mac user who has always been frustrated with the lack of a good desktop so I built a hackintosh. I have 2 hard drives in my computer. One with OS X, the other has windows Vista 64 (for games only). I have been booting OS X using the chameleon boot-loader which lies on the same partition as OS X. I wanted to try Suse so I could give it a try and possibly leave Mac’s behind. I installed Suse on the Windows hard drive because I didn’t want to mess up OS X. I shrank the Windows partition. Created an extended partition and in the extended partition there are 3 volumes. One is for swap, one is for Suse and the last is for “home”. I read that in order for chameleon to detect windows, os x and Suse, i should install the grub boot-loader on the same volume as Suse. Then chameleon would allow me to choose which of the 3 os’s to boot. I chose to not install a boot-loader initially so i could add it later. Here is my problem:
In suse using yast I cannot install the boot-loader to sda5 (the volume with linux). I can select sda5 but after applying the changes and relaunching the utility, it tells me that Grub boots from sda2. So I changed the option to “do not install a boot-loader”. I restarted my computer trying to get into os x only to find that chameleon boot-loader won’t load anymore. I get grub instead. So now even though Linux doesn’t think grub is installed at all, it is on volume sdb somewhere and i have to figure out how to get it off. I can probably manage that. What I can’t manage is how I am supposed to get the grub boot loader installed in such a way that it doesn’t interfere with sdb or the windows partition on sda.
If you can help i would really appreciate it. If you need any clarification, please ask.
I think that your issue is related to booting from two different hard drives. Is that right? If so, then I think the simple explanation is that you need to …
Make the Linux/Windows drive the one that boots first (through your BIOS)
Install GRUB to the MBR of that drive
Configure GRUB to boot Linux, or Windows, or call the OS X bootloader on the other hard drive.
How you actually do that is a bit more complicated, but the instructions on my post should get you most of the way.
My PC now boots GRUB on the first drive which either boots Linux, or calls the Windows 7 bootloader on the other hard drive, which either boots Windows 7 or the XP bootloader, which then boots XP. Ridiculous, yes, but it means that even if I stuff up my OpenSuse installation I can always boot from my other hard drive.
If the machine is configured to boot from sdb with chameleon installed there, and you are now getting grub instead, it sounds like grub was installed to the sdb MBR. And so probably chameleon will need to be re-installed or re-configured (not ever having worked with it, I can say specifically).
Re openSUSE on sda: sda2 - which I assume to be the extended primary - is a valid location. Grub can be “chainloaded” from any partition boot sector. I don’t know why sda5 for overriden, but that should not change the result. When grub is written to a boot sector it has embedded in it a pointer to the partition where its menu.lst control file resides. Of course, the boot stanza in menu.lst will need to point to sda5 to find the kernel, so the notation there should probably be (hd1,4).
In short, I would re-install/repair chameleon as required, make sure sdb is the boot drive, and configure chameleon to chainload (that is the only method possible) grub from sda2.
sdb is a guid disk. So no master boot record there. Now to make matters worse, I had to make a new OS X usb drive to get back in and fix it. Unfortunately now when I try to boot my computer, it locks up before the ram is counted if I have my usb drive inserted. If I insert a different non-booting usb drive the computer boots fine. But obviously this doesn’t help me. Does anyone have any idea why a computer would lock up at the post screen before ram is counted just because of a usb drive being inserted?
fwiw . . . my understanding is that on a GUID disk the MBR is still present at the same location (the first sector) for backwards compatibility reasons; the installed EFI -in this case, Chameleon - of course includes its own boot loader and does not use this sector. AFAIK openSUSE uses the standard grub (as opposed to grub-efi or similar) and so for a GUID disk uses elilo instead. I’ve never tested this, but I would expect that the partition table in the MBR would be marked as type 0xEE and hence disallowed for write by Linux. The relevance of this is that, if you are seeing grub at boot, that suggests that the machine is booting from sda not sdb. A reason openSUSE would have forced sda2 to be used instead of sda5 is to allow for the code in sdb’s MBR to remain intact, i.e., that code will go to the boot sector of the active primary (the code cannot read down the logical partition chain, it can only read the MBR’s table). On a standard BIOS machine, if the firmware does not find an executable in the defined boot disk’s MBR, typically it will try the next disk (whether defined as such or just reading down the controller chain). This suggests that somehow the Chameleon EFI is borked and consequently control is falling to sda.
As far as why POST would fail before initializing RAM when a bootable USB device is attached, I’m sorry but I have no idea. AFAIK this cannot happen with standard BIOS as the firmware must initialize the CPU and memory before it can do anything else. What is not all that uncommon is a BIOS locking up when trying to read or transfer control to an external device defined for boot (if the device has a valid boot sector, the problem is usually in the BIOS) - but that of course follows POST. And how that factors in when using EFI, again I have no experience with that.
Thanks for your help. Remade my USB drive containing os x that I use to fix os x on my hard drive and it works now for whatever reason.
Also in case anyone else wanting to boot Linux from chameleon reads this:
I am now able to boot windows, os x, and Linux all from chameleon. Chameleon recognized all three without any extra work. It even has a penguin icon for Linux. The trick was to install Linux on it’s own partition and not an extended partition. Grub is installed to the root partition of Linux.
A small point of clarification for the reader in ref to:
The trick was to install Linux on it’s own partition and not an extended partition.
I take this to mean that the Linux root needs to be in its own “primary” partition rather than a “logical” within an “extended primary”. Additionally, I would expect this to also work with /boot being separated from root onto its own primary partition (which is sometimes desirable/necessary for other reasons).