Page MenuHomeFreeBSD

Let the EFI loader build a partition menu
Needs ReviewPublic

Authored by stephane.rochoy_stormshield.eu on Fri, Feb 27, 10:43 AM.

Details

Summary

It build the menu using either a static list of partitions (filtered by name
and/or unit) or by using the BOOTME attribute. Under the hood it use the
PARTITION_INFO protocol if available but fallback to builtin GPT parsing when
missing.

The following tunables are available to tweak the menu:

  • partmenu_default What partition to try when the user don't press any key after partmenu_delay seconds. Only value supported: firstbootme.
  • partmenu_firstkey The first key to use when building the menu. Default to 0.
  • partmenu_maxdelay How many seconds to wait for user input. Default to 10 seconds.
  • partmenu_names Name of partitions to include in the menu.
  • partmenu_units Unit (i.e., partition number) of partitions to include in the menu.

Note that you can combine partmenu_default=firstbootme with partmenu_names
or partmenu_units to be able to easily change the default boot partition.
With the following in loader.conf:

# Two partitions, defaulting to the first one having the BOOTME attribute
partmenu_default=firstbootme
partmenu_names=2,7

You can switch default from 2 to 7 as follow:

gpart unset -a bootme -i 2 ada0
gpart set   -a bootme -i 7 ada0

Here is an example of menu:

>>> Partitions
[1] Boot MAIN
[2] Boot BACKUP
[i] Display Information
Default: firstbootme, MAIN
Choose: boot MAIN

This patch follow a discussion in PR#207940.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 71064
Build 67947: arc lint + arc unit

Event Timeline

My big problem with this is three fold. 1. Gpt bootme is non standard, so I don't want to build anything on it. 2 all menu stuff should be in lua, not c. The part protocol is not a good base to start from. And I guess 3: it ignore the BootXXXX protocol, so locks out all other oses. It is a big reason I never merged the boot1 changes in that pr. It is too limited in what it can boot and isn't scriptable.

In D55559#1271244, @imp wrote:

My big problem with this is three fold. 1. Gpt bootme is non standard, so I don't want to build anything on it. 2 all menu stuff should be in lua, not c. The part protocol is not a good base to start from. And I guess 3: it ignore the BootXXXX protocol, so locks out all other oses. It is a big reason I never merged the boot1 changes in that pr. It is too limited in what it can boot and isn't scriptable.

Well, let's split the big problem into smaller ones then ;)

  1. The use of BOOTME is something we use here at Stormshield. I should be able to remove it from the patch. Not a big deal I guess.
  1. Putting menu in Lua looks great but I'm lacking some understanding here: is it possible before picking the partition where /boot/lua is? If yes, I'll be more than happy the use this approach.
  1. I didn't know the PARTITION_INFO protocol was a Bad Thing but as long as there's alternatives, let's see.
  1. By using the BootXXXX protocol, you means crafting the menu from it? Looks like a good idea to me :)

And if I understand correctly, 4 would solve 1 and 3, right?