RE: grub2 and hybrid MBR booting

[Elliott, Robert (Server Storage)]

> -----Original Message-----
> From: address@hidden [mailto:grub-devel-
> address@hidden On Behalf Of Vladimir 'f-coder/phcoder'
> Serbinenko
> Sent: Thursday, 01 July, 2010 2:43 PM
> To: address@hidden
> Subject: Re: grub2 and hybrid MBR booting
> 
> On 06/29/2010 08:37 PM, Elliott, Robert (Server Storage) wrote:
> > I successfully ran ubuntu 10.04 (which uses grub2) on a 4 TB drive
> > (presented by a RAID controller) on a system with legacy BIOS.  The
> > drive got partitioned as GPT; a BIOS boot partition was installed;
> > and grub stage 1 contains the 8-byte LBA of the BIOS boot partition
> > hardcoded into its 440 bytes of x86 boot code, so it can load the
> > code in that BIOS boot partition.
> >
> > That works pretty well, but requires any program that moves the BIOS
> > boot partition to know that grub is pointing to it and also adjust
> > that 8-byte LBA value stored in LBA 0.
> >
> >
> After moving of partitions containing it's recommended to reinstall
> bootloader

> > In the UEFI Working Group (which defines GPT) and the T13 (ATA)
> > standards bodies, we defined a slightly different method:  the GPT 
> > partition record now includes a Legacy BIOS Bootable bit that can be 
> > set for a partition like the BIOS boot partition,   The algorithm is 
> > documented in T13 EDD-4 revision 2 and later (see
> > http://t13.org/Documents/MinutesDefault.aspx?DocumentType=4&DocumentSta
> > ge=1).
> >
> >
> At last. It's refreshing from the usual lie that you need EFI to boot
> from GPT-partitioned disk.
> But I don't see the need to standartise the interface between MBR code
> and the rest. Standartisation is good only for interoperability between
> different software. But in this case both parts are from the same
> bootloader so it will only reduce flexibility.

The "handoff" contents are defined to better support MBRs and VBRs that
aren't tightly coupled.  The VBR can ignore the data structure if it 
doesn't need it. Syslinux felt it helpful to support legacy VBRs
(particularly when they are located < 2.2 TB).

> 
> > and the x86 boot code in LBA 0 can search through the GPT partition 
> > table for a partition with that bit set to 1 (rather than contain 
> > a hardcoded LBA).
> It's closedly modeled after msdos. It annihilates most of advantages of
> GPT. I suppose you want to put filesystem on bootable partition too.

The bootable partition can hold whatever it wants; the BIOS
Boot Partition contents would be fine as-is.

UEFI system boots require a FAT filesystem on the UEFI system
partition; this scheme has no such requirement.

> When we added GPT support virtually unlimited embedding zone was the
> great plus. Switching to msdos-like scheme would be a huge step
> backwards (especially that you have no MBR gap). It's a repetion of old
> mistakes under new sauce. MSDOS scheme already forced anti-patterns and
> any new scheme must be based on saner pattern.

What's an "anti-pattern"?

The change here would be that the grub MBR code would locate the
grub VBR code (the BIOS Boot Partition) by looking for the Legacy BIOS 
Bootable bit in the GPT partition record, rather than have hardcode
the LBA at some offset in the MBR.

Although all legacy BIOS boots will fail if LBA 0 goes bad, this allows
inclusion of more than one legacy bootable partition on the disk to 
tolerate a failure in those LBAs.  It would also tolerate failures of 
the GPT region (since there's a backup GPT at the end of the disk
that can be used).

> 
> > Would grub2 consider switching to that modified algorithm?
> >
> > H Peter Anvin has implemented it in syslinux-4.00-pre48 (see
> > http://syslinux.zytor.com/wiki/index.php/The_Syslinux_Project).
> >
> Syslinux is known for hanging on the old protocol no matter the price.

> > The boot code doesn't have enough room to verify the GPT CRC and 
> > perform all the possible GPT verification checks, but it can definitely 
> > walk through the structure and find the boot partition.
> >
> >
> Which contradicts your spec. Unimplementable spec only forces devs to
> code undefined behaviour.

The T13 spec includes a NOTE that the CRC check might not be possible.
A few simpler checks could be done: check the GPT signature ("EFI PART") 
or the My LBA field.  Those are a bit stronger than the 0x55AA magic
number relied on by traditional MBRs.

> 
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
>