[NetBSD logo]    &    [Google logo]

NetBSD-SoC: GPT aware boot loader support

What is it?

The GUID Partition Table layout providing a lot of advanced partitioning features, including, but not limited to:

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.


Mandatory (must-have) components:

Optional (would-be-nice) components:


I'm reading technical details as major guidance and trying to accomplish the following plan:

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.
17th August Pencils down.

Also, please take a look to my Twitter mini-blog.


The following documents were used as primary references:

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:

    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.

Get NetBSD Summer of Code projects at SourceForge.net. Fast, secure and Free Open Source software downloads
Mike M. Volokhov (mike.volokhov(at)gmail.com)
$Id: index.html,v 1.13 2009/08/20 07:56:44 bubuchka Exp $