mirror of
https://github.com/systemd/systemd.git
synced 2024-12-25 01:34:28 +03:00
8b9f092112
Fixes #25780. > Man page: crypttab.5 > Issue 1: Missing fullstop > Issue 2: I<cipher=>, I<hash=>, I<size=> → B<cipher=>, B<hash=>, B<size=> > > "Force LUKS mode\\&. When this mode is used, the following options are " > "ignored since they are provided by the LUKS header on the device: " > "I<cipher=>, I<hash=>, I<size=>" Seems OK to me. The full stop is there and has been for at least a few years. And we use <option> for the markup, which is appropriate here. > Man page: crypttab.5 > Issue 1: Missing fullstop > Issue 2: I<cipher=>, I<hash=>, I<keyfile-offset=>, I<keyfile-size=>, I<size=> → B<cipher=>, B<hash=>, B<keyfile-offset=>, B<keyfile-size=>, B<size=> > > "Use TrueCrypt encryption mode\\&. When this mode is used, the following " > "options are ignored since they are provided by the TrueCrypt header on the " > "device or do not apply: I<cipher=>, I<hash=>, I<keyfile-offset=>, I<keyfile-" > "size=>, I<size=>" Same. > Man page: journalctl.1 > Issue 1: make be → may be Fixed. > Issue 2: below\\&. → below: Fixed. > Man page: journalctl.1 > Issue: Colon at the end? > > "The following commands are understood\\&. If none is specified the default " > "is to display journal records\\&." > msgstr "" > "Die folgenden Befehle werden verstanden\\&. Falls keiner festgelegt ist, ist " > "die Anzeige von Journal-Datensätzen die Vorgabe\\&." This is a bit awkward, but I'm not sure how to fix it. > Man page: kernel-install.8 > Issue: methods a fallback → methods fallback It was correct, but I added a comma to make the sense clearer. > Man page: loader.conf.5 > Issue 1: secure boot variables → Secure Boot variables > Issue 2: one → one for (multiple times) > > "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 \\m[blue]B<UEFI specification>\\m[]\\&\\s-2\\u[2]\\d\\s+2, " > "under Secure Boot and Driver Signing\\&. Another resource that describe the " > "interplay of the different variables is the \\m[blue]B<EDK2 " > "documentation>\\m[]\\&\\s-2\\u[3]\\d\\s+2\\&." "one of" would sound strange. "One this and one that" is OK. > Man page: loader.conf.5 > Issue: systemd-boot → B<systemd-boot>(7) Fixed. > Man page: logind.conf.5 > Issue: systemd-logind → B<systemd-logind>(8) We use <filename>systemd-logind</> on subsequent references… I think that's good enough. > Man page: nss-myhostname.8 > Issue: B<getent> → B<getent>(1) Fixed. > Man page: nss-resolve.8 > Issue: B<systemd-resolved> → B<systemd-resolved>(8) The first reference does this, subsequent are shorter. > Man page: os-release.5 > Issue: Portable Services → Portable Services Documentation? Updated. > Man page: pam_systemd_home.8 > Issue: auth and account use "reason", while session and password do not? Reworded. > Man page: portablectl.1 > Issue: In systemd-portabled.service(8): Portable Services Documentation Updated. > Man page: repart.d.5 > Issue: The partition → the partition Fixed. > Man page: repart.d.5 > Issue: B<systemd-repart> → B<systemd-repart>(8) The first reference does this. I also change this one, because it's pretty far down in the text. > Man page: systemd.1 > Issue: kernel command line twice? > > "Takes a boolean argument\\&. If false disables importing credentials from " > "the kernel command line, qemu_fw_cfg subsystem or the kernel command line\\&." Apparently this was fixed already. > Man page: systemd-boot.7 > Issue: enrollement → enrollment Fixed. > Man page: systemd-cryptenroll.1 > Issue: multiple cases: any specified → the specified Reworded. > Man page: systemd-cryptenroll.1 > Issue: If this this → If this Fixed tree-wide. > Man page: systemd-cryptsetup-generator.8 > Issue: and the initrd → and in the initrd "Is honoured by the initrd" is OK, because we often speak about the initrd as a single unit. But in the same paragraph we also used "in the initrd", which makes the other use look sloppy. I changed it to "in the initrd" everywhere in that file. > Man page: systemd.directives.7 > Issue: Why are these two quoted (but not others)? > > "B<\\*(Aqh\\*(Aq>" > > B<\\*(Aqs\\*(Aq>" > > "B<\\*(Aqy\\*(Aq>" This is autogenerated from files… We use slightly different markup in different files, and it's just too hard to make it consistent. We gave up on this. > Man page: systemd.exec.5 > Issue 1: B<at>(1p) → B<at>(1) > Issue 2: B<crontab>(1p) → B<crontab>(1) Fixed. > Man page: systemd.exec.5 > Issue: B<select()> → B<select>(2) Fixed. > Man page: systemd.exec.5 > Issue: qemu → B<qemu>(1) The man page doesn't seem to be in any of the canonical places on the web. I added a link to online docs. > Man page: systemd.exec.5 > Issue: variable → variables Seems to be fixed already. > Man page: systemd-integritysetup-generator.8 > Issue: systemd-integritysetup-generator → B<systemd-integritysetup-generator> I changed <filename> to <command>. > Man page: systemd-integritysetup-generator.8 > Issue: superfluous comma at the end Already fixed. > Man page: systemd-measure.1 > Issue: (see B<--pcr-bank=>) below → (see B<--pcr-bank=> below) Reworded. > Man page: systemd-measure.1 > Issue: =PATH> → =>I<PATH> Fixed. > Man page: systemd-measure.1.po > Issue: B<--bank=DIGEST> → B<--bank=>I<DIGEST> Fixed. > Man page: systemd.netdev.5 > Issue: os the → on the Appears to have been fixed already. > Man page: systemd.netdev.5 > Issue: Onboard → On-board (as in previous string) Updated. > Man page: systemd.network.5 > Issue: B<systemd-networkd> -> B<systemd-networkd>(8) First reference does this, subsequent do not. > Man page: systemd.network.5 > Issue: B<netlabelctl> → B<netlabelctl>(8) First reference does this, subsequent do not. > Man page: systemd.network.5 > Issue: Missing verb (aquired? configured?) in the half sentence starting with "or by a " I dropped the comma. > Man page: systemd-nspawn.1 > Issue: All host users outside of that range → All other host users Reworded. > # FIXME no effect → no effect\\&. > #. type: Plain text > #: archlinux debian-unstable fedora-rawhide mageia-cauldron opensuse-tumbleweed > msgid "" > "Whichever ID mapping option is used, the same mapping will be used for users " > "and groups IDs\\&. If B<rootidmap> is used, the group owning the bind " > "mounted directory will have no effect" A period is added. Not sure if there's some other issue. > Man page: systemd-oomd.service.8 > Issue: B<systemd> → B<systemd>(1) Done. > Man page: systemd.path.5 > Issue 1: B<systemd.exec>(1) → B<systemd.exec>(5) > Issue 2: This section does not (yet?) exist Fixed. > Man page: systemd-pcrphase.service.8 > Issue 1: indicate phases into TPM2 PCR 11 ?? > Issue 2: Colon at the end of the paragraph? Fixed. > Man page: systemd-pcrphase.service.8 > Issue: final boot phase → final shutdown phase? Updated. > Man page: systemd-pcrphase.service.8 > Issue: for the the → for the Fixed tree-wide. > Man page: systemd-portabled.service.8 > Issue: In systemd-portabled.service(8): Portable Services Documentation Updated. > Man page: systemd-pstore.service.8 > Issue: Here and the following paragraphs: . → \\&. // Upstream: What does this comment mean? // You normally write \\&. for a full dot (full stop etc.); here you write only "." (i.e. a plain dot). > > "and we look up \"localhost\", nss-dns will send the following queries to " > "systemd-resolved listening on 127.0.0.53:53: first \"localhost.foobar.com\", " > "then \"localhost.barbar.com\", and finally \"localhost\". If (hopefully) the " > "first two queries fail, systemd-resolved will synthesize an answer for the " > "third query." Looks all OK to me. > Man page: systemd.resource-control.5 > Issue: Missing closing bracket after link to Control Groups version 1 Fixed. > Man page: systemd-sysext.8 > Issue: In systemd-portabled.service(8): Portable Services Documentation Updated. > Man page: systemd.timer.5 > Issue 1: B<systemd.exec>(1) → B<systemd.exec>(5) > Issue 2: This section does not (yet?) exist Fixed. > Man page: systemd.unit.5 > Issue: that is → that are Fixed. > Man page: systemd-veritysetup-generator.8 > Issue: systemd-veritysetup-generator → B<systemd-veritysetup-generator> > > "systemd-veritysetup-generator implements B<systemd.generator>(7)\\&." > > "systemd-veritysetup-generator understands the following kernel command line " > "parameters:" Updated. > Man page: systemd-volatile-root.service.8 > Issue: initrdyes → Initrd Fixed. > Man page: sysupdate.d.5 > Issue: : → \\&. (As above in TRANSFER) Updated. > Man page: sysupdate.d.5 > Issue: some → certain Updated. > Man page: sysupdate.d.5 > Issue 1: i\\&.e\\& → I\\&.e\\& Fixed. > Issue 2: the image → the system "image" seems correct. > Man page: tmpfiles.d.5 > Issue: systemd-tmpfiles → B<systemd-tmpfiles>(8) Updated.
537 lines
28 KiB
XML
537 lines
28 KiB
XML
<?xml version='1.0'?> <!--*-nxml-*-->
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
|
|
|
<refentry id="systemd-boot" conditional='HAVE_GNU_EFI'
|
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
<refentryinfo>
|
|
<title>systemd-boot</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>systemd-boot</refentrytitle>
|
|
<manvolnum>7</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>systemd-boot</refname>
|
|
<refname>sd-boot</refname>
|
|
<refpurpose>A simple UEFI boot manager</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para><command>systemd-boot</command> (short: <command>sd-boot</command>) is a simple UEFI boot
|
|
manager. It provides a textual menu to select the entry to boot and an editor for the kernel command
|
|
line. <command>systemd-boot</command> supports systems with UEFI firmware only.</para>
|
|
|
|
<para><command>systemd-boot</command> loads boot entry information from the EFI system partition (ESP),
|
|
usually mounted at <filename>/efi/</filename>, <filename>/boot/</filename>, or
|
|
<filename>/boot/efi/</filename> during OS runtime, as well as from the Extended Boot Loader partition
|
|
(XBOOTLDR) if it exists (usually mounted to <filename>/boot/</filename>). Configuration file fragments,
|
|
kernels, initrds and other EFI images to boot generally need to reside on the ESP or the Extended Boot
|
|
Loader partition. Linux kernels must be built with <option>CONFIG_EFI_STUB</option> to be able to be
|
|
directly executed as an EFI image. During boot <command>systemd-boot</command> automatically assembles a
|
|
list of boot entries from the following sources:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Boot entries defined with <ulink
|
|
url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> Type #1
|
|
description files located in <filename>/loader/entries/</filename> on the ESP and the Extended Boot
|
|
Loader Partition. These usually describe Linux kernel images with associated initrd images, but
|
|
alternatively may also describe other arbitrary EFI executables.</para></listitem>
|
|
|
|
<listitem><para>Unified kernel images, <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot
|
|
Loader Specification</ulink> Type #2, which are executable EFI binaries in
|
|
<filename>/EFI/Linux/</filename> on the ESP and the Extended Boot Loader Partition.</para></listitem>
|
|
|
|
<listitem><para>The Microsoft Windows EFI boot manager, if installed.</para></listitem>
|
|
|
|
<listitem><para>The Apple macOS boot manager, if installed.</para></listitem>
|
|
|
|
<listitem><para>The EFI Shell binary, if installed.</para></listitem>
|
|
|
|
<listitem><para>A reboot into the UEFI firmware setup option, if supported by the firmware.</para></listitem>
|
|
|
|
<listitem><para>Secure Boot variables enrollment if the UEFI firmware is in setup-mode and files are provided
|
|
on the ESP.</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para><command>systemd-boot</command> supports the following features:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Basic boot manager configuration changes (such as timeout
|
|
configuration, default boot entry selection, …) may be made directly from the boot loader UI at
|
|
boot-time, as well as during system runtime with EFI variables.</para></listitem>
|
|
|
|
<listitem><para>The boot manager integrates with the <command>systemctl</command> command to implement
|
|
features such as <command>systemctl reboot --boot-loader-entry=…</command> (for rebooting into a
|
|
specific boot menu entry, i.e. "reboot into Windows") and <command>systemctl reboot
|
|
--boot-loader-menu=…</command> (for rebooting into the boot loader menu), by implementing the <ulink
|
|
url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>. See
|
|
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
|
|
details.</para></listitem>
|
|
|
|
<listitem><para>An EFI variable set by the boot loader informs the OS about the EFI System Partition used
|
|
during boot. This is then used to automatically mount the correct EFI System Partition to
|
|
<filename>/efi/</filename> or <filename>/boot/</filename> during OS runtime. See
|
|
<citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
for details.</para></listitem>
|
|
|
|
<listitem><para>The boot manager provides information about the boot time spent in UEFI firmware using
|
|
the <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>. This
|
|
information can be displayed using
|
|
<citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
|
|
</para></listitem>
|
|
|
|
<listitem><para>The boot manager implements boot counting and automatic fallback to older, working boot
|
|
entries on failure. See <ulink url="https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT">Automatic Boot
|
|
Assessment</ulink>.</para></listitem>
|
|
|
|
<listitem><para>The boot manager optionally reads a random seed from the ESP partition, combines it
|
|
with a 'system token' stored in a persistent EFI variable and derives a random seed to use by the OS as
|
|
entropy pool initialization, providing a full entropy pool during early boot.</para></listitem>
|
|
|
|
<listitem><para>The boot manager allows for Secure Boot variables to be enrolled if the UEFI firmware is
|
|
in setup-mode. Additionally, variables can be automatically enrolled if configured.</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para><citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
may be used from a running system to locate the ESP and the Extended Boot Loader Partition, list
|
|
available entries, and install <command>systemd-boot</command> itself.</para>
|
|
|
|
<para><citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
may be used to copy kernel images onto the ESP or the Extended Boot Loader Partition and to generate
|
|
description files compliant with the Boot Loader
|
|
Specification.</para>
|
|
|
|
<para><citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
|
may be used as UEFI boot stub for executed kernels, which is useful to show graphical boot splashes
|
|
before transitioning into the Linux world. It is also capable of automatically picking up auxiliary
|
|
credential files (for boot parameterization) and system extension images, as companion files to the
|
|
booted kernel images.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Key bindings</title>
|
|
<para>The following keys may be used in the boot menu:</para>
|
|
|
|
<!-- Developer commands Q/v/Ctrl+l deliberately not advertised. -->
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><keycap>↑</keycap> (Up)</term>
|
|
<term><keycap>↓</keycap> (Down)</term>
|
|
<term><keycap>j</keycap></term>
|
|
<term><keycap>k</keycap></term>
|
|
<term><keycap>PageUp</keycap></term>
|
|
<term><keycap>PageDown</keycap></term>
|
|
<term><keycap>Home</keycap></term>
|
|
<term><keycap>End</keycap></term>
|
|
<listitem><para>Navigate up/down in the entry list</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>↵</keycap> (Enter)</term>
|
|
<term><keycap>→</keycap> (Right)</term>
|
|
<listitem><para>Boot selected entry</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>d</keycap></term>
|
|
<listitem><para>Make selected entry the default</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>e</keycap></term>
|
|
<listitem><para>Edit the kernel command line for selected entry</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>+</keycap></term>
|
|
<term><keycap>t</keycap></term>
|
|
<listitem><para>Increase the timeout before default entry is booted</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>-</keycap></term>
|
|
<term><keycap>T</keycap></term>
|
|
<listitem><para>Decrease the timeout</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>r</keycap></term>
|
|
<listitem><para>Change screen resolution, skipping any unsupported modes.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>R</keycap></term>
|
|
<listitem><para>Reset screen resolution to firmware or configuration file default.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>p</keycap></term>
|
|
<listitem><para>Print status</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>h</keycap></term>
|
|
<term><keycap>?</keycap></term>
|
|
<term><keycap>F1</keycap></term>
|
|
<listitem><para>Show a help screen</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>f</keycap></term>
|
|
<listitem><para>Reboot into firmware interface.</para>
|
|
|
|
<para>For compatibility with the keybindings of several firmware implementations this operation
|
|
may also be reached with <keycap>F2</keycap>, <keycap>F10</keycap>, <keycap>Del</keycap> and
|
|
<keycap>Esc</keycap>.</para></listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>The following keys may be pressed during bootup or in the boot menu to directly boot a specific
|
|
entry:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><keycap>l</keycap></term>
|
|
<listitem><para>Linux</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>w</keycap></term>
|
|
<listitem><para>Windows</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>a</keycap></term>
|
|
<listitem><para>macOS</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>s</keycap></term>
|
|
<listitem><para>EFI shell</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>1</keycap></term>
|
|
<term><keycap>2</keycap></term>
|
|
<term><keycap>3</keycap></term>
|
|
<term><keycap>4</keycap></term>
|
|
<term><keycap>5</keycap></term>
|
|
<term><keycap>6</keycap></term>
|
|
<term><keycap>7</keycap></term>
|
|
<term><keycap>8</keycap></term>
|
|
<term><keycap>9</keycap></term>
|
|
<listitem><para>Boot entry number 1 … 9</para></listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>The boot menu is shown when a non-zero menu timeout has been configured. If the menu timeout has
|
|
been set to zero, it is sufficient to press any key — before the boot loader initializes — to bring up
|
|
the boot menu, except for the keys listed immediately above as they directly boot into the selected boot
|
|
menu item. Note that depending on the firmware implementation the time window where key presses are
|
|
accepted before the boot loader initializes might be short. If the window is missed, reboot and try
|
|
again, possibly pressing a suitable key (e.g. the space bar) continuously; on most systems it should be
|
|
possible to hit the time window after a few attempts. To avoid this problem, consider setting a non-zero
|
|
timeout, thus showing the boot menu unconditionally. Some desktop environments might offer an option to
|
|
directly boot into the boot menu, to avoid the problem altogether. Alternatively, use the command line
|
|
<command>systemctl reboot --boot-loader-menu=0</command> from the shell.</para>
|
|
|
|
<para>In the editor, most keys simply insert themselves, but the following keys
|
|
may be used to perform additional actions:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><keycap>←</keycap> (Left)</term>
|
|
<term><keycap>→</keycap> (Right)</term>
|
|
<term><keycap>Home</keycap></term>
|
|
<term><keycap>End</keycap></term>
|
|
<listitem><para>Navigate left/right</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>Esc</keycap></term>
|
|
<term><keycombo><keycap>Ctrl</keycap><keycap>c</keycap></keycombo></term>
|
|
<listitem><para>Abort the edit and quit the editor</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycombo><keycap>Ctrl</keycap><keycap>k</keycap></keycombo></term>
|
|
<listitem><para>Clear the command line forwards</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycombo><keycap>Ctrl</keycap><keycap>w</keycap></keycombo></term>
|
|
<term><keycombo><keycap>Alt</keycap><keycap>Backspace</keycap></keycombo></term>
|
|
<listitem><para>Delete word backwards</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycombo><keycap>Ctrl</keycap><keycap>Del</keycap></keycombo></term>
|
|
<term><keycombo><keycap>Alt</keycap><keycap>d</keycap></keycombo></term>
|
|
<listitem><para>Delete word forwards</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><keycap>↵</keycap> (Enter)</term>
|
|
<listitem><para>Boot entry with the edited command line</para></listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>Note that unless configured otherwise in the UEFI firmware, systemd-boot will
|
|
use the US keyboard layout, so key labels might not match for keys like +/-.
|
|
</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Files</title>
|
|
|
|
<para>The files <command>systemd-boot</command> processes generally reside on the UEFI ESP which is
|
|
usually mounted to <filename>/efi/</filename>, <filename>/boot/</filename> or
|
|
<filename>/boot/efi/</filename> during OS runtime. It also processes files on the Extended Boot Loader
|
|
partition which is typically mounted to <filename>/boot/</filename>, if it
|
|
exists.</para>
|
|
|
|
<para><command>systemd-boot</command> reads runtime configuration such as the boot timeout and default
|
|
entry from <filename>/loader/loader.conf</filename> on the ESP (in combination with data read from EFI
|
|
variables). See
|
|
<citerefentry><refentrytitle>loader.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
|
|
|
|
<para>Boot entry description files following the <ulink
|
|
url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> are read from
|
|
<filename>/loader/entries/</filename> on the ESP and the Extended Boot Loader partition.</para>
|
|
|
|
<para>Unified kernel boot entries following the <ulink
|
|
url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> are read from
|
|
<filename>/EFI/Linux/</filename> on the ESP and the Extended Boot Loader partition.</para>
|
|
|
|
<para>Optionally, a random seed for early boot entropy pool provisioning is stored in
|
|
<filename>/loader/random-seed</filename> in the ESP.</para>
|
|
|
|
<para>During initialization, <command>sd-boot</command> automatically loads all driver files placed in
|
|
the <filename>/EFI/systemd/drivers/</filename> directory of the ESP. The files placed there must have an
|
|
extension of the EFI architecture ID followed by <filename>.efi</filename> (e.g. for x86-64 this means a
|
|
suffix of <filename>x64.efi</filename>). This may be used to automatically load file system drivers and
|
|
similar, to extend the native firmware support.</para>
|
|
|
|
<para>Enrollment of Secure Boot variables can be performed manually or automatically if files are available
|
|
under <filename>/loader/keys/<replaceable>NAME</replaceable>/{db,KEK,PK}.auth</filename>, <replaceable>NAME</replaceable>
|
|
being the display name for the set of variables in the menu. If one of the sets is named <filename>auto</filename>
|
|
then it might be enrolled automatically depending on whether <literal>secure-boot-enroll</literal> is set
|
|
to force or not.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>EFI Variables</title>
|
|
|
|
<para>The following EFI variables are defined, set and read by <command>systemd-boot</command>, under the
|
|
vendor UUID <literal>4a67b082-0a4c-41cf-b6c7-440b29bb8c4f</literal>, for communication between the boot
|
|
loader and the OS:</para>
|
|
|
|
<variablelist class='efi-variables'>
|
|
<varlistentry>
|
|
<term><varname>LoaderBootCountPath</varname></term>
|
|
<listitem><para>If boot counting is enabled, contains the path to the file in whose name the boot counters are
|
|
encoded. Set by the boot
|
|
loader. <citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
uses this information to mark a boot as successful as determined by the successful activation of the
|
|
<filename>boot-complete.target</filename> target unit.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>LoaderConfigTimeout</varname></term>
|
|
<term><varname>LoaderConfigTimeoutOneShot</varname></term>
|
|
<listitem><para>The menu timeout in seconds. Read by the boot loader. <varname>LoaderConfigTimeout</varname>
|
|
is maintained persistently, while <varname>LoaderConfigTimeoutOneShot</varname> is a one-time override which is
|
|
read once (in which case it takes precedence over <varname>LoaderConfigTimeout</varname>) and then
|
|
removed. <varname>LoaderConfigTimeout</varname> may be manipulated with the
|
|
<keycap>t</keycap>/<keycap>T</keycap> keys, see above.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>LoaderDevicePartUUID</varname></term>
|
|
|
|
<listitem><para>Contains the partition UUID of the EFI System Partition the boot loader was run from. Set by
|
|
the boot
|
|
loader. <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
uses this information to automatically find the disk booted from, in order to discover various other partitions
|
|
on the same disk automatically.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>LoaderEntries</varname></term>
|
|
|
|
<listitem><para>A list of the identifiers of all discovered boot loader entries. Set by the boot
|
|
loader.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>LoaderEntryDefault</varname></term>
|
|
<term><varname>LoaderEntryOneShot</varname></term>
|
|
|
|
<listitem><para>The identifier of the default boot loader entry. Set primarily by the OS and read by the boot
|
|
loader. <varname>LoaderEntryOneShot</varname> sets the default entry for the next boot only, while
|
|
<varname>LoaderEntryDefault</varname> sets it persistently for all future
|
|
boots. <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
|
|
<option>set-default</option> and <option>set-oneshot</option> commands make use of these variables. The boot
|
|
loader modifies <varname>LoaderEntryDefault</varname> on request, when the <keycap>d</keycap> key is used, see
|
|
above.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>LoaderEntrySelected</varname></term>
|
|
|
|
<listitem><para>The identifier of the boot loader entry currently being booted. Set by the boot
|
|
loader.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>LoaderFeatures</varname></term>
|
|
|
|
<listitem><para>A set of flags indicating the features the boot loader supports. Set by the boot loader. Use
|
|
<citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this
|
|
data.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>LoaderFirmwareInfo</varname></term>
|
|
<term><varname>LoaderFirmwareType</varname></term>
|
|
|
|
<listitem><para>Brief firmware information. Set by the boot loader. Use
|
|
<citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this
|
|
data.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>LoaderImageIdentifier</varname></term>
|
|
|
|
<listitem><para>The path of executable of the boot loader used for the current boot, relative to the EFI System
|
|
Partition's root directory. Set by the boot loader. Use
|
|
<citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this
|
|
data.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>LoaderInfo</varname></term>
|
|
|
|
<listitem><para>Brief information about the boot loader. Set by the boot loader. Use
|
|
<citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this
|
|
data.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>LoaderTimeExecUSec</varname></term>
|
|
<term><varname>LoaderTimeInitUSec</varname></term>
|
|
<term><varname>LoaderTimeMenuUsec</varname></term>
|
|
|
|
<listitem><para>Information about the time spent in various parts of the boot loader. Set by the boot
|
|
loader. Use <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
to view this data. </para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>LoaderSystemToken</varname></term>
|
|
|
|
<listitem><para>A binary random data field, that is used for generating the random seed to pass to
|
|
the OS (see above). Note that this random data is generally only generated once, during OS
|
|
installation, and is then never updated again.</para></listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>Many of these variables are defined by the <ulink
|
|
url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Boot Counting</title>
|
|
|
|
<para><command>systemd-boot</command> implements a simple boot counting mechanism on top of the <ulink
|
|
url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink>, for automatic and unattended
|
|
fallback to older kernel versions/boot loader entries when a specific entry continuously fails. Any boot loader
|
|
entry file and unified kernel image file that contains a <literal>+</literal> followed by one or two numbers (if
|
|
two they need to be separated by a <literal>-</literal>), before the <filename>.conf</filename> or
|
|
<filename>.efi</filename> suffix is subject to boot counting: the first of the two numbers ('tries left') is
|
|
decreased by one on every boot attempt, the second of the two numbers ('tries done') is increased by one (if 'tries
|
|
done' is absent it is considered equivalent to 0). Depending on the current value of these two counters the boot
|
|
entry is considered to be in one of three states:</para>
|
|
|
|
<orderedlist>
|
|
<listitem><para>If the 'tries left' counter of an entry is greater than zero the entry is considered to be in
|
|
'indeterminate' state. This means the entry has not completed booting successfully yet, but also hasn't been
|
|
determined not to work.</para></listitem>
|
|
|
|
<listitem><para>If the 'tries left' counter of an entry is zero it is considered to be in 'bad' state. This means
|
|
no further attempts to boot this item will be made (that is, unless all other boot entries are also in 'bad'
|
|
state), as all attempts to boot this entry have not completed successfully.</para></listitem>
|
|
|
|
<listitem><para>If the 'tries left' and 'tries done' counters of an entry are absent it is considered to be in
|
|
'good' state. This means further boot counting for the entry is turned off, as it successfully booted at least
|
|
once. The
|
|
<citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
service moves the currently booted entry from 'indeterminate' into 'good' state when a boot attempt completed
|
|
successfully.</para></listitem>
|
|
</orderedlist>
|
|
|
|
<para>Generally, when new entries are added to the boot loader, they first start out in 'indeterminate' state,
|
|
i.e. with a 'tries left' counter greater than zero. The boot entry remains in this state until either it managed to
|
|
complete a full boot successfully at least once (in which case it will be in 'good' state) — or the 'tries left'
|
|
counter reaches zero (in which case it will be in 'bad' state).</para>
|
|
|
|
<para>Example: let's say a boot loader entry file <filename>foo.conf</filename> is set up for 3 boot tries. The
|
|
installer will hence create it under the name <filename>foo+3.conf</filename>. On first boot, the boot loader will
|
|
rename it to <filename>foo+2-1.conf</filename>. If that boot does not complete successfully, the boot loader will
|
|
rename it to <filename>foo+1-2.conf</filename> on the following boot. If that fails too, it will finally be renamed
|
|
<filename>foo+0-3.conf</filename> by the boot loader on next boot, after which it will be considered 'bad'. If the
|
|
boot succeeds however the entry file will be renamed to <filename>foo.conf</filename> by the OS, so that it is
|
|
considered 'good' from then on.</para>
|
|
|
|
<para>The boot menu takes the 'tries left' counter into account when sorting the menu entries: entries in 'bad'
|
|
state are ordered at the beginning of the list, and entries in 'good' or 'indeterminate' at the end. The user can
|
|
freely choose to boot any entry of the menu, including those already marked 'bad'. If the menu entry to boot is
|
|
automatically determined, this means that 'good' or 'indeterminate' entries are generally preferred (as the bottom
|
|
item of the menu is the one booted by default), and 'bad' entries will only be considered if there are no 'good' or
|
|
'indeterminate' entries left.</para>
|
|
|
|
<para>The <citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry> kernel
|
|
install framework optionally sets the initial 'tries left' counter to the value specified in
|
|
<filename>/etc/kernel/tries</filename> when a boot loader entry is first created.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Using systemd-boot in virtual machines.</title>
|
|
|
|
<para>When using qemu with OVMF (UEFI Firmware for virtual machines) the <option>-kernel</option> switch
|
|
works not only for linux kernels, but for any EFI binary, including sd-boot and unified linux
|
|
kernels. Example command line for loading sd-boot on x64:</para>
|
|
|
|
<para>
|
|
<command>qemu-system-x86_64 <replaceable>[ ... ]</replaceable>
|
|
-kernel /usr/lib/systemd/boot/efi/systemd-bootx64.efi</command>
|
|
</para>
|
|
|
|
<para>systemd-boot will detect that it was started directly instead of being loaded from ESP and will
|
|
search for the ESP in that case, taking into account boot order information from the hypervisor (if
|
|
available).</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
<para>
|
|
<citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>loader.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd-boot-random-seed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
|
|
<ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink>,
|
|
<ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>
|
|
</para>
|
|
</refsect1>
|
|
</refentry>
|