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.
|23th May – 7th June||LBA0 implementation.||β stage reached, PBR can be loaded for partition of any GUID type.|
|8th June – 17th June||PBR implementation.||β stage reached. The /boot can be loaded off GPT partition (System EFI UUID) using bootxx_fat16 loader.|
|18th June – 12th July||Complete bootxx implementation. installboot(8) and gpt(8) review.||LBA0 loader can be installed using new "biosboot" command of gpt(8). PBR loader can be installed by standard installboot(8), but will work with the gpt_mbr (the LBA0) only.|
|13th July – 2nd August||boot(8) implementation.||The boot(8) was extended with GPT parsing, which is now preferred to MBR/disklabel (i.e. if GPT is found, no disklabel lookup will be performed). A kernel and OS can be loaded from a GPT partition.|
|3rd August &ndash 16th August||Documentation update. Final testing.||There is some TODOs and nitpicks that should be cleaned up before publishing the code. Please also feel free to test it yourself.|
Also, please take a look to my
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.