2018-07-03 00:15:39 +03:00
<?xml version='1.0'?>
2019-03-14 16:40:58 +03:00
< !DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
2023-12-25 17:48:33 +03:00
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
2020-11-09 07:23:58 +03:00
<!-- SPDX - License - Identifier: LGPL - 2.1 - or - later -->
2013-02-22 20:18:47 +04:00
2022-04-04 16:38:33 +03:00
<refentry id= "kernel-install" conditional= 'ENABLE_KERNEL_INSTALL'
2019-03-07 22:49:30 +03:00
xmlns:xi="http://www.w3.org/2001/XInclude">
2013-02-22 20:18:47 +04:00
<refentryinfo >
<title > kernel-install</title>
<productname > systemd</productname>
</refentryinfo>
<refmeta >
<refentrytitle > kernel-install</refentrytitle>
<manvolnum > 8</manvolnum>
</refmeta>
<refnamediv >
<refname > kernel-install</refname>
2024-06-19 15:41:55 +03:00
<refpurpose > Add and remove kernel and initrd images to and from the boot partition</refpurpose>
2013-02-22 20:18:47 +04:00
</refnamediv>
<refsynopsisdiv >
<cmdsynopsis >
2013-05-03 08:55:20 +04:00
<command > kernel-install</command>
2019-03-07 22:49:30 +03:00
<arg choice= "opt" rep= "repeat" > OPTIONS</arg>
2023-03-18 09:51:37 +03:00
<arg choice= "plain" > add</arg>
2013-05-03 08:55:20 +04:00
<arg choice= "plain" > <replaceable > KERNEL-VERSION</replaceable> </arg>
2018-12-29 22:01:10 +03:00
<arg choice= "plain" > <replaceable > KERNEL-IMAGE</replaceable> </arg>
2019-01-17 21:06:09 +03:00
<arg choice= "opt" rep= "repeat" > <replaceable > INITRD-FILE</replaceable> </arg>
2013-02-22 20:18:47 +04:00
</cmdsynopsis>
2024-03-08 14:30:30 +03:00
<cmdsynopsis >
<command > kernel-install</command>
<arg choice= "opt" rep= "repeat" > OPTIONS</arg>
<arg choice= "plain" > add-all</arg>
</cmdsynopsis>
2023-03-18 09:51:37 +03:00
<cmdsynopsis >
<command > kernel-install</command>
<arg choice= "opt" rep= "repeat" > OPTIONS</arg>
<arg choice= "plain" > remove</arg>
<arg choice= "plain" > <replaceable > KERNEL-VERSION</replaceable> </arg>
</cmdsynopsis>
<cmdsynopsis >
<command > kernel-install</command>
<arg choice= "opt" rep= "repeat" > OPTIONS</arg>
<arg choice= "plain" > inspect</arg>
2023-10-23 12:18:35 +03:00
<arg choice= "opt" > <replaceable > KERNEL-VERSION</replaceable> </arg>
2023-03-19 17:43:16 +03:00
<arg choice= "opt" > <replaceable > KERNEL-IMAGE</replaceable> </arg>
2023-10-23 12:18:35 +03:00
<arg choice= "opt" rep= "repeat" > <replaceable > INITRD-FILE</replaceable> </arg>
2023-03-18 09:51:37 +03:00
</cmdsynopsis>
2023-11-06 12:30:58 +03:00
<cmdsynopsis >
<command > kernel-install</command>
<arg choice= "opt" rep= "repeat" > OPTIONS</arg>
<arg choice= "plain" > list</arg>
</cmdsynopsis>
2013-02-22 20:18:47 +04:00
</refsynopsisdiv>
<refsect1 >
<title > Description</title>
man: "the initial RAM disk" → "the initrd"
In many places we spelled out the phrase behind "initrd" in full, but this
isn't terribly useful. In fact, no "RAM disk" is used, so emphasizing this
is just confusing to the reader. Let's just say "initrd" everywhere, people
understand what this refers to, and that it's in fact an initramfs image.
Also, s/i.e./e.g./ where appropriate.
Also, don't say "in RAM", when in fact it's virtual memory, whose pages
may or may not be loaded in page frames in RAM, and we have no control over
this.
Also, add <filename></filename> and other minor cleanups.
2022-09-15 15:43:59 +03:00
<para > <command > kernel-install</command> is used to install and remove kernel and initrd images
<footnote >
<para > Nowadays actually CPIO archives used as an "initramfs", rather than "initrd". See
<citerefentry > <refentrytitle > bootup</refentrytitle> <manvolnum > 7</manvolnum> </citerefentry> for an
explanation.</para>
</footnote>
2024-06-19 15:41:55 +03:00
to and from the boot partition, referred to as <varname > $BOOT</varname> here. It will usually be one of
<filename > /boot/</filename> , <filename > /efi/</filename> , or <filename > /boot/efi/</filename> , see below.
</para>
2013-02-22 20:18:47 +04:00
2022-02-10 17:27:45 +03:00
<para > <command > kernel-install</command> will run the executable files ("plugins") located in the
directory <filename > /usr/lib/kernel/install.d/</filename> and the local administration directory
<filename > /etc/kernel/install.d/</filename> . All files are collectively sorted and executed in lexical
order, regardless of the directory in which they live. However, files with identical filenames replace
each other. Files in <filename > /etc/kernel/install.d/</filename> take precedence over files with the
same name in <filename > /usr/lib/kernel/install.d/</filename> . This can be used to override a
system-supplied executables with a local file if needed; a symbolic link in
<filename > /etc/kernel/install.d/</filename> with the same name as an executable in
<filename > /usr/lib/kernel/install.d/</filename> , pointing to <filename > /dev/null</filename> , disables the
executable entirely. Executables must have the extension <literal > .install</literal> ; other extensions
are ignored.</para>
<para > An executable placed in these directories should return <constant > 0</constant> on success. It may
also return <constant > 77</constant> to cause the whole operation to terminate (executables later in
lexical order will be skipped).</para>
2013-02-22 20:18:47 +04:00
</refsect1>
<refsect1 >
<title > Commands</title>
<para > The following commands are understood:</para>
<variablelist >
<varlistentry >
2023-09-07 13:29:38 +03:00
<term >
2023-11-06 12:47:10 +03:00
<command > add [[[<replaceable > KERNEL-VERSION</replaceable> ] <replaceable > KERNEL-IMAGE</replaceable> ] [<replaceable > INITRD-FILE</replaceable> ...]]</command>
2023-09-07 13:29:38 +03:00
</term>
2013-02-22 20:18:47 +04:00
<listitem >
2023-11-06 12:47:10 +03:00
<para > This command takes a kernel version string and a path to a kernel image file as arguments. If
the former is omitted, specified as an empty string or as "-" it defaults to the current kernel
version, i.e. the same string <command > uname -r</command> returns. If the latter is omitted,
specified as an empty string or as "-" defaults to
<filename > /usr/lib/modules/<replaceable > KERNEL_VERSION</replaceable> /vmlinuz</filename> . Optionally,
one or more initrd images may be specified as well (note that plugins might generate additional
ones).</para>
2023-09-07 13:29:38 +03:00
<para > The executable files from <filename > /usr/lib/kernel/install.d/*.install</filename> and
<filename > /etc/kernel/install.d/*.install</filename> (i.e. the plugins) are called with the
following arguments:</para>
2018-06-22 19:14:22 +03:00
2023-09-07 13:29:38 +03:00
<programlisting > add <replaceable > KERNEL-VERSION</replaceable> <filename > $BOOT/<replaceable > ENTRY-TOKEN</replaceable> /<replaceable > KERNEL-VERSION</replaceable> /</filename> <replaceable > KERNEL-IMAGE</replaceable> \
[<replaceable > INITRD-FILE</replaceable> ...]</programlisting>
2022-02-10 17:27:45 +03:00
man: "the initial RAM disk" → "the initrd"
In many places we spelled out the phrase behind "initrd" in full, but this
isn't terribly useful. In fact, no "RAM disk" is used, so emphasizing this
is just confusing to the reader. Let's just say "initrd" everywhere, people
understand what this refers to, and that it's in fact an initramfs image.
Also, s/i.e./e.g./ where appropriate.
Also, don't say "in RAM", when in fact it's virtual memory, whose pages
may or may not be loaded in page frames in RAM, and we have no control over
this.
Also, add <filename></filename> and other minor cleanups.
2022-09-15 15:43:59 +03:00
<para > The third argument directly refers to the path where to place kernel images, initrd
2023-09-07 13:29:38 +03:00
images and other resources for
<ulink url= "https://uapi-group.org/specifications/specs/boot_loader_specification" > Boot
2022-02-10 17:27:45 +03:00
Loader Specification</ulink> Type #1 entries (the "entry directory"). If other boot loader schemes
2023-09-07 13:29:38 +03:00
are used the parameter may be ignored.</para>
<para > The <replaceable > ENTRY-TOKEN</replaceable> string is typically the machine ID and is supposed
to identify the local installation on the system. For details see below.</para>
2013-05-03 08:55:20 +04:00
kernel-install: replace 00-entry-directory with K_I_LAYOUT in k-i
341890de866f2ee34919a47ce3fc6c8cd3c1924c made "bootctl install" create
ESP\MID, in preparation of cf73f650890b56a59bfb713c4c82b4e29daa7316 that
followed it and created 00-entry-directory.install to make ESP\MID\KVER
if ESP\MID existed ‒ this meant that "bootctl install" followed by
"kernel-install $(uname -r) /boot/vml*$(uname -r) /boot/ini*$(uname -r)"
actually installed the kernel correctly.
Later, 31e57550b552e113bd3d44355b237c41e42beb58 reverted the first
commit, meaning, that now running those two commands first installs
sd-boot, but then does nothing. Everything appears to work right,
nothing errors out, but no changes are actually done. To the untrained
eye (all of them), even running with -v appears to work:
all the hooks are run, as is depmod, but, again, nothing happens.
This is horrible. Nothing in either manpage suggests what to do
(nor should it, really), but the user is left with a bootloader that
appears fully funxional, since nothing suggests a failure in the output,
but with an unbootable machine, /no way to boot it/, even if they drop
to an EFI shell, since the boot bundle isn't present on the ESP,
and no real recourse even if they boot into a recovery system,
apart from installing like GRUB or whatever.
00- is purely instrumentation for 90-,
and separating one from the other has led to downstream dissatisfaxion
(indeed, the last mentioned commit cited cited exactly that as the
reversion reason), while creating $ENTRY_DIR_ABS is only required
for bootloaders using the BLS, and shouldn't itself toggle anything.
To that end, introduce an /{e,l}/k/install.conf file that allows
overriding the detected layout, and detect it as "bls" if
$BOOT_ROOT/$MACHINE_ID ($ENTRY_DIR_ABS/..) exists, otherwise "other" ‒
if a user wishes to select a different bootloader,
like GRUB, they (or, indeed, the postinst script) can specify
layout=grub. This disables 90- and $ENTRY_DIR_ABS manipulation.
2021-03-16 18:47:34 +03:00
<para > Two default plugins execute the following operations in this case:</para>
2018-06-22 19:14:22 +03:00
<itemizedlist >
kernel-install: replace 00-entry-directory with K_I_LAYOUT in k-i
341890de866f2ee34919a47ce3fc6c8cd3c1924c made "bootctl install" create
ESP\MID, in preparation of cf73f650890b56a59bfb713c4c82b4e29daa7316 that
followed it and created 00-entry-directory.install to make ESP\MID\KVER
if ESP\MID existed ‒ this meant that "bootctl install" followed by
"kernel-install $(uname -r) /boot/vml*$(uname -r) /boot/ini*$(uname -r)"
actually installed the kernel correctly.
Later, 31e57550b552e113bd3d44355b237c41e42beb58 reverted the first
commit, meaning, that now running those two commands first installs
sd-boot, but then does nothing. Everything appears to work right,
nothing errors out, but no changes are actually done. To the untrained
eye (all of them), even running with -v appears to work:
all the hooks are run, as is depmod, but, again, nothing happens.
This is horrible. Nothing in either manpage suggests what to do
(nor should it, really), but the user is left with a bootloader that
appears fully funxional, since nothing suggests a failure in the output,
but with an unbootable machine, /no way to boot it/, even if they drop
to an EFI shell, since the boot bundle isn't present on the ESP,
and no real recourse even if they boot into a recovery system,
apart from installing like GRUB or whatever.
00- is purely instrumentation for 90-,
and separating one from the other has led to downstream dissatisfaxion
(indeed, the last mentioned commit cited cited exactly that as the
reversion reason), while creating $ENTRY_DIR_ABS is only required
for bootloaders using the BLS, and shouldn't itself toggle anything.
To that end, introduce an /{e,l}/k/install.conf file that allows
overriding the detected layout, and detect it as "bls" if
$BOOT_ROOT/$MACHINE_ID ($ENTRY_DIR_ABS/..) exists, otherwise "other" ‒
if a user wishes to select a different bootloader,
like GRUB, they (or, indeed, the postinst script) can specify
layout=grub. This disables 90- and $ENTRY_DIR_ABS manipulation.
2021-03-16 18:47:34 +03:00
<listitem > <para > <command > kernel-install</command> creates
2022-02-10 17:27:45 +03:00
<filename > $BOOT/<replaceable > ENTRY-TOKEN</replaceable> /<replaceable > KERNEL-VERSION</replaceable> </filename> ,
if enabled (see <varname > $KERNEL_INSTALL_LAYOUT</varname> ).</para> </listitem>
2018-06-22 19:14:22 +03:00
<listitem > <para > <filename > 50-depmod.install</filename> runs
2020-06-25 15:37:24 +03:00
<citerefentry project= 'man-pages' > <refentrytitle > depmod</refentrytitle> <manvolnum > 8</manvolnum> </citerefentry> for the
2018-06-22 19:14:22 +03:00
<replaceable > KERNEL-VERSION</replaceable> .</para> </listitem>
2022-02-10 17:27:45 +03:00
<listitem > <para > <filename > 90-loaderentry.install</filename> copies
<replaceable > KERNEL-IMAGE</replaceable> to
<filename > $BOOT/<replaceable > ENTRY-TOKEN</replaceable> /<replaceable > KERNEL-VERSION</replaceable> /linux</filename> .
kernel-install: replace 00-entry-directory with K_I_LAYOUT in k-i
341890de866f2ee34919a47ce3fc6c8cd3c1924c made "bootctl install" create
ESP\MID, in preparation of cf73f650890b56a59bfb713c4c82b4e29daa7316 that
followed it and created 00-entry-directory.install to make ESP\MID\KVER
if ESP\MID existed ‒ this meant that "bootctl install" followed by
"kernel-install $(uname -r) /boot/vml*$(uname -r) /boot/ini*$(uname -r)"
actually installed the kernel correctly.
Later, 31e57550b552e113bd3d44355b237c41e42beb58 reverted the first
commit, meaning, that now running those two commands first installs
sd-boot, but then does nothing. Everything appears to work right,
nothing errors out, but no changes are actually done. To the untrained
eye (all of them), even running with -v appears to work:
all the hooks are run, as is depmod, but, again, nothing happens.
This is horrible. Nothing in either manpage suggests what to do
(nor should it, really), but the user is left with a bootloader that
appears fully funxional, since nothing suggests a failure in the output,
but with an unbootable machine, /no way to boot it/, even if they drop
to an EFI shell, since the boot bundle isn't present on the ESP,
and no real recourse even if they boot into a recovery system,
apart from installing like GRUB or whatever.
00- is purely instrumentation for 90-,
and separating one from the other has led to downstream dissatisfaxion
(indeed, the last mentioned commit cited cited exactly that as the
reversion reason), while creating $ENTRY_DIR_ABS is only required
for bootloaders using the BLS, and shouldn't itself toggle anything.
To that end, introduce an /{e,l}/k/install.conf file that allows
overriding the detected layout, and detect it as "bls" if
$BOOT_ROOT/$MACHINE_ID ($ENTRY_DIR_ABS/..) exists, otherwise "other" ‒
if a user wishes to select a different bootloader,
like GRUB, they (or, indeed, the postinst script) can specify
layout=grub. This disables 90- and $ENTRY_DIR_ABS manipulation.
2021-03-16 18:47:34 +03:00
If <replaceable > INITRD-FILE</replaceable> s are provided, it also copies them to
2022-02-10 17:27:45 +03:00
<filename > $BOOT/<replaceable > ENTRY-TOKEN</replaceable> /<replaceable > KERNEL_VERSION</replaceable> /<replaceable > INITRD-FILE</replaceable> </filename> .
2023-06-19 18:31:58 +03:00
This can also be used to prepend microcode before the actual initrd. It also creates a boot loader entry according to the <ulink
2022-11-14 11:44:39 +03:00
url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> (Type #1) in
2022-02-10 17:27:45 +03:00
<filename > $BOOT/loader/entries/<replaceable > ENTRY-TOKEN</replaceable> -<replaceable > KERNEL-VERSION</replaceable> .conf</filename> .
2018-06-22 19:14:22 +03:00
The title of the entry is the <replaceable > PRETTY_NAME</replaceable> parameter specified in
2022-02-10 17:27:45 +03:00
<filename > /etc/os-release</filename> or <filename > /usr/lib/os-release</filename> (if the former
is missing), or "Linux <replaceable > KERNEL-VERSION</replaceable> ", if unset.</para>
2019-03-07 23:18:56 +03:00
2022-02-10 17:27:45 +03:00
<para > If <varname > $KERNEL_INSTALL_LAYOUT</varname> is not "bls", this plugin does nothing.</para> </listitem>
2022-11-23 18:43:19 +03:00
<listitem > <para > <filename > 90-uki-copy.install</filename> copies a file
<filename > uki.efi</filename> from <varname > $KERNEL_INSTALL_STAGING_AREA</varname> or if it does
2023-01-25 15:57:09 +03:00
not exist the <replaceable > KERNEL-IMAGE</replaceable> argument, only if it has a
2022-11-23 18:43:19 +03:00
<literal > .efi</literal> extension, to
<filename > $BOOT/EFI/Linux/<replaceable > ENTRY-TOKEN</replaceable> -<replaceable > KERNEL-VERSION</replaceable> .efi</filename> .</para>
<para > If <varname > $KERNEL_INSTALL_LAYOUT</varname> is not "uki", this plugin does nothing.</para> </listitem>
2018-06-22 19:14:22 +03:00
</itemizedlist>
2023-08-22 19:52:36 +03:00
2023-09-18 18:03:38 +03:00
<xi:include href= "version-info.xml" xpointer= "v198" />
2013-02-22 20:18:47 +04:00
</listitem>
</varlistentry>
2023-11-06 13:34:11 +03:00
<varlistentry >
<term >
<command > add-all</command>
</term>
<listitem >
<para > This is the same as <command > add</command> (see above), but invokes the operation iteratively
for every installed kernel in <filename > /usr/lib/modules/</filename> . This operation is only
supported on systems where the kernel image is installed in
<filename > /usr/lib/modules/<replaceable > KERNEL-VERSION</replaceable> /vmlinuz</filename> .</para>
<xi:include href= "version-info.xml" xpointer= "v255" />
</listitem>
</varlistentry>
2013-02-22 20:18:47 +04:00
<varlistentry >
2013-04-30 20:01:47 +04:00
<term > <command > remove <replaceable > KERNEL-VERSION</replaceable> </command> </term>
2013-05-03 08:55:20 +04:00
<listitem >
2023-09-07 13:29:38 +03:00
<para > This command expects a kernel version string as single argument.</para>
<para > The executable files from <filename > /usr/lib/kernel/install.d/*.install</filename> and
<filename > /etc/kernel/install.d/*.install</filename> (i.e. the plugins) are called with the
following arguments:</para>
2013-05-03 08:55:20 +04:00
2022-02-10 17:27:45 +03:00
<programlisting > remove <replaceable > KERNEL-VERSION</replaceable> <filename > $BOOT/<replaceable > ENTRY-TOKEN</replaceable> /<replaceable > KERNEL-VERSION</replaceable> /</filename> </programlisting>
<para > Afterwards, <command > kernel-install</command> removes the entry directory
<filename > $BOOT/<replaceable > ENTRY-TOKEN</replaceable> /<replaceable > KERNEL-VERSION</replaceable> /</filename>
and its contents, if it exists.</para>
2018-06-22 19:14:22 +03:00
<para > Two default plugins execute the following operations in this case:</para>
<itemizedlist >
2023-09-07 13:29:38 +03:00
<listitem > <para > <filename > 50-depmod.install</filename> removes the files generated by
<command > depmod</command> for this kernel again.</para> </listitem>
2018-06-22 19:14:22 +03:00
<listitem > <para > <filename > 90-loaderentry.install</filename> removes the file
2023-09-07 13:29:38 +03:00
<filename > $BOOT/loader/entries/<replaceable > ENTRY-TOKEN</replaceable> -<replaceable > KERNEL-VERSION</replaceable> .conf</filename> .
</para> </listitem>
2022-11-23 18:43:19 +03:00
<listitem > <para > <filename > 90-uki-copy.install</filename> removes the file
2023-09-07 13:29:38 +03:00
<filename > $BOOT/EFI/Linux/<replaceable > ENTRY-TOKEN</replaceable> -<replaceable > KERNEL-VERSION</replaceable> .efi</filename> .
</para> </listitem>
kernel-install: replace 00-entry-directory with K_I_LAYOUT in k-i
341890de866f2ee34919a47ce3fc6c8cd3c1924c made "bootctl install" create
ESP\MID, in preparation of cf73f650890b56a59bfb713c4c82b4e29daa7316 that
followed it and created 00-entry-directory.install to make ESP\MID\KVER
if ESP\MID existed ‒ this meant that "bootctl install" followed by
"kernel-install $(uname -r) /boot/vml*$(uname -r) /boot/ini*$(uname -r)"
actually installed the kernel correctly.
Later, 31e57550b552e113bd3d44355b237c41e42beb58 reverted the first
commit, meaning, that now running those two commands first installs
sd-boot, but then does nothing. Everything appears to work right,
nothing errors out, but no changes are actually done. To the untrained
eye (all of them), even running with -v appears to work:
all the hooks are run, as is depmod, but, again, nothing happens.
This is horrible. Nothing in either manpage suggests what to do
(nor should it, really), but the user is left with a bootloader that
appears fully funxional, since nothing suggests a failure in the output,
but with an unbootable machine, /no way to boot it/, even if they drop
to an EFI shell, since the boot bundle isn't present on the ESP,
and no real recourse even if they boot into a recovery system,
apart from installing like GRUB or whatever.
00- is purely instrumentation for 90-,
and separating one from the other has led to downstream dissatisfaxion
(indeed, the last mentioned commit cited cited exactly that as the
reversion reason), while creating $ENTRY_DIR_ABS is only required
for bootloaders using the BLS, and shouldn't itself toggle anything.
To that end, introduce an /{e,l}/k/install.conf file that allows
overriding the detected layout, and detect it as "bls" if
$BOOT_ROOT/$MACHINE_ID ($ENTRY_DIR_ABS/..) exists, otherwise "other" ‒
if a user wishes to select a different bootloader,
like GRUB, they (or, indeed, the postinst script) can specify
layout=grub. This disables 90- and $ENTRY_DIR_ABS manipulation.
2021-03-16 18:47:34 +03:00
</itemizedlist>
2023-08-22 19:52:36 +03:00
2023-09-18 18:03:38 +03:00
<xi:include href= "version-info.xml" xpointer= "v198" />
2013-02-22 20:18:47 +04:00
</listitem>
</varlistentry>
2022-02-10 17:27:45 +03:00
<varlistentry >
2023-10-23 12:18:35 +03:00
<term >
2023-11-06 20:25:46 +03:00
<command > inspect [[[<replaceable > KERNEL-VERSION</replaceable> ] <replaceable > KERNEL-IMAGE</replaceable> ] [<replaceable > INITRD-FILE</replaceable> ...]]</command>
2023-10-23 12:18:35 +03:00
</term>
2022-02-10 17:27:45 +03:00
<listitem >
2023-11-06 20:25:46 +03:00
<para > Takes the same parameters as <command > add</command> .</para>
2022-02-10 17:27:45 +03:00
<para > Shows the various paths and parameters configured or auto-detected. In particular shows the
2023-11-06 20:25:46 +03:00
values of the various <varname > $KERNEL_INSTALL_*</varname> environment variables listed below, as
they would be passed to plugins. The <option > --json</option> option can be used to get the output
of this verb as a JSON object.</para>
2023-08-22 19:52:36 +03:00
2023-09-18 18:03:38 +03:00
<xi:include href= "version-info.xml" xpointer= "v251" />
2022-02-10 17:27:45 +03:00
</listitem>
</varlistentry>
2023-11-06 12:30:58 +03:00
<varlistentry >
<term > <command > list</command> </term>
<listitem >
<para > Shows the various installed kernels. This enumerates the subdirectories of
<filename > /usr/lib/modules/</filename> , and shows whether a kernel image is installed there.</para>
<xi:include href= "version-info.xml" xpointer= "v255" />
</listitem>
</varlistentry>
2013-02-22 20:18:47 +04:00
</variablelist>
2019-03-08 21:21:54 +03:00
</refsect1>
2013-02-22 20:18:47 +04:00
2023-09-26 22:54:18 +03:00
<refsect1 >
<title > Compatibility with the kernel build system</title>
<cmdsynopsis >
<command > installkernel</command>
<arg choice= "opt" rep= "repeat" > OPTIONS</arg>
<arg choice= "plain" > VERSION</arg>
<arg choice= "plain" > VMLINUZ</arg>
<arg choice= "opt" > MAP</arg>
<arg choice= "opt" > INSTALLATION-DIR</arg>
</cmdsynopsis>
<para > When invoked as <command > installkernel</command> , this program accepts arguments as specified by
the kernel build system's <command > make install</command> command. The <parameter > VERSION</parameter> and
<parameter > VMLINUZ</parameter> parameters specify the kernel version and the kernel binary. The other two
parameters (<parameter > MAP</parameter> and <parameter > INSTALLATION-DIR</parameter> ) are currently
ignored.
</para>
</refsect1>
2019-03-08 21:21:54 +03:00
<refsect1 >
<title > The <varname > $BOOT</varname> partition</title>
2022-07-01 11:52:12 +03:00
2022-11-14 11:44:39 +03:00
<para > The partition where the kernels and <ulink url= "https://uapi-group.org/specifications/specs/boot_loader_specification" > Boot
2019-03-08 21:21:54 +03:00
Loader Specification</ulink> snippets are located is called <varname > $BOOT</varname> .
<command > kernel-install</command> determines the location of this partition by checking
2022-02-10 17:27:45 +03:00
<filename > /efi/</filename> , <filename > /boot/</filename> , and <filename > /boot/efi/</filename> in turn. The
first location where <filename > $BOOT/loader/entries/</filename> or
<filename > $BOOT/<replaceable > ENTRY-TOKEN</replaceable> /</filename> exists is used.</para>
2013-02-22 20:18:47 +04:00
</refsect1>
2019-03-07 22:49:30 +03:00
<refsect1 >
<title > Options</title>
<para > The following options are understood:</para>
<variablelist >
2023-03-19 20:55:56 +03:00
<xi:include href= "standard-options.xml" xpointer= "esp-path" />
<xi:include href= "standard-options.xml" xpointer= "boot-path" />
2023-03-26 08:57:10 +03:00
<varlistentry >
<term > <option > --make-entry-directory=yes|no|auto</option> </term>
<listitem >
<para > Controls creation and deletion of the
<ulink url= "https://uapi-group.org/specifications/specs/boot_loader_specification" > Boot Loader Specification</ulink>
Type #1 entry directory on the file system containing resources such as kernel and initrd images
during <option > add</option> and <option > remove</option> , respectively. The directory is named after
the entry token, and is placed immediately below the boot root directory. When
<literal > auto</literal> , the directory is created or removed only when the install layout is
<literal > bls</literal> . Defaults to <literal > auto</literal> .</para>
2023-08-22 19:52:36 +03:00
<xi:include href= "version-info.xml" xpointer= "v254" />
2023-03-26 08:57:10 +03:00
</listitem>
</varlistentry>
2023-03-26 10:34:29 +03:00
<varlistentry >
<term > <option > --entry-token=</option> </term>
<listitem >
<para > Controls how to name and identify boot loader entries for this kernel installation or
deletion. Takes one of <literal > auto</literal> , <literal > machine-id</literal> ,
<literal > os-id</literal> , <literal > os-image-id</literal> , or an arbitrary string prefixed by
<literal > literal:</literal> as argument.</para>
<para > If set to <option > machine-id</option> the entries are named after the machine ID of the
running system (e.g. <literal > b0e793a9baf14b5fa13ecbe84ff637ac</literal> ). See
<citerefentry > <refentrytitle > machine-id</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> for
details about the machine ID concept and file.</para>
<para > If set to <option > os-id</option> the entries are named after the OS ID of the running system,
i.e. the <varname > ID=</varname> field of
<citerefentry > <refentrytitle > os-release</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
(e.g. <literal > fedora</literal> ). Similarly, if set to <option > os-image-id</option> the entries are
named after the OS image ID of the running system, i.e. the <varname > IMAGE_ID=</varname> field of
<filename > os-release</filename> (e.g. <literal > vendorx-cashier-system</literal> ).</para>
<para > If set to <option > auto</option> (the default), the
<filename > /etc/kernel/entry-token</filename> (or
<filename > $KERNEL_INSTALL_CONF_ROOT/entry-token</filename> ) file will be read if it exists, and the
stored value used. Otherwise if the local machine ID is initialized it is used. Otherwise
<varname > IMAGE_ID=</varname> from <filename > os-release</filename> will be used, if set. Otherwise,
<varname > ID=</varname> from <filename > os-release</filename> will be used, if set. Otherwise a
randomly generated machine ID is used.</para>
<para > Using the machine ID for naming the entries is generally preferable, however there are cases
where using the other identifiers is a good option. Specifically: if the identification data that
the machine ID entails shall not be stored on the (unencrypted) <varname > $BOOT_ROOT</varname>
partition, or if the ID shall be generated on first boot and is not known when the entries are
prepared. Note that using the machine ID has the benefit that multiple parallel installations of
the same OS can coexist on the same medium, and they can update their boot loader entries
independently. When using another identifier (such as the OS ID or the OS image ID), parallel
installations of the same OS would try to use the same entry name. To support parallel
installations, the installer must use a different entry token when adding a second installation.
</para>
2023-08-22 19:52:36 +03:00
<xi:include href= "version-info.xml" xpointer= "v254" />
2023-03-26 10:34:29 +03:00
</listitem>
</varlistentry>
2019-03-07 22:49:30 +03:00
<varlistentry >
<term > <option > -v</option> </term>
<term > <option > --verbose</option> </term>
<listitem >
<para > Output additional information about operations being performed.</para>
2023-08-22 19:52:36 +03:00
<xi:include href= "version-info.xml" xpointer= "v242" />
2019-03-07 22:49:30 +03:00
</listitem>
</varlistentry>
2023-10-25 10:57:44 +03:00
<varlistentry >
<term > <option > --root=<replaceable > root</replaceable> </option> </term>
<listitem > <para > Takes a directory path as an argument. All paths will be prefixed with the given
alternate <replaceable > root</replaceable> path, including config search paths. This is useful to
operate on a system image mounted to the specified directory instead of the host system
itself.</para>
<xi:include href= "version-info.xml" xpointer= "v255" /> </listitem>
</varlistentry>
<varlistentry >
<term > <option > --image=<replaceable > image</replaceable> </option> </term>
<listitem > <para > Takes a path to a disk image file or block device node. If specified, all operations
are applied to the file system in the indicated disk image. This option is similar to
<option > --root=</option> , but operates on file systems stored in disk images or block devices. The
disk image should either contain just a file system or a set of file systems within a GPT partition
table, following the <ulink url= "https://uapi-group.org/specifications/specs/discoverable_partitions_specification" > Discoverable Partitions
Specification</ulink> . For further information on supported disk images, see
<citerefentry > <refentrytitle > systemd-nspawn</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> 's
switch of the same name.</para>
<xi:include href= "version-info.xml" xpointer= "v255" /> </listitem>
</varlistentry>
2019-03-07 22:49:30 +03:00
<xi:include href= "standard-options.xml" xpointer= "help" />
2022-04-05 19:18:56 +03:00
<xi:include href= "standard-options.xml" xpointer= "version" />
2023-10-23 12:18:35 +03:00
<xi:include href= "standard-options.xml" xpointer= "no-pager" />
<xi:include href= "standard-options.xml" xpointer= "json" />
2023-10-25 10:57:44 +03:00
<xi:include href= "standard-options.xml" xpointer= "image-policy-open" />
2023-11-06 12:30:58 +03:00
<xi:include href= "standard-options.xml" xpointer= "no-legend" />
2019-03-07 22:49:30 +03:00
</variablelist>
</refsect1>
<refsect1 >
<title > Environment variables</title>
2021-03-16 19:38:20 +03:00
2022-07-01 11:52:12 +03:00
<refsect2 >
<title > Environment variables exported for plugins</title>
<para > If <option > --verbose</option> is used, <varname > $KERNEL_INSTALL_VERBOSE=1</varname> will be
exported for plugins. They may output additional logs in this case.</para>
2023-09-20 10:35:37 +03:00
<para > <varname > $KERNEL_INSTALL_IMAGE_TYPE=uki|pe|unknown</varname> is set for the plugins to specify the
type of the kernel image.</para>
<variablelist >
<varlistentry >
<term > uki</term>
<listitem >
<para > Unified kernel image.</para>
<xi:include href= "version-info.xml" xpointer= "v254" />
</listitem>
</varlistentry>
<varlistentry >
<term > pe</term>
<listitem >
<para > PE binary.</para>
<xi:include href= "version-info.xml" xpointer= "v254" />
</listitem>
</varlistentry>
<varlistentry >
<term > unknown</term>
<listitem >
<para > Unknown type.</para>
<xi:include href= "version-info.xml" xpointer= "v254" />
</listitem>
</varlistentry>
</variablelist>
2022-07-01 11:52:12 +03:00
<para > <varname > $KERNEL_INSTALL_MACHINE_ID</varname> is set for the plugins to the desired machine-id to
use. It's always a 128-bit ID. Normally it's read from <filename > /etc/machine-id</filename> , but it can
man: fix issues reported by the manpage-l10n project
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.
2023-01-11 18:45:59 +03:00
also be overridden via <varname > $MACHINE_ID</varname> (see below). If not specified via these methods,
a fallback value will generated by <command > kernel-install</command> and used only for a single
2022-07-01 11:52:12 +03:00
invocation.</para>
<para > <varname > $KERNEL_INSTALL_ENTRY_TOKEN</varname> is set for the plugins to the desired entry
"token" to use. It's an identifier that shall be used to identify the local installation, and is often
the machine ID, i.e. same as <varname > $KERNEL_INSTALL_MACHINE_ID</varname> , but might also be a
different type of identifier, for example a fixed string or the <varname > ID=</varname> ,
<varname > IMAGE_ID=</varname> values from <filename > /etc/os-release</filename> . The string passed here
will be used to name Boot Loader Specification entries, or the directories the kernel image and initial
RAM disk images are placed into.</para>
<para > Note that while <varname > $KERNEL_INSTALL_ENTRY_TOKEN</varname> and
<varname > $KERNEL_INSTALL_MACHINE_ID</varname> are often set to the same value, the latter is guaranteed
to be a valid 32 character ID in lowercase hexadecimals while the former can be any short string. The
entry token to use is read from <filename > /etc/kernel/entry-token</filename> , if it exists. Otherwise a
few possible candidates below <varname > $BOOT</varname> are checked for Boot Loader Specification Type 1
entry directories, and if found the entry token is derived from that. If that is not successful,
<varname > $KERNEL_INSTALL_MACHINE_ID</varname> is used as fallback.</para>
<para > <varname > $KERNEL_INSTALL_BOOT_ROOT</varname> is set for the plugins to the absolute path of the
root directory (mount point, usually) of the hierarchy where boot loader entries, kernel images, and
associated resources should be placed. This usually is the path where the XBOOTLDR partition or the ESP
(EFI System Partition) are mounted, and also conceptually referred to as <varname > $BOOT</varname> . Can
be overridden by setting <varname > $BOOT_ROOT</varname> (see below).</para>
2023-01-20 11:05:18 +03:00
<para > <varname > $KERNEL_INSTALL_LAYOUT=auto|bls|uki|other|...</varname> is set for the plugins to specify the
installation layout. Additional layout names may be defined by convention. If a plugin uses a special layout,
2022-07-01 11:52:12 +03:00
it's encouraged to declare its own layout name and configure <varname > layout=</varname> in
<filename > install.conf</filename> upon initial installation. The following values are currently
understood:</para>
<variablelist >
<varlistentry >
<term > bls</term>
<listitem >
2022-11-14 11:44:39 +03:00
<para > Standard <ulink url= "https://uapi-group.org/specifications/specs/boot_loader_specification" > Boot Loader
2022-07-01 11:52:12 +03:00
Specification</ulink> Type #1 layout, compatible with
<citerefentry > <refentrytitle > systemd-boot</refentrytitle> <manvolnum > 7</manvolnum> </citerefentry> :
entries in
<filename > $BOOT/loader/entries/<replaceable > ENTRY-TOKEN</replaceable> -<replaceable > KERNEL-VERSION</replaceable> [+<replaceable > TRIES</replaceable> ].conf</filename> ,
kernel and initrds under
<filename > $BOOT/<replaceable > ENTRY-TOKEN</replaceable> /<replaceable > KERNEL-VERSION</replaceable> /</filename> </para>
<para > Implemented by <filename > 90-loaderentry.install</filename> .</para>
2023-09-18 18:03:38 +03:00
<xi:include href= "version-info.xml" xpointer= "v250" />
2022-07-01 11:52:12 +03:00
</listitem>
</varlistentry>
2022-11-23 18:43:19 +03:00
<varlistentry >
<term > uki</term>
<listitem >
<para > Standard <ulink
url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader
Specification</ulink> Type #2 layout, compatible with
<citerefentry > <refentrytitle > systemd-boot</refentrytitle> <manvolnum > 7</manvolnum> </citerefentry> :
unified kernel images under <filename > $BOOT/EFI/Linux</filename> as
<filename > $BOOT/EFI/Linux/<replaceable > ENTRY-TOKEN</replaceable> -<replaceable > KERNEL-VERSION</replaceable> [+<replaceable > TRIES</replaceable> ].efi</filename> .</para>
<para > Implemented by <filename > 90-uki-copy.install</filename> .</para>
2023-08-22 19:52:36 +03:00
<xi:include href= "version-info.xml" xpointer= "v253" />
2022-11-23 18:43:19 +03:00
</listitem>
</varlistentry>
2022-07-01 11:52:12 +03:00
<varlistentry >
<term > other</term>
<listitem >
<para > Some other layout not understood natively by <command > kernel-install</command> .</para>
2023-09-18 18:03:38 +03:00
<xi:include href= "version-info.xml" xpointer= "v250" />
2022-07-01 11:52:12 +03:00
</listitem>
</varlistentry>
2023-01-20 11:05:18 +03:00
<varlistentry >
<term > auto</term>
<listitem >
<para > Pick the layout automatically. If the kernel is a UKI set layout to
<option > uki</option> . If not default to <option > bls</option> if
<filename > $BOOT/loader/entries.srel</filename> with content <literal > type1</literal> or
<filename > $BOOT/<replaceable > ENTRY-TOKEN</replaceable> </filename> exists, or
<option > other</option> otherwise.</para>
<para > Leaving layout blank has the same effect. This is the default.</para>
2023-08-22 19:52:36 +03:00
<xi:include href= "version-info.xml" xpointer= "v254" />
2023-01-20 11:05:18 +03:00
</listitem>
</varlistentry>
2022-07-01 11:52:12 +03:00
</variablelist>
2022-01-19 14:20:22 +03:00
2023-03-29 04:50:01 +03:00
<para > <varname > $KERNEL_INSTALL_INITRD_GENERATOR</varname> and <varname > $KERNEL_INSTALL_UKI_GENERATOR</varname>
are set for plugins to select the initrd and/or UKI generator. This may be configured as
2023-03-23 00:09:10 +03:00
<varname > initrd_generator=</varname> and <varname > uki_generator=</varname> in <filename > install.conf</filename> , see below.</para>
2022-07-01 11:52:12 +03:00
<para > <varname > $KERNEL_INSTALL_STAGING_AREA</varname> is set for plugins to a path to a directory.
Plugins may drop files in that directory, and they will be installed as part of the loader entry, based
2023-10-23 12:18:01 +03:00
on the file name and extension: Files named <filename > initrd*</filename> will be installed as <replaceable > INITRD-FILE</replaceable> s,
2023-06-19 18:31:58 +03:00
and files named <filename > microcode*</filename> will be prepended before <replaceable > INITRD-FILE</replaceable> s.</para>
2023-10-23 12:18:01 +03:00
2022-07-01 11:52:12 +03:00
</refsect2>
<refsect2 >
<title > Environment variables understood by <command > kernel-install</command> </title>
2022-07-01 11:58:01 +03:00
<para > <varname > $KERNEL_INSTALL_CONF_ROOT</varname> can be set to override the location of the
configuration files read by <command > kernel-install</command> . When set,
2024-02-21 15:41:57 +03:00
<filename > install.conf</filename> , <filename > entry-token</filename> , and other files will be read from
this directory only. Note that this path is relative to the host, and in particular <emphasis > symlinks
in this directory are resolved relative to the host</emphasis> , even if
<option > --root=<replaceable > root</replaceable> </option> is used. This means that it is generally
<emphasis > not</emphasis> correct to use this variable to specify a directory underneath
<replaceable > root</replaceable> if symlinks are used there.</para>
2022-07-01 11:58:01 +03:00
2022-07-01 13:55:32 +03:00
<para > <varname > $KERNEL_INSTALL_PLUGINS</varname> can be set to override the list of plugins executed by
<command > kernel-install</command> . The argument is a whitespace-separated list of paths.
<literal > KERNEL_INSTALL_PLUGINS=:</literal> may be used to prevent any plugins from running.
</para>
2022-07-01 11:52:12 +03:00
<para > <varname > $MACHINE_ID</varname> can be set for <command > kernel-install</command> to override
<varname > $KERNEL_INSTALL_MACHINE_ID</varname> , the machine ID.</para>
2022-02-10 17:27:45 +03:00
2022-07-01 11:52:12 +03:00
<para > <varname > $BOOT_ROOT</varname> can be set for <command > kernel-install</command> to override
<varname > $KERNEL_INSTALL_BOOT_ROOT</varname> , the installation location for boot entries.</para>
2022-02-10 17:27:45 +03:00
2022-07-01 11:58:01 +03:00
<para > The last two variables may also be set in <filename > install.conf</filename> . Variables set in the
2022-07-01 11:52:12 +03:00
environment take precedence over the values specified in the config file.</para>
</refsect2>
2019-03-07 22:49:30 +03:00
</refsect1>
2013-02-22 20:18:47 +04:00
<refsect1 >
<title > Exit status</title>
2016-11-04 15:40:58 +03:00
<para > If every executable returns 0 or 77, 0 is returned, and a non-zero failure code otherwise.</para>
2013-02-22 20:18:47 +04:00
</refsect1>
<refsect1 >
<title > Files</title>
<variablelist >
<varlistentry >
2023-10-11 18:34:43 +03:00
<term > <filename > /etc/kernel/install.d/*.install</filename> </term>
<term > <filename > /usr/lib/kernel/install.d/*.install</filename> </term>
<listitem >
<para > Drop-in files which are executed by <command > kernel-install</command> .</para>
2023-08-22 19:52:36 +03:00
<xi:include href= "version-info.xml" xpointer= "v198" />
2023-10-11 18:34:43 +03:00
</listitem>
2013-02-22 20:18:47 +04:00
</varlistentry>
2023-10-11 18:34:43 +03:00
2013-02-25 22:29:16 +04:00
<varlistentry >
2023-10-11 18:34:43 +03:00
<term > <filename > /etc/kernel/cmdline</filename> </term>
<term > <filename > /usr/lib/kernel/cmdline</filename> </term>
<term > <filename > /proc/cmdline</filename> </term>
<listitem >
<para > Specifies the kernel command line to use. The first of the files that is found will be used.
<varname > $KERNEL_INSTALL_CONF_ROOT</varname> may be used to override the search path; see below for
details.</para>
2023-08-22 19:52:36 +03:00
2023-09-18 18:03:38 +03:00
<xi:include href= "version-info.xml" xpointer= "v198" />
2023-10-11 18:34:43 +03:00
</listitem>
</varlistentry>
<varlistentry >
<term > <filename > /etc/kernel/devicetree</filename> </term>
<term > <filename > /usr/lib/kernel/devicetree</filename> </term>
<listitem >
<para > Specifies the partial path to the file containing the device tree blob to install with the
kernel and use at boot. The first of the files that is found will be used.
<varname > $KERNEL_INSTALL_CONF_ROOT</varname> may be used to override the search path; see below for
details.</para>
<para > The <filename > devicetree</filename> file contains a path, and this path specifies a location
relative to the kernel install tree. A set of locations is checked, including in particular
<filename > /usr/lib/modules/<replaceable > KERNEL_VERSION</replaceable> /dtb/</filename> , which is the
recommended location to place the dtb files under. For example, with
<literal > broadcom/bcm2711-rpi-4-b.dtb</literal> in the <filename > devicetree</filename> file, the
device tree blob for the Raspberry Pi 4 Model B would be installed, and the actual file would be
<filename index= 'false' > /usr/lib/modules/<replaceable > KERNEL_VERSION</replaceable> /dtb/broadcom/bcm2711-rpi-4-b.dtb</filename> .
</para>
<xi:include href= "version-info.xml" xpointer= "v255" />
</listitem>
2018-06-22 19:14:22 +03:00
</varlistentry>
2023-10-11 18:34:43 +03:00
2018-06-22 19:14:22 +03:00
<varlistentry >
2023-10-11 18:34:43 +03:00
<term > <filename > /etc/kernel/tries</filename> </term>
<listitem >
<para > Read by <filename > 90-loaderentry.install</filename> and
<filename > 90-uki-copy.install</filename> . If this file exists, a numeric value is read from it and
the naming of the generated entry file or UKI is altered to include it as
<filename > $BOOT/loader/entries/<replaceable > ENTRY-TOKEN</replaceable> -<replaceable > KERNEL-VERSION</replaceable> +<replaceable > TRIES</replaceable> .conf</filename>
or
<filename > $BOOT/EFI/Linux/<replaceable > ENTRY-TOKEN</replaceable> -<replaceable > KERNEL-VERSION</replaceable> +<replaceable > TRIES</replaceable> .efi</filename> ,
respectively. This is useful for boot loaders such as
<citerefentry > <refentrytitle > systemd-boot</refentrytitle> <manvolnum > 7</manvolnum> </citerefentry>
which implement boot attempt counting with a counter embedded in the entry file name.
<varname > $KERNEL_INSTALL_CONF_ROOT</varname> may be used to override the search path; see below for
details.</para>
2023-08-22 19:52:36 +03:00
<xi:include href= "version-info.xml" xpointer= "v240" />
2023-10-11 18:34:43 +03:00
</listitem>
2013-02-25 22:29:16 +04:00
</varlistentry>
2023-10-11 18:34:43 +03:00
2013-02-25 22:29:16 +04:00
<varlistentry >
2023-10-11 18:34:43 +03:00
<term > <filename > /etc/kernel/entry-token</filename> </term>
<listitem >
<para > If this file exists it is read and used as "entry token" for this system, i.e. is used for
naming Boot Loader Specification entries. See <varname > $KERNEL_INSTALL_ENTRY_TOKEN</varname> above
for details. <varname > $KERNEL_INSTALL_CONF_ROOT</varname> may be used to override the search path; see
below for details.</para>
2023-08-22 19:52:36 +03:00
2023-10-11 18:34:43 +03:00
<xi:include href= "version-info.xml" xpointer= "v251" />
</listitem>
2013-02-25 22:29:16 +04:00
</varlistentry>
2023-10-11 18:34:43 +03:00
2021-12-14 19:09:08 +03:00
<varlistentry >
<term >
2022-02-10 17:27:45 +03:00
<filename > /etc/machine-id</filename>
2021-12-14 19:09:08 +03:00
</term>
<listitem >
2022-02-10 17:27:45 +03:00
<para > The content of this file specifies the machine identification
<replaceable > MACHINE-ID</replaceable> .</para>
2023-08-22 19:52:36 +03:00
<xi:include href= "version-info.xml" xpointer= "v198" />
2021-12-14 19:09:08 +03:00
</listitem>
</varlistentry>
2023-10-11 18:34:43 +03:00
2013-02-25 22:29:16 +04:00
<varlistentry >
2023-10-11 18:34:43 +03:00
<term > <filename > /etc/os-release</filename> </term>
<term > <filename > /usr/lib/os-release</filename> </term>
2022-02-10 17:27:45 +03:00
<listitem >
2023-10-11 18:34:43 +03:00
<para > Read by <filename > 90-loaderentry.install</filename> . If available,
<varname > PRETTY_NAME=</varname> is read from these files and used as the title of the boot menu
entry. Otherwise, <literal > Linux <replaceable > KERNEL-VERSION</replaceable> </literal> will be
used.</para>
2023-08-22 19:52:36 +03:00
2023-10-11 18:34:43 +03:00
<xi:include href= "version-info.xml" xpointer= "v198" />
2013-02-25 22:29:16 +04:00
</listitem>
</varlistentry>
kernel-install: replace 00-entry-directory with K_I_LAYOUT in k-i
341890de866f2ee34919a47ce3fc6c8cd3c1924c made "bootctl install" create
ESP\MID, in preparation of cf73f650890b56a59bfb713c4c82b4e29daa7316 that
followed it and created 00-entry-directory.install to make ESP\MID\KVER
if ESP\MID existed ‒ this meant that "bootctl install" followed by
"kernel-install $(uname -r) /boot/vml*$(uname -r) /boot/ini*$(uname -r)"
actually installed the kernel correctly.
Later, 31e57550b552e113bd3d44355b237c41e42beb58 reverted the first
commit, meaning, that now running those two commands first installs
sd-boot, but then does nothing. Everything appears to work right,
nothing errors out, but no changes are actually done. To the untrained
eye (all of them), even running with -v appears to work:
all the hooks are run, as is depmod, but, again, nothing happens.
This is horrible. Nothing in either manpage suggests what to do
(nor should it, really), but the user is left with a bootloader that
appears fully funxional, since nothing suggests a failure in the output,
but with an unbootable machine, /no way to boot it/, even if they drop
to an EFI shell, since the boot bundle isn't present on the ESP,
and no real recourse even if they boot into a recovery system,
apart from installing like GRUB or whatever.
00- is purely instrumentation for 90-,
and separating one from the other has led to downstream dissatisfaxion
(indeed, the last mentioned commit cited cited exactly that as the
reversion reason), while creating $ENTRY_DIR_ABS is only required
for bootloaders using the BLS, and shouldn't itself toggle anything.
To that end, introduce an /{e,l}/k/install.conf file that allows
overriding the detected layout, and detect it as "bls" if
$BOOT_ROOT/$MACHINE_ID ($ENTRY_DIR_ABS/..) exists, otherwise "other" ‒
if a user wishes to select a different bootloader,
like GRUB, they (or, indeed, the postinst script) can specify
layout=grub. This disables 90- and $ENTRY_DIR_ABS manipulation.
2021-03-16 18:47:34 +03:00
<varlistentry >
2023-10-11 18:34:43 +03:00
<term > <filename > /etc/kernel/install.conf</filename> </term>
2024-02-21 15:41:57 +03:00
<term > <filename > /run/kernel/install.conf</filename> </term>
<term > <filename > /usr/local/lib/kernel/install.conf</filename> </term>
2023-10-11 18:34:43 +03:00
<term > <filename > /usr/lib/kernel/install.conf</filename> </term>
2024-02-21 15:41:57 +03:00
<term > <filename > /etc/kernel/install.conf.d/*.conf</filename> </term>
<term > <filename > /run/kernel/install.conf.d/*.conf</filename> </term>
<term > <filename > /usr/local/lib/kernel/install.conf.d/*.conf</filename> </term>
<term > <filename > /usr/lib/kernel/install.conf.d/*.conf</filename> </term>
2023-10-11 18:34:43 +03:00
<listitem >
<para > Configuration file with options for <command > kernel-install</command> , as a series of
<varname > KEY=</varname> <replaceable > VALUE</replaceable> assignments, compatible with shell syntax,
following the same rules as described in
<citerefentry > <refentrytitle > os-release</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> . The
first of the files that is found will be used. <varname > $KERNEL_INSTALL_CONF_ROOT</varname> may be
2024-02-21 15:41:57 +03:00
used to override the search path; see below for details. Drop-in files may also be used
to extend the configuration with overrides, see
<citerefentry > <refentrytitle > systemd.unit</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> .
</para>
2023-10-11 18:34:43 +03:00
<para > Currently, the following keys are supported:
<varname > MACHINE_ID=</varname> ,
<varname > BOOT_ROOT=</varname> ,
<varname > layout=</varname> ,
<varname > initrd_generator=</varname> ,
<varname > uki_generator=</varname> .
See the Environment variables section above for details.</para>
2023-08-22 19:52:36 +03:00
2023-10-11 18:34:43 +03:00
<xi:include href= "version-info.xml" xpointer= "v250" />
</listitem>
kernel-install: replace 00-entry-directory with K_I_LAYOUT in k-i
341890de866f2ee34919a47ce3fc6c8cd3c1924c made "bootctl install" create
ESP\MID, in preparation of cf73f650890b56a59bfb713c4c82b4e29daa7316 that
followed it and created 00-entry-directory.install to make ESP\MID\KVER
if ESP\MID existed ‒ this meant that "bootctl install" followed by
"kernel-install $(uname -r) /boot/vml*$(uname -r) /boot/ini*$(uname -r)"
actually installed the kernel correctly.
Later, 31e57550b552e113bd3d44355b237c41e42beb58 reverted the first
commit, meaning, that now running those two commands first installs
sd-boot, but then does nothing. Everything appears to work right,
nothing errors out, but no changes are actually done. To the untrained
eye (all of them), even running with -v appears to work:
all the hooks are run, as is depmod, but, again, nothing happens.
This is horrible. Nothing in either manpage suggests what to do
(nor should it, really), but the user is left with a bootloader that
appears fully funxional, since nothing suggests a failure in the output,
but with an unbootable machine, /no way to boot it/, even if they drop
to an EFI shell, since the boot bundle isn't present on the ESP,
and no real recourse even if they boot into a recovery system,
apart from installing like GRUB or whatever.
00- is purely instrumentation for 90-,
and separating one from the other has led to downstream dissatisfaxion
(indeed, the last mentioned commit cited cited exactly that as the
reversion reason), while creating $ENTRY_DIR_ABS is only required
for bootloaders using the BLS, and shouldn't itself toggle anything.
To that end, introduce an /{e,l}/k/install.conf file that allows
overriding the detected layout, and detect it as "bls" if
$BOOT_ROOT/$MACHINE_ID ($ENTRY_DIR_ABS/..) exists, otherwise "other" ‒
if a user wishes to select a different bootloader,
like GRUB, they (or, indeed, the postinst script) can specify
layout=grub. This disables 90- and $ENTRY_DIR_ABS manipulation.
2021-03-16 18:47:34 +03:00
</varlistentry>
2023-08-12 11:19:11 +03:00
<varlistentry >
2023-10-11 18:34:43 +03:00
<term > <filename > /etc/kernel/uki.conf</filename> </term>
<listitem >
<para > Ini-style configuration file for
<citerefentry > <refentrytitle > ukify</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> which is
only effective when <varname > $KERNEL_INSTALL_LAYOUT</varname> or <varname > layout=</varname> in
<filename > install.conf</filename> is set to <option > uki</option> and
<varname > $KERNEL_INSTALL_UKI_GENERATOR</varname> or <varname > uki_generator=</varname> in
2023-11-09 17:01:48 +03:00
<filename > install.conf</filename> is set to <option > ukify</option> , or is unset.
2023-10-11 18:34:43 +03:00
<varname > $KERNEL_INSTALL_CONF_ROOT</varname> may be used to override the search path; see below for
details.</para>
<xi:include href= "version-info.xml" xpointer= "v255" />
</listitem>
2023-08-12 11:19:11 +03:00
</varlistentry>
2023-11-06 14:03:03 +03:00
<varlistentry >
<term > <filename > /usr/lib/modules/<replaceable > KERNEL-VERSION/</replaceable> </filename> </term>
<listitem >
<para > Location for installed kernel modules and other kernel related resources. For each locally
installed kernel a directory named after the kernel version (<command > uname -r</command> ) is
kept.</para>
<xi:include href= "version-info.xml" xpointer= "v255" />
</listitem>
</varlistentry>
<varlistentry >
<term > <filename > /usr/lib/modules/<replaceable > KERNEL-VERSION/vmlinuz</replaceable> </filename> </term>
<listitem >
<para > Location for installed kernel images. This is the recommended location for OS package
managers to install kernel images into (as applicable), from which <command > kernel-install
add</command> then copies it into the final boot partition.</para>
<xi:include href= "version-info.xml" xpointer= "v255" />
</listitem>
</varlistentry>
2013-02-22 20:18:47 +04:00
</variablelist>
2023-10-11 18:34:43 +03:00
<para > For various cases listed above, if the <varname > $KERNEL_INSTALL_CONF_ROOT</varname> environment
variable is set, it will override the search path. The files will be loaded <emphasis > only</emphasis>
from the directory specified by the environment variable. When the variable is not set, the listed paths
are tried in turn, and the first file that exists is used.</para>
2013-02-22 20:18:47 +04:00
</refsect1>
<refsect1 >
<title > See Also</title>
2023-12-22 21:09:32 +03:00
<para > <simplelist type= "inline" >
<member > <citerefentry > <refentrytitle > machine-id</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> </member>
<member > <citerefentry > <refentrytitle > os-release</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> </member>
<member > <citerefentry project= 'man-pages' > <refentrytitle > depmod</refentrytitle> <manvolnum > 8</manvolnum> </citerefentry> </member>
<member > <citerefentry > <refentrytitle > systemd-boot</refentrytitle> <manvolnum > 7</manvolnum> </citerefentry> </member>
<member > <citerefentry > <refentrytitle > ukify</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> </member>
<member > <ulink url= "https://uapi-group.org/specifications/specs/boot_loader_specification" > Boot Loader Specification</ulink> </member>
</simplelist> </para>
2013-02-22 20:18:47 +04:00
</refsect1>
</refentry>
