KERNEL-INSTALL(8)

📦
version 262.1 · 15 versions
, in arch rolling

💖 NAME 💖

kernel-install — the icon that adds and removes kernel and initrd images to and from the boot partition. That's the whole job bestie, and yes, we're doing it in the kernel-install(8) manual page right now. 🫶

🦋 SYNOPSIS 🦋

kernel-install [OPTIONS...] add KERNEL-VERSION KERNEL-IMAGE
               [INITRD-FILE...]

kernel-install [OPTIONS...] add-all

kernel-install [OPTIONS...] remove KERNEL-VERSION

kernel-install [OPTIONS...] inspect [KERNEL-VERSION] [KERNEL-IMAGE]
               [INITRD-FILE...]

kernel-install [OPTIONS...] list

✨ DESCRIPTION ✨

okay so. kernel-install installs and removes kernel and initrd images [1] to and from the boot partition — we call that partition $BOOT around here, it's the whole vibe. Usually it's one of /boot/, /efi/, or /boot/efi/. We get into the details below, don't worry. 💅

Now the fun part. kernel-install runs the executable files (the "plugins") that live in the directory /usr/lib/kernel/install.d/ and the local administration directory /etc/kernel/install.d/. All the files get collectively sorted and executed in lexicographic order, regardless of the directory they live in. But listen — files with identical filenames replace each other. Files in /etc/kernel/install.d/ take precedence over files with the same name in /usr/lib/kernel/install.d/. That's your override hook: use it to replace a system-supplied executable with a local file whenever you need to. And if you want one gone gone? Drop a symbolic link in /etc/kernel/install.d/ with the same name as the executable in /usr/lib/kernel/install.d/, pointing to /dev/null, and it disables the executable entirely. Iconic behavior honestly. Executables must have the extension .install — other extensions are ignored, no exceptions.

An executable placed in these directories should return 0 on success. It may also return 77 to cause the whole operation to terminate (executables later in lexicographic order will be skipped). So if a plugin returns 77, that's the show, everybody go home. 💀

👑 COMMANDS 👑

The following commands are understood, and yes, each one ate:

🌸 add [[[KERNEL-VERSION] KERNEL-IMAGE] [INITRD-FILE ...]] 🌸

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 specified as -, it defaults to the current kernel version — i.e. the same string uname -r returns. If the latter is omitted, specified as an empty string, or specified as -, it defaults to /usr/lib/modules/KERNEL_VERSION/vmlinuz. Optionally, one or more initrd images may be specified as well (note that plugins might generate additional ones 👀).

The executable files from /usr/lib/kernel/install.d/*.install and /etc/kernel/install.d/*.install (i.e. the plugins) are called with the following arguments:

add KERNEL-VERSION $BOOT/ENTRY-TOKEN/KERNEL-VERSION/ KERNEL-IMAGE [INITRD-FILE ...]

The third argument directly refers to the path where to place kernel images, initrd images and other resources for UAPI.1 Boot Loader Specification [2] Type #1 entries (the "entry directory"). If other boot loader schemes are used the parameter may be ignored.

The ENTRY-TOKEN string is typically the machine ID and is supposed to identify the local installation on the system. For details see below. 🧚

kernel-install creates $BOOT/ENTRY-TOKEN/KERNEL-VERSION, if enabled (see $KERNEL_INSTALL_LAYOUT).

Three default plugins execute the following operations in this case:

🍓 50-depmod.install

The plugin runs depmod(8) for the KERNEL-VERSION.

🍓 90-loaderentry.install

The plugin copies KERNEL-IMAGE to $BOOT/ENTRY-TOKEN/KERNEL-VERSION/linux. If INITRD-FILEs are provided, it also copies them to $BOOT/ENTRY-TOKEN/KERNEL_VERSION/INITRD-FILE. This can also be used to prepend microcode before the actual initrd. It also creates a boot loader entry according to the UAPI.1 Boot Loader Specification [2] (Type #1) in $BOOT/loader/entries/ENTRY-TOKEN-KERNEL-VERSION.conf. The title of the entry is the PRETTY_NAME parameter specified in /etc/os-release or /usr/lib/os-release (if the former is missing), or "Linux KERNEL-VERSION", if unset.

If $KERNEL_INSTALL_LAYOUT is not "bls", this plugin does nothing.

🍓 90-uki-copy.install

If $KERNEL_INSTALL_STAGING_AREA/uki.efi exists, the plugin copies it to $BOOT/EFI/Linux/ENTRY-TOKEN-KERNEL-VERSION.efi. Also, files in $KERNEL_INSTALL_STAGING_AREA/uki.efi.extra.d"/ are copied to $BOOT/EFI/Linux/ENTRY-TOKEN-KERNEL-VERSION.efi.extra.d/.

If $KERNEL_INSTALL_STAGING_AREA/uki.efi does not exist, and the KERNEL-IMAGE argument has a .efi extension, the plugin copies the image to $BOOT/EFI/Linux/ENTRY-TOKEN-KERNEL-VERSION.efi. Also, files in KERNEL-IMAGE.extra.d/ and $KERNEL_INSTALL_STAGING_AREA/uki.efi.extra.d"/ are copied to $BOOT/EFI/Linux/ENTRY-TOKEN-KERNEL-VERSION.efi.extra.d/.

If $KERNEL_INSTALL_LAYOUT is not "uki", this plugin does nothing.

Added in version 198.

🎀 add-all 🎀

This is the same as add (see above), but it invokes the operation iteratively for every installed kernel in /usr/lib/modules/. Obsessed with the efficiency honestly. This operation is only supported on systems where the kernel image is installed in /usr/lib/modules/KERNEL-VERSION/vmlinuz.

Added in version 255.

💜 remove KERNEL-VERSION 💜

This command expects a kernel version string as single argument.

The executable files from /usr/lib/kernel/install.d/*.install and /etc/kernel/install.d/*.install (i.e. the plugins) are called with the following arguments:

remove KERNEL-VERSION $BOOT/ENTRY-TOKEN/KERNEL-VERSION/

Afterwards, kernel-install removes the entry directory $BOOT/ENTRY-TOKEN/KERNEL-VERSION/ and its contents, if it exists. (If it doesn't exist, nothing happens, she's not gonna fight a ghost. 🙈)

Three default plugins execute the following operations in this case:

🍓 50-depmod.install

The plugin removes the files generated by depmod for this kernel again.

🍓 90-loaderentry.install

The plugin removes the file $BOOT/loader/entries/ENTRY-TOKEN-KERNEL-VERSION.conf.

🍓 90-uki-copy.install

The plugin removes the file $BOOT/EFI/Linux/ENTRY-TOKEN-KERNEL-VERSION.efi and $BOOT/EFI/Linux/ENTRY-TOKEN-KERNEL-VERSION.efi.extra.d/ directory including its contents.

Added in version 198.

🔍 inspect [[[KERNEL-VERSION] KERNEL-IMAGE] [INITRD-FILE ...]] 🔍

Takes the same parameters as add.

Shows the various paths and parameters configured or auto-detected. In particular, shows the values of the various $KERNEL_INSTALL_* environment variables listed below, as they would be passed to plugins. The --json option can be used to get the output of this verb as a JSON object. Yes bestie, she'll hand you machine-readable receipts. 💅

Added in version 251.

📋 list 📋

Shows the various installed kernels. This enumerates the subdirectories of /usr/lib/modules/, and shows whether a kernel image is installed there. It's giving inventory check. ✨

Added in version 255.

🔧 COMPATIBILITY WITH THE KERNEL BUILD SYSTEM 🔧

installkernel [OPTIONS...] VERSION VMLINUZ [MAP] [INSTALLATION-DIR]

When invoked as installkernel, this program accepts arguments as specified by the kernel build system's make install command. The VERSION and VMLINUZ parameters specify the kernel version and the kernel binary. The other two parameters (MAP and INSTALLATION-DIR) are currently ignored. Not "handled differently", not "deprecated" — straight up ignored, so don't come for her about them. 💀

🦋 THE $BOOT PARTITION 🦋

The partition where the kernels and UAPI.1 Boot Loader Specification [2] snippets are located is called $BOOT.

kernel-install determines the location of this partition by checking /efi/, /boot/, and /boot/efi/ in turn. The first location where $BOOT/loader/entries/ or $BOOT/ENTRY-TOKEN/ exists is used. First come, first served, periodt. 👑

✨ OPTIONS ✨

okay bestie, here's the full menu of flags, no skips, no cuts 💅

  • --esp-path= — the path to your EFI System Partition (ESP, aka the special lil boot partition). If you don't tell it one, it goes looking at /efi/, then /boot/, then /boot/efi/, one after the other. Pro tip from the manpage itself: it's recommended you mount the ESP at /efi/ if you possibly can.
  • --boot-path= — path to the Extended Boot Loader partition, as defined in the UAPI.1 Boot Loader Specification. If you don't specify it, /boot/ gets checked. And yep, it's recommended you mount the Extended Boot Loader partition at /boot/ if possible.
  • --make-entry-directory=yes|no|auto — this one controls whether a UAPI.1 Boot Loader Specification Type #1 entry directory gets created (on add) and deleted (on remove) on the file system that holds stuff like your kernel and initrd images. The directory is named after the entry token and sits immediately below the boot root directory. When it's auto, the directory only gets created or removed when the install layout is bls. Defaults to auto.

Added in version 254.

  • --entry-type=type1|type2|all — controls which type of entries the command deals with. Super handy when you've got multiple types of boot entries sitting there with the same kernel version and you only wanna nuke one of them. When you say type1 or type2, each plugin gets invoked with the $KERNEL_INSTALL_BOOT_ENTRY_TYPE environment variable set to that value. When you say all, that environment variable simply isn't set. Defaults to all.

Added in version 258.

  • --entry-token= — controls how boot loader entries get named and identified for this kernel installation or deletion. Takes one of auto, machine-id, os-id, os-image-id, or an arbitrary string prefixed with literal:.

If you set it to machine-id, entries get named after the machine ID of the running system (something like "b0e793a9baf14b5fa13ecbe84ff637ac"). Check machine-id(5) for the whole lore about the machine ID concept and file.

If you set it to os-id, entries get named after the OS ID of the running system — that's the ID= field of os-release(5) (like "fedora"). Same energy with os-image-id: entries get named after the OS image ID of the running system, i.e. the IMAGE_ID= field of os-release (like "vendorx-cashier-system").

If you set it to auto (the default), the /etc/kernel/entry-token file (or $KERNEL_INSTALL_CONF_ROOT/entry-token) gets read if it exists, and whatever's stored in there is used. Otherwise, if the local machine ID is initialized, that's used. Otherwise, IMAGE_ID= from os-release gets used if it's set. Otherwise, ID= from os-release gets used if it's set. Otherwise, a randomly generated machine ID is used. the fallback chain is giving very prepared-girl energy ✨

Using the machine ID for naming entries is generally the move, but there are legit cases for the other identifiers. Specifically: if the identification data that the machine ID drags along shouldn't be stored on the (unencrypted) $BOOT_ROOT partition, or if the ID is meant to be generated on first boot and just isn't known yet when the entries get prepared. Heads up though: using the machine ID has the benefit that multiple parallel installations of the same OS can coexist on the same medium and update their boot loader entries independently. When you use another identifier (like the OS ID or 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.

Added in version 254.

  • -v, --verbose — spits out extra info about what operations are happening.

Added in version 242.

  • *--root=root* — takes a directory path as its argument. Every path gets prefixed with the given alternate root path, config search paths included. Perfect for operating on a system image mounted at that directory instead of the host system itself.

Added in version 255.

  • *--image=image* — takes a path to a disk image file or block device node. If you give it one, all operations get applied to the file system inside that disk image. This option is like --root=, except it works 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 inside a GPT partition table following the UAPI.2 Discoverable Partitions Specification. Want more deets on supported disk images? Peep systemd-nspawn(1)'s switch of the same name.

Added in version 255.

  • -h, --help — print a short help text and dip. 👋
  • --version — print a short version string and dip.
  • --no-pager — don't pipe the output into a pager.
  • --json=MODE — shows output formatted as JSON. Expects one of "short" (the shortest possible output, no redundant whitespace or line breaks), "pretty" (the same but pretty, with indentation and line breaks), or "off" (to turn JSON output off — this is the default).
  • *--image-policy=policy* — takes an image policy string as argument, per systemd.image-policy(7). The policy gets enforced when operating on the disk image specified via --image=, see above. If you don't specify it, it defaults to the "*" policy, i.e. all recognized file systems in the image get used.
  • --no-legend — don't print the legend, i.e. the column headers and that footer with the hints. 🎀

🌸 ENVIRONMENT VARIABLES 🌸

Environment variables exported for plugins

These are the ones kernel-install hands off to your plugins, bestie 🫶

  • If --verbose is used, $KERNEL_INSTALL_VERBOSE=1 will be exported for plugins. They may output additional logs in this case.
  • $KERNEL_INSTALL_IMAGE_TYPE=uki|pe|unknown is set for the plugins to specify the type of the kernel image.
    • uki — Unified kernel image.

Added in version 254.

  • pe — PE binary.

Added in version 254.

  • unknown — Unknown type.

Added in version 254.

  • $KERNEL_INSTALL_MACHINE_ID is set for the plugins to the desired machine-id to use. It's always a 128-bit ID. Normally it's read from /etc/machine-id, but it can also be overridden via $MACHINE_ID (see below). If it's not specified through either of those methods, a fallback value will be generated by kernel-install and used only for a single invocation.
  • $KERNEL_INSTALL_ENTRY_TOKEN is set for the plugins to the desired entry "token" to use. It's an identifier that should be used to identify the local installation, and it's often the machine ID, i.e. same as $KERNEL_INSTALL_MACHINE_ID, but it might also be a different kind of identifier — for example a fixed string or the ID=, IMAGE_ID= values from /etc/os-release. The string passed here will be used to name Boot Loader Specification entries, or the directories the kernel image and initial RAM disk images get placed into.

Note that while $KERNEL_INSTALL_ENTRY_TOKEN and $KERNEL_INSTALL_MACHINE_ID 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 gets read from /etc/kernel/entry-token if it exists. Otherwise, a few possible candidates below $BOOT get checked for Boot Loader Specification Type 1 entry directories, and if one's found, the entry token is derived from that. If that doesn't work out, $KERNEL_INSTALL_MACHINE_ID is used as the fallback.

  • $KERNEL_INSTALL_BOOT_ROOT is set for the plugins to the absolute path of the root directory (usually the mount point) of the hierarchy where boot loader entries, kernel images, and associated resources should go. This is usually the path where the XBOOTLDR partition or the ESP (EFI System Partition) are mounted, and it's also conceptually referred to as $BOOT. Can be overridden by setting $BOOT_ROOT (see below).
  • $KERNEL_INSTALL_LAYOUT=auto|bls|uki|other|... is set for the plugins to specify the installation layout. Extra layout names may be defined by convention. If a plugin uses a special layout, it's encouraged to declare its own layout name and configure layout= in install.conf upon initial installation. The following values are currently understood:
    • bls — Standard UAPI.1 Boot Loader Specification Type #1 layout, compatible with systemd-boot(7): entries in $BOOT/loader/entries/ENTRY-TOKEN-KERNEL-VERSION[+TRIES].conf, kernel and initrds under $BOOT/ENTRY-TOKEN/KERNEL-VERSION/

Implemented by 90-loaderentry.install.

Added in version 250.

  • uki — Standard UAPI.1 Boot Loader Specification Type #2 layout, compatible with systemd-boot(7): unified kernel images under $BOOT/EFI/Linux as $BOOT/EFI/Linux/ENTRY-TOKEN-KERNEL-VERSION[+TRIES].efi.

Implemented by 90-uki-copy.install.

Added in version 253.

  • other — Some other layout not understood natively by kernel-install.

Added in version 250.

  • auto — Pick the layout automatically. If the kernel is a UKI, set layout to uki. If not, default to bls if $BOOT/loader/entries.srel with content "type1" or $BOOT/ENTRY-TOKEN exists, or other otherwise.

Leaving layout blank has the same effect. This is the default.

Added in version 254.

  • $KERNEL_INSTALL_INITRD_GENERATOR and $KERNEL_INSTALL_UKI_GENERATOR are set for plugins to select the initrd and/or UKI generator. This may be configured as initrd_generator= and uki_generator= in install.conf, see below.
  • $KERNEL_INSTALL_STAGING_AREA is set for plugins to a path to a directory. Plugins may drop files in that directory, and they'll get installed as part of the loader entry, based on the file name and extension: files named initrd* will be installed as INITRD-FILEs, and files named microcode* will be prepended before INITRD-FILEs.
  • $KERNEL_INSTALL_ENTRY_NAME is set for the plugins to the resolved entry name, derived by expanding specifiers in the entry name format string. This is the base name (without file extension) used for UKI files, loader entry configuration files, and similar. By default this is "ENTRY-TOKEN-KERNEL-VERSION", matching the traditional naming. See $KERNEL_INSTALL_ENTRY_NAME_FORMAT below for the deets on the available specifiers.

Environment variables understood by kernel-install

  • $KERNEL_INSTALL_CONF_ROOT can be set to override the location of the configuration files read by kernel-install. When it's set, install.conf, entry-token, and other files will be read from this directory only. Note that this path is relative to the host, and in particular symlinks in this directory get resolved relative to the host, even if --root=root is used. Which means it's generally not correct to use this variable to specify a directory underneath root if symlinks are used there. 🙈

Okay bestie, so like — the env vars keep coming, and these next ones are the glow-up knobs. 👑

$KERNEL_INSTALL_PLUGINS — set this and you get to override the whole list of plugins that kernel-install runs. The argument is a whitespace-separated list of paths, so like, however many you want, space-separated, that's your lineup. ✨

And the iconic party trick: KERNEL_INSTALL_PLUGINS=: — yes, a single colon, nothing else — may be used to prevent any plugins from running at all. Ghost town. No plugins. Nobody home. 💀

$MACHINE_ID — set this for kernel-install and it overrides $KERNEL_INSTALL_MACHINE_ID, aka the machine ID. That's it, that's the whole vibe. 🪪

$BOOT_ROOT — set this for kernel-install to override $KERNEL_INSTALL_BOOT_ROOT, which is the installation location for boot entries. Where the boot stuff goes. The address, if you will. 🏠

lowkey important, bestie: those last two variables may also be set in install.conf. And here's the rule — variables set in the environment take precedence over the values specified in the config file. Environment wins, every time. No arguments. 🫶

$KERNEL_INSTALL_ENTRY_NAME_FORMAT — this one's for naming your babies (your boot entries, not actual babies, pls). Set it to configure the format string used to derive the entry name for boot loader entries and UKI files. 🌸

The format string is expanded using specifier expansion — that's the magic. And yeah, it may also be configured as entry_name_format= in install.conf, so you've got options, you're flexible, you're that girl. 💅

The following specifiers are understood: (bestie the specifier menu is literally right there, keep scrolling 👀)

✨ Table 1. Specifiers available in $KERNEL_INSTALL_ENTRY_NAME_FORMAT ✨

Okay bestie, this is the good stuff — every little magic code you can drop into that format string, and what it turns into 💖

  • "%a" — Architecture. A short string that IDs the architecture of the local system — something like x86, x86-64 or arm64. Wanna see the full roster? Check the architectures defined for ConditionArchitecture= in systemd.unit(5). 🖥️
  • "%A" — Operating system image version. The OS image version identifier of the running system, read straight outta the IMAGE_VERSION= field of /etc/os-release. If that field isn't set, it resolves to an empty string. More deets in os-release(5). 🏷️
  • "%B" — Operating system build ID. The OS build identifier of the running system, as read from the BUILD_ID= field of /etc/os-release. Not set? Resolves to an empty string. Peep os-release(5) for more. 🔧
  • "%e" — Entry token. The entry token, same thing as $KERNEL_INSTALL_ENTRY_TOKEN. Literally the same value, no cap. 🎟️
  • "%H" — Host name. The hostname of the running system. 🏠
  • "%l" — Short host name. The hostname of the running system, truncated at the first dot so any domain component gets chopped off. ✂️
  • "%m" — Machine ID. The machine ID of the running system, formatted as string. See machine-id(5) for more. 🆔
  • "%M" — Operating system image identifier. The OS image identifier of the running system, read from the IMAGE_ID= field of /etc/os-release. If it's not set, resolves to an empty string. os-release(5) has the full lore. 📦
  • "%o" — Operating system ID. The OS identifier of the running system, read from the ID= field of /etc/os-release. See os-release(5) for more info. 🐧
  • "%q" — Pretty host name. The pretty hostname of the running system, read from the PRETTY_HOSTNAME= field of /etc/machine-info. If that's not set, it resolves to the short hostname instead. Check machine-info(5) for more. 🌸
  • "%v" — Kernel version. The kernel version being installed. And listen, heads up: unlike the common specifier "%v" that expands to the currently running kernel version (i.e. uname -r), here it means the target kernel version passed to kernel-install. Different vibe, same letter. 👀
  • "%w" — Operating system version ID. The OS version identifier of the running system, read from the VERSION_ID= field of /etc/os-release. If it's not set, it resolves to an empty string. See os-release(5) for more. 🔢
  • "%W" — Operating system variant ID. The OS variant identifier of the running system, read from the VARIANT_ID= field of /etc/os-release. If not set, resolves to an empty string. More in os-release(5). 🎨
  • "%%" — Single percent sign. Use "%%" in place of "%" to specify one single percent sign. That's it, that's the trick. 💯
⚠️ Real talk though: the resolved entry name must be a valid filename — no path separators allowed, periodt.

The default is "%e-%v", which gives you that classic traditional "ENTRY-TOKEN-KERNEL-VERSION" naming everybody knows and loves. 💅

For example, setting entry_name_format=%M_%A_%a on a system with IMAGE_ID=myos, IMAGE_VERSION=20250830, and architecture "x86-64" would produce entry names like "myos_20250830_x86-64". Slay, that's a whole aesthetic. ✨🦋

Okay so one more thing about that entry name, bestie, and it's important 👀 — the entry name gets resolved every single time kernel-install runs. So if your format string uses specifiers that depend on mutable system state (looking at you, "%M", "%A", "%H"), and that state changes between installing a kernel and removing it, the remove operation may compute a completely different entry name than add did — and boom, stale files just chilling on the boot partition forever 💀. So the entry_name_format= setting should stay stable across a kernel's install/remove lifecycle, okay? And also, the format should produce a unique name for each installed kernel, like by including "%v" (kernel version) or "%A" (IMAGE_VERSION) — otherwise installing multiple kernels will overwrite each other's boot entries and that is not the vibe 🙈.

💥 EXIT STATUS 💥

If every executable returns 0 or 77, 0 is returned. Anything else? Non-zero failure code, bestie. That's it. Periodt. ✨

📂 FILES 📂

  • /etc/kernel/install.d/*.install, /usr/lib/kernel/install.d/*.install — Drop-in files which are executed by kernel-install.

Added in version 198.

  • /etc/kernel/cmdline, /usr/lib/kernel/cmdline, /proc/cmdline — Specifies the kernel command line to use. The first of the files that is found will be used. Lines starting with the "#" character are ignored. When running in a container, /proc/cmdline is ignored. $KERNEL_INSTALL_CONF_ROOT may be used to override the search path; see below for details.

Added in version 198.

  • /etc/kernel/devicetree, /usr/lib/kernel/devicetree — 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. $KERNEL_INSTALL_CONF_ROOT may be used to override the search path; see below for details.

The devicetree 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 /usr/lib/modules/KERNEL_VERSION/dtb/, which is the recommended location to place the dtb files under. For example, with "broadcom/bcm2711-rpi-4-b.dtb" in the devicetree file, the device tree blob for the Raspberry Pi 4 Model B would be installed, and the actual file would be /usr/lib/modules/KERNEL_VERSION/dtb/broadcom/bcm2711-rpi-4-b.dtb.

Added in version 255.

  • /etc/kernel/tries — Read by 90-loaderentry.install and 90-uki-copy.install. 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 $BOOT/loader/entries/ENTRY-TOKEN-KERNEL-VERSION+TRIES.conf or $BOOT/EFI/Linux/ENTRY-TOKEN-KERNEL-VERSION+TRIES.efi, respectively. This is useful for boot loaders such as systemd-boot(7) which implement boot attempt counting with a counter embedded in the entry file name. $KERNEL_INSTALL_CONF_ROOT may be used to override the search path; see below for details.

Added in version 240.

  • /etc/kernel/entry-token — 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 $KERNEL_INSTALL_ENTRY_TOKEN above for details. $KERNEL_INSTALL_CONF_ROOT may be used to override the search path; see below for details.

Added in version 251.

  • /etc/machine-id — The content of this file specifies the machine identification MACHINE-ID.

Added in version 198.

  • /etc/os-release, /usr/lib/os-release — Read by 90-loaderentry.install. If available, PRETTY_NAME= is read from these files and used as the title of the boot menu entry. Otherwise, "Linux KERNEL-VERSION" will be used.

Added in version 198.

  • /etc/kernel/install.conf, /run/kernel/install.conf, /usr/local/lib/kernel/install.conf, /usr/lib/kernel/install.conf, /etc/kernel/install.conf.d/*.conf, /run/kernel/install.conf.d/*.conf, /usr/local/lib/kernel/install.conf.d/*.conf, /usr/lib/kernel/install.conf.d/*.conf — Configuration file with options for kernel-install, as a series of KEY=VALUE assignments, compatible with shell syntax, following the same rules as described in os-release(5). The first of the files that is found will be used. $KERNEL_INSTALL_CONF_ROOT may be used to override the search path; see below for details. Drop-in files may also be used to extend the configuration with overrides, see systemd.unit(5).

Currently, the following keys are supported: MACHINE_ID=, BOOT_ROOT=, layout=, initrd_generator=, uki_generator=, entry_name_format=. See the Environment variables section above for details.

Added in version 250.

  • /etc/kernel/uki.conf — Ini-style configuration file for ukify(1) which is only effective when $KERNEL_INSTALL_LAYOUT or layout= in install.conf is set to uki and $KERNEL_INSTALL_UKI_GENERATOR or uki_generator= in install.conf is set to ukify, or is unset. $KERNEL_INSTALL_CONF_ROOT may be used to override the search path; see below for details.

Added in version 255.

  • /usr/lib/modules/KERNEL-VERSION/ — Location for installed kernel modules and other kernel related resources. For each locally installed kernel a directory named after the kernel version (uname -r) is kept.

Added in version 255.

  • /usr/lib/modules/KERNEL-VERSION/vmlinuz — Location for installed kernel images. This is the recommended location for OS package managers to install kernel images into (as applicable), from which kernel-install add then copies it into the final boot partition.

Added in version 255.

For all those cases up there 👆, if the $KERNEL_INSTALL_CONF_ROOT environment variable is set, it will override the search path. The files will be loaded only 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. Slay. 🫶

🌈 SEE ALSO 🌈

machine-id(5), os-release(5), depmod(8), systemd-boot(7), ukify(1), UAPI.1 Boot Loader Specification[2]

📝 NOTES 📝

  1. Nowadays actually CPIO archives used as an "initramfs", rather than "initrd". See bootup(7) for an explanation.
  2. UAPI.1 Boot Loader Specification https://uapi-group.org/specifications/specs/boot_loader_specification
  3. UAPI.2 Discoverable Partitions Specification https://uapi-group.org/specifications/specs/discoverable_partitions_specification

and that's the whole page, bestie!! 🎀 This one's from systemd 262.1, filed under KERNEL-INSTALL(8) — go forth and install kernels responsibly, you absolute icon 👑💖

📦 where this page comes from
  • arch rolling: systemd 262.1-1 · LGPL-2.1-or-later AND CC0-1.0 AND GPL-2.0-or-later AND MIT-0
  • 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms