[gentoo-dev] Re: grub:2 keywords

[Duncan]

Richard Yao posted on Fri, 29 Jun 2012 17:10:31 -0400 as excerpted:

> On 06/29/2012 05:04 PM, Mike Gilbert wrote:
>> On Fri, Jun 29, 2012 at 4:56 PM, Richard Yao <ryao@g.o> wrote:
>>> On 06/29/2012 03:04 PM, Mike Gilbert wrote:
>>>> On Fri, Jun 29, 2012 at 3:00 PM, Rich Freeman <rich0@g.o>
>>>> wrote:
>>>>> On Fri, Jun 29, 2012 at 2:51 PM, Richard Yao <ryao@g.o>
>>>>> wrote:
>>>>>> GRUB2 does away with the conventional stage files. It also wants a
>>>>>> special BIOS Boot Partition in order to function. That is where it
>>>>>> stores the equivalent of the stage2 bootcode.

>>>>> Now, that should make for a fun migration!  Fortunately I do have a
>>>>> separate boot already, and I guess I can be daring and overwrite it
>>>>> in place and trust in grub2 to still find the kernel elsewhere.
>>>>>
>>>>> Those without a separate boot and without any free space are likely
>>>>> to find this to be painful.  Resizing partitions isn't exactly
>>>>> risk-free...

>>>> I think Richard is incorrect here; grub2 can live on any filesystem,
>>>> so long as some combination of modules can access it.

>>> Do you know what function the BIOS Boot Partion serves? It is
>>> necessary when using GRUB2's ZFS support. I was under the impression
>>> that it stored boot code.

>> Based on a Google search I think "BIOS Boot Partition" is a GPT thing.
>> Not relevent if you have an MBR partition table.

> This is correct. I had forgotten that I switched to GPT

Some brief detail to de-fuzz things slightly...

1) Existing MBR installations function much like grub1 in terms of where 
the core, which replaces stage-1.5, goes.  Like grub1, one of two 
requirements must be met:

1a) Preferable: Some slack-space between the MBR and the first 
partition.  If this exists, grub2's core gets placed here, with the MBR 
using an absolute address to it, much like grub1 did with its stage-1.5s 
except that grub2's core is assembled from individual modules at install 
time and is thus able to handle anything it has modules for (as long as 
there's slack-space enough for the stack of necessary modules), including 
mdraid, lvm2, etc.

1b) Fallback: If no slack-space exists between the MBR and the first 
partition or if it's not enough, grub2 can install its core, much as 
grub1 could install its stage-1.5s, into /boot.  The disadvantage in both 
cases is that again it's accessed via absolute-address from the mbr, and 
if the filesystem moves it around, as journaling and COW-based 
filesystems sometimes do, the data can move out from under that absolute 
address, breaking the boot before even grub's rescue shell is available.  
Thus, this is STRONGLY DISCOURAGED, but it's an option for those on old 
systems, and it generally works as long as you're using an older /boot 
filesystem like fat or ext2 that's not going to move the data around.

(1c: As with grub1 it's also possible to install grub to a partition 
instead of to the entire disk.  However, this is much more strongly 
discouraged with grub2 than it was with grub1, I believe for much the 
same reasons as with 1b.)

2) BIOS-based GPT, with a dedicated BIOS partition (typically ~128 KB or 
so in size is fine), is definitely preferable to legacy MBR for grub2.  
This is because grub2 makes use of the (bare-partition, no-filesystem) 
dedicated BIOS partition to place its core in, something grub1 doesn't 
do.  With no filesystem and a special partition type dedicated by GPT for 
this purpose, this is the strongest guarantee yet that the core will 
remain undisturbed at the absolute address grub placed it at, and thus at 
least the core rescue shell should always be available, even if something 
happens to /boot (which is entirely separate from the reserved BIOS 
partition.

If a user has planned well when they setup their GPT partitioning, this 
reserved BIOS partition should be plenty large enough for all required 
modules, even for stacked devices such as exotic filesystem on lvm on 
mdraid.

3) For EFI-based GPT, there's another entirely separate special reserved 
partition for the EFI system.  According to the EFI spec, this must be 
formatted FAT32, and should be 256 MB or so.  I don't have an EFI system 
so have skipped much of the grub2 documentation on this so far and thus 
don't know a whole lot about it.

Again, if a user has planned well when setting up their GPT, they may 
actually have both an EFI partition and a BIOS partition (as I do here), 
tho only one will likely be in use.  But having both in the gpt layout 
does allow migrating the disk from a legacy BIOS system to a newer EFI 
system when the time comes, without re-gdisking (fdisking for gpt).


Meanwhile, for those who didn't know yet, it's worth noting that with GPT 
there's no primary/logical partition division, they're all the same, and 
there's room for upto 128 partition entries in the standard GPT, tho a 
larger one is possible if needed.  Additionally, there's two copies of 
the partition table and they're checksummed, making them MUCH more 
reliable than the old MBR scheme.  AND, gpt allows direct partition 
names, much like filesystem labels, udev maps them (tho for some reason 
it doesn't seem to map those on mdraid devices last I checked), and mount 
can mount by partition name using udev in much the same way as it mounts 
by UUID or filesystem label.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman