[parted-devel] [PATCH] GPT & BIOS Boot partition

[Robert Millan]

On Fri, Feb 22, 2008 at 12:25:32PM -0800, H. Peter Anvin wrote:
> 
> That's the problem - "it just".  There is another part of the MBR 
> protocol which this doesn't seem to address; the DS:SI structure.
> 
> When an MBR chainloads a boot program, it sets DS:SI to point to the 
> partition entry; to make it work for cases like logical partitions it 
> needs to be synthesized since a logical partition entry has slightly 
> different meaning.
> 
> For < 2 TB, we can simply synthesize a MBR-style partition entry in 
> memory and point to it.  No problem.  For >= 2 TB, there are issues here.
> 
> One possible extension protocol would look like:
> 
> Point DS:SI to an MBR-style partition entry followed by the GPT 
> partition entry.  The MBR partition entry has EE as its type (indicating 
> GPT) and has the offset and length valid if possible, otherwise 
> 0FFFFFFFFh.  This should provide maximum compatibility while providing 
> the program with the flexibility it needs.
> 
> Why bother with this stuff?  Well, for one thing, if partitions can be 
> moved, it is not a very nice thing to stop being able to boot as a result.

Sounds fine to me.  Although it can be some work to make the code for that
fit (patches welcome ;-)).

> However, using a specific UUID for this doesn't seem to be all that good 
> of an idea;

A dedicated partition is, in fact, the only way to get back the static
63-sector area we used to have with DOS labels.

Of course, you have other options;  you can put your code in a filesystem
and hardcode its offset (expect some fun with xfs), or you can assume your
filesystem of choice reserves space at the beginning of its partition.  GRUB
can do both but neither of them is as good as embedding the bootstrap code
in sectors 1 to 63 like it used to (AFAICT).

So, let's summarize that we have two options:

 1- We can just assume this partition type is "for use by BIOS-based
    bootloaders as they see fit".  This is what GRUB already does, but also
    what other bootloaders can do if they find that useful.

    But, of course, if you previously ignored the 63-sector gap and just jumped
    from MBR to PBR, this option doesn't provide any advantage to you, only the
    second one does.

 2- We can try to standarize a boot mechanism on top of it.  My GPT-MBR work
    is aimed in that direction.  Although there are limitations as you pointed
    out (and others you didn't mention), but overall I see this as a bonus
    once you have a partition type that bootloaders can use in their own
    specific way.

> especially with Redmond OSes seemingly going a different way.

What do you mean?  Last I heard, their way was not supporting GPT on BIOS at
all :-)

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)