Grub in non MBR partition

[smr54]

I've only run into this on one machine, a Sandy Bridge UX31E laptop. If I install Fedora after installing something else, and put grub2 into the root partition (/dev/sda2 in this case) rather than the MBR, it won't work. It will only show the word GRUB, a flashing cursor, and shortly afterwards, usually reboot.

I then tried changing Ubuntu's grub menu to use vmlinuz and initrd of the Fedora install. It would boot with a kernel panic and have to be manually shut down. Interestingly, if I ran os-probe on Ubuntu, it wouldn't see the Fedora installation.

So, I then put Fedora's grub into the MBR, and everything worked. It saw two other installations, though it missed a third, which is fine, I prefer to turn off os probing and use custom config.

I've seen no other mention of this, so don't know if it's Sandy Bridge, some update to grub that broke it (which seems likely, as I didn't have this problem with F16, same circumstance, or even the earlier TC1 of F17).

It may be one of those aggravating Just Me issues, but I've been able to replicate it with a few installs.

[sonoran]

I installed Fedora 17's grub2 under /, not to the mbr, and boot it from Arch's legacy grub with
title Fedora 17
root (hd1,5)
chainloader +1

When F17 boots it starts at the grub2 menu, which shows my other systems. This is an AMD/nvidia desktop mobo.

[smr54]

Thanks. That's what I was expecting, and getting as late as TC1. It's only in RC1 where I'm getting this issue.

[srs5694]

These days, when diagnosing boot issues, it's absolutely critical that you know whether you're booting in BIOS mode or in EFI mode. Most Sandy Bridge motherboards ship with EFI firmware that includes a BIOS compatibility mode (often called "CSM"), so your board, smr54, could be booting in either way, or perhaps even in one way for one installation and in another way for another one. This mix can cause no end of confusion if you don't recognize what's happening.

Once you've booted in Linux, you can tell which way you're booted in a couple of ways. The simplest is to check for the presence of the /sys/firmware/efi directory. If it's present, you're booted in EFI mode. If not, you're probably booted in BIOS mode. Another way is to type "dmesg | grep EFI." If you get dozens of lines of output relating to EFI, then you're booted in EFI mode. If you get no output, or perhaps just a line or two, then you're probably booted in BIOS mode.

In theory, managing boot loaders on an EFI boot is simpler than doing the same with BIOS, although the methods are entirely different and so you'll suffer a learning curve if you already understand BIOS boot loaders. In practice, unfortunately, many EFI implementations provide poor user controls, and many Linux distributions still aren't handling EFI as well as they should, so working with EFI isn't always as easy as it should be. If you care to learn more, I've got a Web page on the topic. (http://www.rodsbooks.com/efi-bootloaders/) I've also forked an older EFI boot manager and am actively improving it, under the name rEFInd. (http://www.rodsbooks.com/refind/) Of course, none of this is relevant if you're booting in BIOS mode, unless you've got an EFI-capable board and you want to switch to EFI booting.

[smr54]

Thanks Rod. I've taken a quick glance at your pages and think they'll prove useful.

At this point, if I put Fedora's Grub in MBR, it's handling the other systems on there without problem, so, for the moment at least, I'll leave it at that.

[sonoran]

Thanks for the link to your page. My curiosity was aroused by this EFI_STUB thread: https://bbs.archlinux.org/viewtopic.php?id=136833&p=1

As in nature, evolution in computer science apparently produces dead-ends occasionally (thinking of you, grub2).:D

[smr54]

Y'know, I find myself constantly criticizing the theoretical improvements--then, in fairness, have to realize that I _like_ not having to know my monitor's specifications, worrying about destroying it, and having a wireless card work--often more easily than it does in Windows.

On the other hand, some of the design decisions made by various programmers, that get accepted as mainstream, surprise me. I'll leave it at that, but will just say that, as happens quite frequently, I agree with sonoran. (Scrolls up to make sure that I've also said thanks for the link to the page, sees that I have.)

[quackers]

I installed F17 yesterday but left Ubuntu's grub in the MBR and when I update-grub in Ubuntu it does not detect F17 at all.
I installed Fedora's grub to the MBR and that detects and boots all installed systems.
No EFI here.

[smr54]

Ok, similar to my experience. (I also looked and see that UEFI is disabled in BIOS)

Thanks for the feedback.

[quackers]

No problem. It's an odd one.

[srs5694]

I installed F17 yesterday but left Ubuntu's grub in the MBR and when I update-grub in Ubuntu it does not detect F17 at all.
I installed Fedora's grub to the MBR and that detects and boots all installed systems.
No EFI here.

One of the problems with GRUB 2 is that it relies on pretty sophisticated scripts to probe for various OSes and Linux distributions. (On the Gentoo system on which I'm typing this right now, the standard scripts in /etc/grub.d come to over 1,000 lines.) There's nothing inherently wrong with "sophisticated," but the fact that so much code is required to properly detect an OS is an indication of the complexity of the task, and hence the ease with which that detection can go wrong. It's really not surprising to me that an older distribution's GRUB scripts (Ubuntu 11.10, for instance) fails to detect a newer distribution (Fedora 17 pre-release, in this case).

This is one of the areas where EFI could eventually make things much easier. With boot loaders stored in standard locations and (according to the spec) registered with the EFI, creating a boot menu for all the options is relatively straightforward. The Linux kernel developers are implementing tools to let the kernel boot directly as an EFI application, which eliminates the need for GRUB. At the moment, there's still the problem of passing kernel options to the kernel, but apparently the plan is to put those in a configuration file. In the meantime, my rEFInd (http://www.rodsbooks.com/refind/) can glue it together. So the problem at the moment is that distributions don't yet support the kernel's EFI stub loader or rEFInd. Once the kernel's EFI stub loader support matures and distributions begin using it (perhaps with rEFInd or something similar to provide a consistent boot menu), problems with detection of other distributions or OSes will diminish greatly. Of course, this is all a theoretical future benefit of EFI. Current BIOS-based computers will still be stuck with either GRUB 2's "kitchen sink" approach or the need for manual configuration with LILO or GRUB Legacy.

[quackers]

Hi Rod, nice to see you again :-)

I sorted the problem out.

I needed to mount the Fedora partition in Ubuntu first, then Ubuntu's grub picked it up.