The NetBSD operating system has support for GPT disks via dkwedges, but can't be boot of such a disk. There are two standard ways to load kernel off the GPT: use EFI, or use legacy BIOS bootstrapping with GPT support. This project is about implementing second approach — develop GPT aware bootloader for the NetBSD operating system by extending its existing MBR/disklabel based multistaged kernel loader.
The project was initially started as part of Google Summer of Code 2009.
Please read the list of TODO items before your rants.
It means the mbr code should be learned to understand GPT. There is not so much space, but taking in account that GPT is a replacement to MBR partitioning, and MBR can be avoided by EFI compliant system, IMO it would be safe to drop usual code from GPT-aware MBR and place there GPT parsing only. GPT have special GUID when used during BIOS boot, but very first partition with FFS GUID should be a preferred option. Also, in case if the FFS partition is not bootable, we should try all other FFS parts as well.
The design concepts are presented on the MBR+GPT activity diagram.
There are two options to boot from a GPT partitioned disk:
ClassicalNetBSD bootxx code, when 1st stage loader is installed on a native NetBSD partitions, and PBR performs partition analysis again and reads rest of 1st stage boot code from subsequent sectors. After that it tries to find appropriate boot partition where boot(8) can be loaded from.
EFI stylecode, when all loaders are stored on the EFI System Partition (usually MS-DOS formatted), and there no need for 1st stage loader to hunt through partition tables and load secondary loader — it can be assumed the boot(8) is located on the same partition.
As GPT layout is came from the EFI world, it perhaps better to follow the second approach. Fortunately, fatboot (or bootxx_fat16) loader can do almost all required things, the one only missing is FAT16 lookup at arbitrary offset on disk.
bootxx discovers appropriate partition (if needed), reads boot(8) from it, and jumps into it. Almost no modifications required in this part.
by default boot2 uses data supplied by boot1. User can override it, and boot2 will rely on set of biosdisk_*() functions to locate partitions as it specified by user. Unfortunately, all those functions are relying on disklabel(5) structures and therefore should be adopted to GPT as well.
As soon as struct *bootinfo will properly be constructed, all the rest should working just fine, and dkwedges should work automatically (probably dk as root is already done, if not, it should be adopted too). That's all.