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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
