Bug 398459 – sys-boot/grub:2 Guide needs Variant C: Installing on a PC with BIOS and a GPT-Partitioned Disk

• Product: Documentation
• Status: RESOLVED OBSOLETE

[Description Duncan 2012-01-11 02:23:24 UTC]

This is about the in-progress Grub 2 Guide presently found at the URL link (to scarabeus' devspace: http://dev.gentoo.org/~scarabeus/grub-2-guide.xml ) and as mentioned in the grub:2 ebuilds.  I was unsure whether to mail him directly or file the bug, but gentoo policy seems to prefer bug filing, so here it is.  As mentioned in bug #398451 as just filed, I'm investigating an upgrade to grub2...

The guide as presently written has two variants:

Variant A: Installing on a PC with BIOS and a MBR-Partitioned Disk

Variant B: Installing GRUB 2 on Hardware That Supports EFI


But, I'm on a BIOS PC that has been upgraded to GPT-partitions using  sys-apps/gptfdisk, grub1 (grub-static-0.97-r10, which includes gpt-support patches), and the relevant kernel config:

# CONFIG_EFI is not set
CONFIG_EFI_PARTITION=y

That doesn't fit A since it's not MBR partitioned but rather GPT, and doesn't fit B since it's BIOS, not EFI.  So either there's a Variant C needed, or one of the other two needs reworded to include GPT partitioned disks on BIOS-based systems.

At this point I suspect I should be doing the grub2-install thing regardless of gpt instead of mbr partitioning, thus suggesting a reword of Variant A to include this situation, but I'm not yet /sure/ that's correct.

Meanwhile, thanks for the guide-in-progress.  It's possible I'll have further suggestions/bugs regarding either it or the grub packages in gentoo, as I further research and eventually carry thru on the upgrade.

[Comment 1 Petr Kočmíd 2012-01-11 09:34:21 UTC]

I confirm scarabeus's documentation is dangerously incomplete.

In case of using GPT with older, non-EFI BIOS, grub2 requires a special tiny "BIOS boot" partition type at the beginning, where an initial grub's boot code resides. The reason is, on GPT scheme there is not enough reserved room to put this code into like on MBR scheme.
Note that this is NOT a /boot partition, its code is EF02, while linux filesystem are 8300!
This "BIOS boot" partition is not needed for EFI-enabled boards.

Here an example of such GPT scheme on a large drive with bios boot, /boot and /:

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            4095   1024.0 KiB  EF02  BIOS boot partition
   2            4096        33558527   16.0 GiB    8300  Linux filesystem
   3        33558528      1465149134   682.6 GiB   8300  Linux filesystem

Another issue with grub2 gentoo doc is, root=UUID= does not work correctly with single/multiple snapshoted btrfs roots (parhaps grub2 upstream bug?), which renders that automatism mentioned in scarabeus's document completely unusable. I am just mentioning this here for I don't feel it's worth a (potentially WONTFIX) bug report, since gentoo does not support btrfs anywhere in the docs yet.

[Comment 2 Jeroen Roovers (RETIRED) 2012-01-11 17:18:58 UTC]

(In reply to comment #1)
> I confirm scarabeus's documentation is dangerously incomplete.

It isn't official either, but let's have the man himself in the loop on this.

[Comment 3 SpanKY 2012-01-13 06:05:22 UTC]

"dangerous" is a bit melodramatic.  if you're mucking with grub2, a level of debugging is already implied.

[Comment 4 Duncan 2012-01-13 08:05:36 UTC]

(In reply to comment #1)
> I confirm scarabeus's documentation is dangerously incomplete.

As with the others, IMO that's going a bit overboard, as it has that disclaimer
in a square box right at the top and the entire grub:2 slot remains hard-masked
until the documentation is agreed to be appropriate.

"Work in progress" is, however, an entirely accurate description, and my
purpose here is simply to aid in that progress. =:^)

> In case of using GPT with older, non-EFI BIOS, grub2 requires a special tiny
> "BIOS boot" partition type at the beginning, where an initial grub's boot code
> resides. The reason is, on GPT scheme there is not enough reserved room to put
> this code into like on MBR scheme.  Note that this is NOT a /boot partition, its
> code is EF02,

Thanks for the clarifying memory nudge!  I had read all about that at the
rodsbooks/gptfdisk site back when I switched to gpt, but that was still in the
context of gentoo's grub1 (which is patched to support gpt), and while I knew
grub2 was supposed to be gpt aware and make use of either that or the EFI
system partition, I wasn't at all sure how all the pieces fit together, yet, and
was confused to the point I really didn't even know which end was up!  Your
comment turned out to be just the orientation hint I needed, and with it,
everything else started falling into place as well!

> Another issue with grub2 gentoo doc is, root=UUID= does not work correctly with
> single/multiple snapshoted btrfs roots (parhaps grub2 upstream bug?), which
> renders that automatism mentioned in scarabeus's document completely unusable.
> I am just mentioning this here for I don't feel it's worth a (potentially
> WONTFIX) bug report, since gentoo does not support btrfs anywhere in the docs
> yet.

Based on what I've read, it is indeed an upstream bug, or at least it still was with
1.98.  I read that it's fixed, at the time of the comment, fixed in trunk, but I'm not
sure if that comment was made before or after 1.99's release, so I don't know
whether the fix is in 1.99 or not.

So if you're still seeing it with 1.99, try the -9999 live-build and see if it's fixed there.
AFAIK it should be based on what I read, but I'm not (yet) on btrfs either, still on
reiserfs at this point, pending another btrfs on-disk-format-change (possibly the last)
that was targeted at kernel 3.3, last I read.

Meanwhile, I'm having an issue with grub.d/10_linux (because my kernels aren't
in /boot itself but in /boot/amd64 and /boot/x86) and am having to edit it to
make the detection work.  I guess I'll be using CONFIG_PROTECT for that file.
(I thought about making it an 11_linux_subdirs or some such, but then I'd not
get the benefit of CONFIG_PROTECT conflict notification and handling if they
update the script.)

Editing that, I do see where btrfs is getting special root processing treatment,
the big reason I suspect it might have fixed the bug.  But as I don't yet run
btrfs (still reiserfs here, tho I'm getting antsy and may finally upgrade with
3.3, which last I read was bringing another btrfs on-disk-format change)
I don't really understand what's going on there and whether that's the fix
or is still buggy.  But if you're reasonable with shell scripting and reasonably
confident you understand btrfs as well, look at the if/then beginning on line
54 (again, in the 1.99 version of 10_linux) or do a search on xbtrfs while
editing that file, and you should see what it's doing and possibly be able to
edit it as appropriate, much as I am the uname -m case branching
starting on line 134, to handle the kernels-in-subdirs setup I have.

But of course I'm not sure whether that's the only place they need that fix.
You could just try the -9999 live-build and see... or find the patch committed
upstream and backport it to 1.99, if desired.

Heh, maybe I just returned the favor you did me. =:^)

[Comment 5 Andreas Sturmlechner 2012-10-15 06:12:09 UTC]

I must say I was surprised at how easy it was to get grub-2 up and running on my new BIOS/GPT setup, given how complex it looked at the beginning. First shot, success.

I mostly had a look in here, which was an excellent resource: http://wiki.gentoo.org/wiki/GRUB2#Configuration

[Comment 6 Duncan 2014-05-05 06:15:09 UTC]

Closing as resolved/obsolete.  As comment #5 indicates, the gentoo wiki grub2 page covers gpt/bios, and the ~scarabeus link is now quite dead, so...