|Summary:||sys-boot/grub:2 Guide needs Variant C: Installing on a PC with BIOS and a GPT-Partitioned Disk|
|Component:||Project-specific documentation||Assignee:||AMD64 Project <amd64>|
|Package list:||Runtime testing required:||---|
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