• DevSummit
• 201905
• FailsafeBootcode

FreeBSD Developer Summit: Fail-Safe Boot Code

Date: TBD

Overview

FreeBSD has provided a failsafe upgrade path for appliances with NanoBSD (UFS + GPT Flags) for many years. Recent efforts to build a similar system for ZFS based systems using Boot Environments are going well, and cover everything after /boot/loader. However, the approach NanoBSD used (GPT Flags) doesn't work for boot environments, because there is only a single ZFS partition. The new and old system image are inside that partition. This requires extending the 'boot once' style failover system to earlier parts of the bootcode.

The UEFI standard provides a standard way to do failover and boot once. The Boot Manager protocol has been implemented completely there and can be used to reliably implement failover protocols. However, some embedded platform don't support writing to the UEFI environment (thus making persistent changes to the boot impossible, though these are just supposed to be for a one and only one way to boot scenarios). Also, some BIOS makers have such ham-fisted UEFI implementations that they clobber some or all of the UEFI BootXXXX variables. Finally, no updating script for NanoBSD has been upstreamed.

Agenda

• Legacy Boot
  • Should we move gptzfsboot from freebsd-boot to inside freebsd-zfs @offset (like the MBR way)
  • Can we create a 2nd offset to store a backup gptzfsboot?
  • make a version of PMBR (ZFSPMBR) that knows these offsets and can failsafe GPT boot a ZFS pool (based on how the old MBR version works)
  • Or do we create two freebsd-boot partitions and teach PMBR about the GPT flags (bootme, bootonce, bootfailed)
    • the gptbooot protocol for these flags is tricky, and PMBR is likely too small to be able to implement it.

  • How best to make a zpool bootcode command for updating the primary and backup gptzfsboot, or the EFI code if it exists

• UEFI
  • Add support for a fallback loader.efi for UEFI boot that goes beyond UEFI Boot Manager Protocol (done)

  • Leverage EFI NVRAM BootNext variable as part of loader update mechanism

  • Userland update mechanism. What is the expected way for a user to update their EFI bootcode.
    • do we do it as part of install world (with knobs)
    • do we add a new installboot target
    • Is it just a script?
    • How much can we leverage for imaging
  • Should we switch to ZFS managed EFI partition for full disk ZFS installs?

Attending

Please add yourself here. Your name needs to already appear on the general developer summit attendees list though.

Results

Notes: https://hackmd.io/AA4TrMDERUKn_1qw0TEyhA