GPT boot loader?

[Adam Martin]

Resent to freebsd-hackers@:

Greetings, all.

On 2007.05.22, at 03:57, Ivan Voras wrote:

> Hi!
>
> I've had the opportunity to talk to Adam Martin, Marcel Moolenaar and
> Peter Wemm about making GPT bootable, but not all of them at the same
> time, so I'd like this thread to be the meeting point on the subject.

	I have offered to work on the MBR and some of the lower level  
assembler nasties to make this thing work.  The most problematic  
issue is that the GPT requires 128 bit fields to identify the  
partition type.  In a typical MBR we have 488 bytes to work with (512  
bytes in one sector, 2 bytes for the boot-identifier, and another 32  
bytes for the partition table.)  If we insert a few valid GPT labels  
into the MBR to scan for, this takes up 16 bytes per entry.  The  
lucky part is that the MBR really just needs to find a bootable  
partition, load a few sectors from it, and let go.

> (Adam and Peter have offered to modify the boot loader chain, but
> differently.)

	I can also work on boot2, not just mbr/boot0, to make it understand  
GPT, but I need to know a bit more about the information it needs to  
understand.  In this situation, /boot/loader still needs GPT support  
-- according to Marcel, it gets help on the GPT interpretation from  
the EFI.  I do not want to undertake the task of "GPT-ifying" the  
loader program.  It's not worth it to have someone make the earlier  
boot stages work with GPT, unless the later stages also will support it.

	I have written a simple MBR code that will look for the first GPT  
partition marked with a GUID specified at compile time, and load the  
first 8k of that partition, to facilitate boot2.  However, I do not  
think I will take this any further unless people take up the task of  
writing the GPT support for other parts of the boot-chain.

> Summary:
>
> The idea is to replace bsdlabels with GPT. The problem is that GPT is
> intended to be used with EFI and not to be bootable by regular BIOS
> machines. For FreeBSD, there are two distinct cases:
>
> 1. the machine is GPT-only, there are no other MSDOS and bsdlabel  
> partitions
> 2. the machine is dual-boot or has some other need to retain MSDOS
> partitions.
>
> The second case is more convoluted as it means the MBR will hold a
> regular MSDOS partition table, and one of those partitions will hold a
> GPT - which is trivially done with GEOM but completely non-standard.

	Marcel and I discussed a hybrid solution, which requires almost no  
bootloader code to be written -- We could have the MBR point to a  
"legacy" boot partition, even down to a really small root filesystem,  
which the GPT also has an entry for, but the kernel in this root  
filesystem has a switch set to inform it that it must use GPT and not  
MBR/BSDlabels.  This is not unlike what Apple have done with their  
EFI on x86 platform.

	In a related quirk, I have not used MBR partitions for almost 3  
years now -- I just raw-BSDlabel my discs.  So I know it is possible  
to do away with the MBR completely.  The biggest obstacle to this on  
x86/amd64 computers is the single-sector bootloader limitations.  GPT  
isn't very PC-friendly, as it also demands that the sectors right  
after the "fake MBR" be for the GPT.  What I would love to see is  
some ability to have a smarter PC boot procedure.

> I'd like to hear more from Adam and Peter (and others!) about their  
> ideas...

	Optimally, the PC architecture boot procedure (and perhaps the PC  
itself?) should die and fade away, leaving behind smarter bootloader  
and firmware code in its place, instead of shoehorning this  
functionality into an unnecessarily complicated bootloader chain.   
Since this does not seem to be in the cards, I guess we need to focus  
on this concept.

--
ADAM David Alan Martin

FreeBSD Hacker, TCSH Hacker, general UNIX coding
Author of AutoFS for FreeBSD 6.x
LSD Kernel Lead Developer
Filesystem and Storage Lab, SUNY Stony Brook