NAME
loader.conf - Configuration file for systemd-bootSYNOPSIS
ESP/loader/loader.conf, ESP/loader/entries/*.conf XBOOTLDR/loader/entries/*.confDESCRIPTION
systemd-boot(7) will read ESP/loader/loader.conf, and any files with the ".conf" extension under ESP/loader/entries/ on the EFI system partition (ESP), and XBOOTLDR/loader/entries/ on the extended boot loader partition (XBOOTLDR) as defined by Boot Loader Specification[1]. Each of these configuration files must consist of series of newline (i.e. ASCII code 10) separated lines, each consisting of an option name, followed by whitespace, and the option value. "#" may be used to start a comment line. Empty and comment lines are ignored. The files use UTF-8 encoding. Boolean arguments may be written as "yes"/"y"/"true"/"t"/"on"/"1" or "no"/"n"/"false"/"f"/"off"/"0".OPTIONS
The configuration options supported by ESP/loader/entries/*.conf and XBOOTLDR/loader/entries/*.conf files are defined as part of the Boot Loader Specification[1]. The following configuration are supported by the loader.conf configuration file: defaultA glob pattern to select the default entry.
The default entry may be changed in the boot menu itself, in which case the
name of the selected entry will be stored as an EFI variable, overriding this
option.
If set to "@saved" the chosen entry will be saved as an EFI variable
on every boot and automatically selected the next time the boot loader starts.
Table 1. Automatically detected entries will use the following
names:
Supported glob wildcard patterns are
"?", "*", and "[...]" (including ranges). Note
that these patterns use the same syntax as glob(7), but do not support
all features. In particular, set negation and named character classes are not
supported. The matching is done case-insensitively on the entry ID (as shown
by bootctl list).
timeout
Name | Description |
auto-efi-default | EFI Default Loader |
auto-efi-shell | EFI Shell |
auto-osx | macOS |
auto-reboot-to-firmware-setup | Reboot Into Firmware Interface |
auto-windows | Windows Boot Manager |
How long the boot menu should be shown before
the default entry is booted, in seconds. This may be changed in the boot menu
itself and will be stored as an EFI variable in that case, overriding this
option.
If set to "menu-hidden" or "0" (the default) no menu is
shown and the default entry will be booted immediately. The menu can be shown
by pressing and holding a key before systemd-boot is launched. Setting this to
"menu-force" disables the timeout while always showing the
menu.
console-mode
This option configures the resolution of the
console. Takes a number or one of the special values listed below. The
following values may be used:
0
editor
Standard UEFI 80x25 mode
1
80x50 mode, not supported by all devices
2
the first non-standard mode provided by the
device firmware, if any
auto
Pick a suitable mode automatically using
heuristics
max
Pick the highest-numbered available mode
keep
Keep the mode selected by firmware (the
default)
Takes a boolean argument. Enable (the default)
or disable the editor. The editor should be disabled if the machine can be
accessed by unauthorized persons.
auto-entries
Takes a boolean argument. Enable (the default)
or disable entries for other boot entries found on the boot partition. In
particular, this may be useful when loader entries are created to show
replacement descriptions for those entries.
auto-firmware
A boolean controlling the presence of the
"Reboot into firmware" entry (enabled by default). If this is
disabled, the firmware interface may still be reached by using the f
key.
beep
Takes a boolean argument. If timeout enabled
beep every second, otherwise beep n times when n-th entry in boot menu is
selected (default disabled). Currently, only x86 is supported, where it uses
the PC speaker.
secure-boot-enroll
Danger: this feature might soft-brick your
device if used improperly.
Takes one of "off", "manual" or "force". Controls
the enrollment of secure boot keys. If set to "off", no action
whatsoever is taken. If set to "manual" (the default) and the UEFI
firmware is in setup-mode then entries to manually enroll Secure Boot
variables are created in the boot menu. If set to "force", in
addition, if a directory named /loader/keys/auto/ exists on the ESP then the
keys in that directory are enrolled automatically.
The different sets of variables can be set up under /loader/keys/ NAME
where NAME is the name that is going to be used as the name of the
entry. This allows one to ship multiple sets of Secure Boot variables and
choose which one to enroll at runtime.
Supported secure boot variables are one database for authorized images, one key
exchange key (KEK) and one platform key (PK). For more information, refer to
the UEFI specification[2], under Secure Boot and Driver Signing.
Another resource that describe the interplay of the different variables is the
EDK2 documentation[3].
A complete set of UEFI variable includes db.auth, KEK.auth and PK.auth. Note
that these files need to be authenticated UEFI variables. See below for an
example of how to generate them from regular X.509 keys.
This feature is considered dangerous because even if all the required files are
signed with the keys being loaded, some files necessary for the system to
function properly still won't be. This is especially the case with Option ROMs
(e.g. for storage controllers or graphics cards). See Secure Boot and
Option ROMs[4] for more details.
reboot-for-bitlocker
uuid=$(systemd-id128 new --uuid) for key in PK KEK db; do openssl req -new -x509 -subj "/CN=${key}/" -keyout "${key}.key" -out "${key}.crt" openssl x509 -outform DER -in "${key}.crt" -out "${key}.cer" cert-to-efi-sig-list -g "${uuid}" "${key}.crt" "${key}.esl" done for key in MicWinProPCA2011_2011-10-19.crt MicCorUEFCA2011_2011-06-27.crt MicCorKEKCA2011_2011-06-24.crt; do curl "https://www.microsoft.com/pkiops/certs/${key}" --output "${key}" sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output "${key%crt}esl" "${key}" done # Optionally add Microsoft Windows Production CA 2011 (needed to boot into Windows). cat MicWinProPCA2011_2011-10-19.esl >> db.esl # Optionally add Microsoft Corporation UEFI CA 2011 (for firmware drivers / option ROMs # and third-party boot loaders (including shim). This is highly recommended on real # hardware as not including this may soft-brick your device (see next paragraph). cat MicCorUEFCA2011_2011-06-27.esl >> db.esl # Optionally add Microsoft Corporation KEK CA 2011. Recommended if either of the # Microsoft keys is used as the official UEFI revocation database is signed with this # key. The revocation database can be updated with fwupdmgr(1). cat MicCorKEKCA2011_2011-06-24.esl >> KEK.esl sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth
Caveat: This feature is experimental, and is
likely to be changed (or removed in its current form) in a future version of
systemd.
Work around BitLocker requiring a recovery key when the boot loader was updated
(disabled by default).
Try to detect BitLocker encrypted drives along with an active TPM. If both are
found and Windows Boot Manager is selected in the boot menu, set the
"BootNext" EFI variable and restart the system. The firmware will
then start Windows Boot Manager directly, leaving the TPM PCRs in expected
states so that Windows can unseal the encryption key. This allows systemd-boot
to be updated without having to provide the recovery key for BitLocker drive
unlocking.
Note that the PCRs that Windows uses can be configured with the "Configure
TPM platform validation profile for native UEFI firmware configurations"
group policy under "Computer Configuration\Administrative
Templates\Windows Components\BitLocker Drive Encryption". When secure
boot is enabled, changing this to PCRs "0,2,7,11" should be safe.
The TPM key protector needs to be removed and then added back for the PCRs on
an already encrypted drive to change. If PCR 4 is not measured, this setting
can be disabled to speed up booting into Windows.
random-seed-mode
Takes one of "off",
"with-system-token" and "always". If "off" no
random seed data is read off the ESP, nor passed to the OS. If
"with-system-token" (the default) systemd-boot will read a
random seed from the ESP (from the file /loader/random-seed) only if the
LoaderSystemToken EFI variable is set, and then derive the random seed
to pass to the OS from the combination. If "always" the boot loader
will do so even if LoaderSystemToken is not set. This mode is useful in
environments where protection against OS image reuse is not a concern, and the
random seed shall be used even with no further setup in place. Use bootctl
random-seed to initialize both the random seed file in the ESP and the
system token EFI variable.
See Random Seeds[5] for further information.
EXAMPLE
# /boot/efi/loader/loader.conf timeout 0 default 01234567890abcdef1234567890abdf0-* editor no
SEE ALSO
systemd-boot(7), bootctl(1)NOTES
- 1.
- Boot Loader Specification
- 2.
- UEFI specification
- 3.
- EDK2 documentation
- 4.
- Secure Boot and Option ROMs
- 5.
- Random Seeds
systemd 252 |