GPT aware NetBSD boot loader

What is it?

• modern logical block addressing (LBA)
• 64-bit LBA pointers, allowing partitions up to 8 Zbytes in size, and even bigger
• suitable for disks with sector size, other than 512 bytes
• by default up to 128 partitions per disk
• backup partition table.

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.

Status

Please read the list of TODO items before your rants.

Documentation

• NetBSD Manual Pages
• UEFI Specification Version 2.3
• UEFI Platform Initialization Specification 1.2

Technical Details

How the NetBSD bootstraps

1. A i386 based bootstrapping is starting from MBR code.

   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.

2. The MBR performs partition table analysis, chooses a bootable partition, and reads its PBR, followed by the 1st stage boot, from it.

   There are two options to boot from a GPT partitioned disk:

   • Classical NetBSD 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 style code, 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.

3. 1st stage loader reads the second one.

   bootxx discovers appropriate partition (if needed), reads boot(8) from it, and jumps into it. Almost no modifications required in this part.

4. 2nd stage loader, boot(8), uses biosdisk_*() functions to select appropriate partition and read a kernel from.

   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.

5. Final steps.

   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.