Installation

Laying the foundation

Base System

The absolute minimum set of packages required to install Arch Linux onto a machine is as follows:

pacstrap /mnt base linux linux-firmware

However, this selection lacks the tooling required for file systems, RAID, LVM, special firmware for devices not included with linux-firmware, networking software, a text editor or packages necessary to access documentation. It also lacks CPU microcode packages with stability and security updates.

The following table contains additional packages you most likely want to append to the above pacstrap command:

Package Description
base Absolute essentials (required)
linux Vanilla Linux kernel and modules, with a few patches applied (required)
linux-hardened A security-focused Linux kernel applying a set of hardening patches to mitigate kernel and userspace exploits
linux-lts Long-term support (LTS) Linux kernel and modules
linux-zen Result of a collaborative effort of kernel hackers to provide the best Linux kernel possible for everyday systems
linux-firmware Device firmware files, e.g. WiFi (required)
intel-ucode Intel CPU microcode (required, if on Intel)
amd-ucode AMD CPU microcode (required, if on AMD)
btrfs-progs Userspace tools to manage btrfs filesystems
dosfstools Userspace tools to manage FAT filesystems
exfatprogs Userspace tools to manage exFAT filesystems
f2fs-tools Userspace tools to manage F2FS filesystems
e2fsprogs Userspace tools to manage ext2/3/4 filesystems
jfsutils Userspace tools to manage JFS filesystems
nilfs-utils Userspace tools to manage NILFS2 filesystems
ntfs-3g Userspace tools to manage NTFS filesystems
reiserfsprogs Userspace tools to manage ReiserFS filesystems
udftools Userspace tools to manage UDF filesystems
xfsprogs Userspace tools to manage XFS filesystems
lvm2 Userspace tools for Logical Volume Management
cryptsetup Userspace tools for encrypting storage devices (LUKS)
networkmanager Comprehensive network management and configuration suite
nano Console text editor
man Read documentation (manuals)
sudo Execute commands with elevated privileges

CAUTION: Be sure to replace amd-ucode with intel-ucode if you're on Intel!

ATTENTION: If you've chosen to use LUKS disk encryption make sure to include the cryptsetup package!

TIP: To speed up package installation, edit /etc/pacman.conf, uncomment the option ParallelDownloads and set it to a desired value. To further increase transfer speeds consider using reflector to select mirrors geographically nearest to you, e.g.:

reflector --country Germany --age 12 --protocol https --sort rate --save /etc/pacman.d/mirrorlist

A desireable selection of packages for a useful base system could therefore look like this:

pacstrap /mnt base linux linux-firmware amd-ucode btrfs-progs dosfstools lvm2 nano networkmanager sudo

Generate the fstab containing information about which storage devices should be mounted at boot:

# Generate fstab referencing UUIDs of devices/partitions
genfstab -U /mnt >> /mnt/etc/fstab

Switch into the newly installed system with arch-chroot and continue setting it up:

arch-chroot /mnt

Time Zone & Locale

Time zone

Create a symbolic link to your local time zone at /etc/localtime and sync the time with the local hardware clock:

ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime
hwclock --systohc

Localization

Edit /etc/locale.gen and uncomment en_US.UTF-8 UTF-8 and other desired locales (prefer UTF-8):

nano /etc/locale.gen

Generate the locales by running:

locale-gen

Set which locales and keyboard layout the system should use for messages and documentation (man pages):

echo "LANG=de_DE.UTF-8" > /etc/locale.conf
echo "KEYMAP=de-latin1" > /etc/vconsole.conf

Network

Set up the default host name of the machine as well as localhost:

NOTE: sebin-desktop is used as an example here. Set $HOSTNAME to whatever you like.

# Define an environment variable containing the desired hostname
export HOSTNAME='sebin-desktop'

# Set the hostname of the machine
echo "$HOSTNAME" > /etc/hostname

# Set localhost to resolve to the machine's loopback address
echo "127.0.0.1	localhost" >> /etc/hosts
echo "::1		localhost" >> /etc/hosts
echo "127.0.1.1	$HOSTNAME.localdomain	$HOSTNAME" >> /etc/hosts

Set wireless region

If your machine has Wi-Fi it is advisable to set the region for wireless radio waves to comply with local regulations:

# Install crda
pacman -S iw

# Set the wireless region, e.g. Germany
iw reg set DE

Network manager

Previously we installed NetworkManager as our default network mangaging software. GNOME and KDE have out of the box support for managing network connections in their settings dialogs in a graphical manner. Both rely on NetworkManager.

Enable NetworkManager to start at boot:

systemctl enable NetworkManager

Using iwd as the Wi-Fi backend (optional)

By default NetworkManager uses wpa_supplicant for managing Wi-Fi connections.

iwd (iNet wireless daemon) is a wireless daemon for Linux written by Intel. The core goal of the project is to optimize resource utilization by not depending on any external libraries and instead utilizing features provided by the Linux Kernel to the maximum extent possible.

To enable the experimental iwd backend, first install iwd and then create the following configuration file:

mkdir /etc/NetworkManager/conf.d
nano /etc/NetworkManager/conf.d/wifi_backend.conf

With the following contents:

[device]
wifi.backend=iwd

systemd-resolved for DNS name resolution

systemd-resolved is a systemd service that provides network name resolution to local applications via a D-Bus interface, the resolve NSS service, and a local DNS stub listener on 127.0.0.53.

Benefits of using systemd-resolved include:

To use systemd-resolved enable the respective unit:

systemctl enable systemd-resolved

To provide domain name resolution for software that reads /etc/resolv.conf directly, such as web browsers and GnuPG, systemd-resolved has four different modes for handling the file

The recommende mode is stub, which uses /run/systemd/resolve/stub-resolv.conf, and contains the local stub 127.0.0.53 as the only DNS server and a list of search domains.

ATTENTION: A few notes about setting this up:

This propagates the systemd-resolved managed configuration to all clients. To use it, replace /etc/resolv.conf with a symbolic link to it:

ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

When set up this way, NetworkManager automatically picks up systemd-resolved for network name resolution.

Fallback DNS servers

If systemd-resolved does not receive DNS server addresses from the network manager and no DNS servers are configured manually then systemd-resolved falls back to the fallback DNS addresses to ensure that DNS resolution always works.

The fallback order is:

  1. Cloudflare
  2. Quad9 (without filtering and without DNSSEC)
  3. Google

ATTENTION: Depending on your use-case, you might not want to route all your DNS traffic through the pre-determined fallback servers for privacy reasons. Do your own research on fallback DNS servers that you want to trust.

Fallback addresses can be manually set in a drop-in config file, e.g. /etc/systemd/resolved.conf.d/fallback_dns.conf:

[Resolve]
FallbackDNS=127.0.0.1 ::1

To disable the fallback DNS functionality set the FallbackDNS option without specifying any addresses:

[Resolve]
FallbackDNS=

DNSSEC

WARNING: DNSSEC support in systemd-resolved is considered experimental and incomplete.

DNSSEC is a suite of extensions to the DNS system. Benefits of utilizing DNSSEC include authentication and data integrity, but not encryption. For actually encrypting your DNS traffic, see the section below.

systemd-resolved can be configured to use DNSSEC for validation of DNS requests. It can be configured in three modes:

Setting Description
allow-downgrade Validate DNSSEC only if the upstream DNS server supports it
true Always validate DNSSEC, breaking DNS resolution if the server does not support it
false Disable DNSSEC validation entirely

Set up DNSSEC in a drop-in config file, e.g. /etc/systemd/resolved.conf.d/dnssec.conf:

[Resolve]
DNSSEC=allow-downgrade

DNS over TLS

DNS over TLS is a security protocol for encrypting DNS queries and responses via Transport Layer Security (TLS), thereby increasing privacy and security by preventing eavesdropping and manipulation of DNS requests in man-in-the-middle attack scenarios.

DNS over TLS in systemd-resolved is disabled by default. To enable validation of your DNS provider's server certificate, include their hostname in the DNS setting in the format ip_address#hostname and set DNSOverTLS to one of three modes:

Setting Description
opportunistic Attempt DNS over TLS when possible and fall back to unencrypted DNS if the server does not support it
true Always use DNS over TLS, breaking resolution if the server does not support it
false Disable DNS over TLS entirely

ATTENTION: When setting DNSOverTLS=opportunistic systemd-resolved will try to use DNS over TLS and if the server does not support it fall back to regular DNS. Note, however, that this opens you to "downgrade" attacks, where an attacker might be able to trigger a downgrade to non-encrypted mode by synthesizinig a response that suggests DNS over TLS was not supported.

WARNING: If setting DNSOverTLS=yes and the server provided in DNS= does not support DNS over TLS all DNS requests will fail!

Set up DNS over TLS in a drop-in config file, e.g. /etc/systemd/resolved.conf.d/dns_over_tls.conf:

[Resolve]
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net [2620:fe::fe]#dns.quad9.net [2620:fe::9]#dns.quad9.net
DNSOverTLS=yes

Multicast DNS

systemd-resolved is capable of working as a multicast DNS (mDNS) resolver and responder. The resolver provides hostname resolution using a "hostname.local" naming scheme.

mDNS support in systemd-resolved is enabled by default. For a given connection, mDNS will only be activated if both mDNS in systemd-resolved is enabled, and if the configuration for the currently active network manager enables mDNS for the connection.

The MulticastDNS setting in systemd-resolved can be set to one of the following:

Setting Description
resolve Only enables resolution support, but responding is disabled
true Enables full mDNS responder and resolver support
false Disables both mDNS responder and resolver

ATTENTION: If you plan on using systemd-resolved as mDNS resolver and responder consider the following:

To enable mDNS for a connection managed by NetworkManager tell nmcli to modify an existing connection:

nmcli connection modify CONNECTION_NAME connection.mdns yes

TIP: The default for all NetworkManager connections can be set by creating a configuration file in /etc/NetworkManager/conf.d/ and setting connection.mdns=2 (equivalent to "yes") in the [connection] section.

[connection]
connection.mdns=2

Avahi

Avahi implements zero-configuration networking (zeroconf), allowing for multicast DNS/DNS-SD service discovery. This enables programs to publish and discover services and hosts running on a local network, e.g. network file sharing servers, remote audio devices, network printers, etc.

Some desktop environments pull in the avahi package as a dependency. It enables their file manager to scan the network for services and make them easily accessible.

ATTENTION: If you plan on using avahi as mDNS resolver and responder consider the following:

Avahi provides local hostname resolution using a "hostname.local" naming scheme. To use it, install the avahi and nss-mdns package and enable Avahi:

pacman -S avahi nss-mdns
systemctl enable avahi-daemon

Then, edit the file /etc/nsswitch.conf and change the hosts line to include mdns_minimal [NOTFOUND=return] before resolve and dns:

hosts: mymachines mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] files myhostname dns

To discover services running in your local network:

avahi-browse --all --ignore-local --resolve --terminate

To query a specific host for the services it advertises:

avahi-resolve-host-name hostname.local

Avahi also includes the avahi-discover graphical utility that lists the various services on your network.

Root Password

Set the password for the root user:

passwd

This password schould differ from the regular user password for security reasons.

In the case of system recovery operations the root user comes into play, e.g. when the kernel fails to mount the root file system or system maintenance via chroot is needed.

sudo

sudo is the standard tool for gaining temporary system administrator privileges on Linux to perform administrative tasks. This eliminates the need to change the current user to root to perform these tasks.

To allow regular users to execute commands with elevated privileges, the configuration for sudo needs to be modified to allow this.

sudo supports configuration drop-in files in /etc/sudoers.d/. Using these makes it easy to modularize the configuration and remove offending files, if something goes wrong.

TIP: File names starting with . or ~ will get ignored. Use this to turn off certain configuration settings if you need to.

WARNING: Drop-in files are just as fragile as /etc/sudoers! It is therefore strongly advised to always use visudo when creating or editing sudo config files, as it will check for syntax errors. Failing to do so will risk rendering sudo inoperable!

Create a new drop-in file at:

EDITOR=nano visudo /etc/sudoers.d/01_wheel

The contents of the drop-in file are as follows:

## Allow members of group wheel to execute any command
%wheel ALL=(ALL:ALL) ALL

Save and exit.

Now every user who is in the wheel user group is allowed to run any command as root.

zsh

zsh is a modern shell with lots of customizability and features. Install the following packages:

pacman -S zsh zsh-autosuggestions zsh-completions zsh-history-substring-search zsh-syntax-highlighting
Package Description
zsh-autosuggestions Suggests commands as you type based on history and completions
zsh-completions Additional completion definitions for zsh
zsh-history-substring-search Type any part of any command from history and cycle through matches
zsh-syntax-highlighting Highlights commands whilst they are typed, helping in reviewing commands before running them

Add User

It is advised to add a regular user account for day to day usage.

Add a new user, create a home directory, add them to the wheel group, set their default shell to zsh:

useradd -mG wheel -s /bin/zsh sebin

Set a password for the new user:

passwd sebin

AUR Helper

An AUR helper is a tool that simplifies the process of procuring extra packages from the Arch User Repository.

yay

Install base-devel packages, git and go:

pacman -S base-devel git go

Switch to any regular user:

su sebin

Make sure we're in the user's home directory:

cd

Create a new directory and change into it:

mkdir git && cd git

Clone the AUR package repo for yay:

git clone https://aur.archlinux.org/yay

Change into the newly cloned repository:

cd yay

Build the package and install it:

makepkg -si

initramfs

The initramfs contains all the necessary programs and config files needed to bring up the machine, mount the root file system and hand off the rest of the boot process to the installed system. It can be further customized with additional modules, binaries, files and hooks for special use cases and hardware.

Usage

Automated image generation

Every kernel in Arch Linux comes with its own .preset file stored in /etc/mkinitcpio.d/ with configuration presets for mkinitcpio. Pacman hooks build a new image after every kernel upgrade or installation of a new kernel.

Manual image generation

To manually generate a Linux kernel image issue the following command:

mkinitcpio -p linux

This will generate a new kernel image with the settings of the preset file /etc/mkinitcpio.d/linux.preset.

To generate kernel images with every preset available, pass the -P argument:

mkinitcpio -P

Configuration

To customize your initramfs, place drop-in configuration files into /etc/mkinitcpio.conf.d/. They will override the settings in the main configuration file at /etc/mkinitcpio.conf.

An overview of the settings you can customize:

Setting Type Description
MODULES Array Kernel modules to be loaded before any boot hooks are run.
BINARIES Array Additional binaries you want included in the initramfs image.
FILES Array Additional files you want included in the initramfs image.
HOOKS Array Hooks are scripts that execute in the initial ramdisk.
COMPRESSION String Which tool to use for compressing the image.
COMPRESSION_OPTIONS Array Extra arguments to pass to the COMPRESSION tool.

WARNING: Do not use the COMPRESSION_OPTIONS setting, unless you know exactly what you are doing. Misuse can produce unbootable images!

MODULES

The MODULES array is used to specify modules to load before anything else is done.

Here you can specify additional kernel modules needed in early userspace, e.g. file system modules (ext2, reiser4, btrfs), keyboard drivers (usbhid, hid_apple, etc.), USB 3 hubs (xhci_hcd) or "out-of-tree" modules which are not part of the Linux kernel. It is also needed to add modules for hardware devices that are not always connected but you would like to be operational from the very start if they are connected during boot.

HINT: The lshw utility can tell you what hardware uses which driver, e.g.:

*-usb:2
             description: USB controller
             product: Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller
             vendor: Intel Corporation
             physical id: 14
             bus info: pci@0000:00:14.0
             version: 20
             width: 64 bits
             clock: 33MHz
             capabilities: xhci bus_master cap_list
             configuration: driver=xhci_hcd latency=0
             resources: iomemory:600-5ff irq:163 memory:603f260000-603f26ffff

The second to last line starting with configuration shows the driver being used.

Example of a MODULES array that adds two modules to the generated image needed for keyboard input, if the keyboard is connected to a USB 3 hub, e.g. a docking station:

MODULES=(xhci_hcd usbhid)

CAUTION: Keep in mind that adding to the initramfs increases the size of the resulting image on disk. Unless you have created your boot partition (more specifically the EFI System partition at either /efi, /boot or /boot/efi) with generous space, you should limit yourself to modules strictly needed for your system. The autodetect hook tries to detect all currently loaded modules of the running system to determine the needed modules to include by default. Only include additional modules if something doesn't work as expected.

ATTENTION: If you use an NVIDIA graphics card, the following modules are required in the MODULES array for early KMS:

MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)

BINARIES

The BINARIES array holds the name of extra executables needed to boot the system. It can also be used to replace binaries provided by HOOKS. The executable names are sourced from the PATH evironment variable, associated libraries are added as well.

Example of a BINARIES array that adds the kexec binary:

BINARIES=(kexec)

FILES

The FILES array hold the full paths to arbitrary files to be included in the image.

Example of a module configuration file to be included in the image, containting the names of modules to auto-load and optional parameters to pass to them:

FILES=(/etc/modprobe.d/modprobe.conf)

HOOKS

The HOOKS array is the most important setting in the file. Hooks are small scripts which describe what will be added to the image. Hooks are referred to by their name, and executed in the order they exist in the HOOKS array of the configuration file.

HINT: For a full list of availble hooks run:

mkinitcpio -L

The default HOOKS line in /etc/mkinitcpio.conf is as follows:

ATTENTION: The order in which hooks are placed in the array is important!

HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block filesystems fsck)

This creates a basic image suitable for most single disk systems.

A quick overview of the hooks and their meaning:

Hook Description
base Sets up all initial directories and installs base utilities and libraries.
udev Adds the udev device manager to scan and set up devices. Recommended for simple boot process.
autodetect Trims hooks after this one to only include modules that are needed for the current system. Keeps image slim.
microcode Includes CPU microcode updates in the image.
modconf Includes module configuration files from /etc/modprobe.d/ and /usr/lib/modprobe.d/.
kms Adds modules to bring up graphics cards as early as possible in the boot process.
keyboard Adds modules for keyboards. Required for keyboard input in early userspace.
keymap Adds the specified keymap(s) from /etc/vconsole.conf.
consolefont Adds the specified console font from /etc/vconsole.conf.
block Adds block device modules needed to bring up different kinds of storage devices.
filesystems Adds file system modules. Required unless file system modules are specified in MODULES.
fsck Adds tools for checking file systems before they are mounted. Strongly recommended!

busybox

By default, mkinitcpio will generate a busybox-based initramfs. It starts an init script that scans the filesystem of the initramfs for scripts to execute and bring up the system and hand over the remaining boot process to systemd once the root file system is mounted. This is fine for most use-cases.

For special cases some additional hooks may be required for busybox to bring up the machine properly:

Hook Description
usr Needed for when you have /usr on a separate partition
resume Needed for suspend-to-disk (hibernation) support
btrfs Needed for btrfs file systems that span multiple drives, needs the btrfs-progs package installed
net Needed for booting from a network drive, needs the mkinitcpio-nfs-utils package installed
dmraid Needed for fakeRAID (BIOS RAID) root devices, needs the dmraid package installed
mdadm_udev Needed for assembling RAID arrays via udev (software RAID), needs the mdadm package installed
encrypt Needed for booting from an encrypted file system, needs the cryptsetup package installed
lvm2 Needed for booting a system that is on LVM, needs the lvm2 package installed

One such special case is encryption, which would result in a HOOKS array that looks like this:

HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block encrypt filesystems fsck)

ATTENTION: In some cases it might be necessary to place the keyboard hook before the autodetect hook to be able to enter the passphrase to unlock the encrypted file systems, e.g. when using different keyboards requiring a different module from the one in use at the time of building the initramfs.

systemd

If you wish, you can also make systemd bring the whole system up start to finish. In this case bootup will be handled by systemd unit files instead of scripts.

The benefit of this is faster boot times and some additional features not available to a busybox-based intiramfs.

To instruct mkinitcpio to build a systemd-based initramfs:

The resulting HOOKS array should look something like this:

HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block filesystems fsck)

For special cases some additional hooks may be required for systemd to bring up the machine properly:

Hook Description
mdadm_udev Needed for assembling RAID arrays via udev (software RAID), needs the mdadm package installed
sd-encrypt Needed for booting from an encrypted file system, needs the cryptsetup package installed
lvm2 Needed for booting a system that is on LVM, needs the lvm2 package installed

One such special case is encryption, which would result in a HOOKS array that looks like this:

HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)

ATTENTION: In some cases it might be necessary to place the keyboard hook before the autodetect hook to be able to enter the passphrase to unlock the encrypted file systems, e.g. when using different keyboards requiring a different module from the one in use at the time of building the initramfs.

COMPRESSION

The COMPRESSION option instructs mkinitcpio to compress the resulting images to save on space on the EFI System Partition or /boot partition. This can be especially important if you include a lot of modules and hooks and the size of the image grows.

Compressing the initramfs is a tradeoff between:

Which one you choose is something you have to decide on the constraints you're working with (slow/fast CPU, available cores, RAM usage, disk space), but generally speaking the default zstd compression strikes a good balance.

Algorithm Description
cat Uncompressed
zstd Best tradeoff between de-/compression time and image size (default)
gzip Balanced between speed and size, acceptable performance
bzip2 Rarely used, decent compression, resource conservative
lzma Very small size, slow to compress
xz Smallest size at longer compression time, RAM intensive compression
lzop Slightly better compression than lz4, still fast to decompress
lz4 Fast decompression, slow compression, "largest" compressed output

NOTE: See this article for a comprehensive comparison between compression algorithms.

COMPRESSION_OPTIONS

WARNING: Misuse of this option may lead to an unbootable system if the kernel is unable to unpack the resultant archive. Do not set this option unless you're absolutely sure that you have to!

The COMPRESSION_OPTIONS setting allows you to pass additional parameters for the compression tool. Available parameters depend on the algorithm chosen for the COMPRESSION option. Refer to the tool's manual for available options. If left empty mkinitcpio will make sure it always produces a working image.

zram

The zram kernel module provides a compressed block device in RAM. If you use it as swap device, the RAM can hold much more information but uses more CPU. Still, it is much quicker than swapping to a hard drive. If a system often falls back to swap, this could improve responsiveness. Using zram is also a good way to reduce disk read/write cycles due to swap on SSDs.

Install the zram-generator package and copy the example configuration:

pacman -S zram-generator
cp /usr/share/doc/zram-generator/zram-generator.conf.example /etc/systemd/zram-generator.conf

Edit the copy of the example configuration to your liking. Comments explain what each setting does.

Secure Boot

Secure Boot is a security feature found in the UEFI standard, designed to add a layer of protection to the pre-boot process: by maintaining a cryptographically signed list of binaries authorized or forbidden to run at boot, it helps in improving the confidence that the machine core boot components (boot manager, kernel, initramfs) have not been tampered with.

ATTENTION: When using Secure Boot it's imperative to use it with disk encryption. If the storage device that stores the keys is not encrypted, anybody can read the keys and use them to sign bootable images, thereby defeating the purpose of using Secure Boot at all.

Preparations

To determine the current state of Secure Boot execute:

bootctl status

The output looks something like this:

System:
      Firmware: UEFI 2.70 (American Megatrends 5.17)
 Firmware Arch: x64
   Secure Boot: enabled (user)
  TPM2 Support: yes
  Measured UKI: yes
  Boot into FW: supported

...

In order to proceed you need to set your firmware's Secure Boot mode into "setup" mode to proceed. This can usually be achieved by wiping the key store of the firmware. Refer to your mainboard's user manual on how to do this.

Installation

For the most straight-forward Secure Boot toolchain install sbctl:

pacman -S sbctl

It tremendously simplifies generating Secure Boot keys, loading keys into firmware and signing kernel images.

Generating keys

SEE ALSO: The Meaning of all the UEFI Keys

Secure Boot implementations use these keys:

Key Type Description
Platform Key (PK) Top-level key
Key Exchange Key (KEK) Keys used to sign Signatures Database and Forbidden Signatures Database updates
Signature Database (db) Contains keys and/or hashes of allowed EFI binaries
Forbidden Signatures Database (dbx) Contains keys and/or hashes of denylisted EFI binaries

To generate new keys and store them under /usr/share/secureboot/keys/:

sbctl create-keys

Unified Kernel Image

A unified kernel image (UKI) combines an EFI stub image, CPU microcode, kernel command line and an initramfs into a single file that can be read and executed by the machines UEFI firmware. It also makes it easier to sign for secure boot as there will be only a single file to sign.

Starting with v31 mkinitcpio is able to create UKIs out-of-the-box. The maintainers of sbctl also recommend using the system's initramfs generation tool instead of sbctl bundle.

To make mkinitcpio generate UKIs, edit the appropriate .preset file for your kernel in /etc/mkinitcpio.d/:

NOTE: mkinitcpio automatically sources /etc/kernel/cmdline for the included kernel command line arguments. If you want the fallback image to receive a different set of kernel command line arguments, specify a different file path in fallback_options with the --cmdline argument. It also sources drop-in files under /etc/cmdline.d/ during UKI generation. However, the latter won't allow you to pass different command line arguments for the default and fallback image.

NOTE: Placing the UKI under /efi/EFI/Linux/ allows systemd-boot to automatically detect images and list them without having to specifically create boot entries for them.

# mkinitcpio preset file for the 'linux' package

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux.img"
default_uki="/efi/EFI/Linux/arch-linux.efi"                                # NEW
#default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"

#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-linux-fallback.img"
fallback_uki="/efi/EFI/Linux/arch-linux-fallback.efi"                      # NEW
fallback_options="-S autodetect --cmdline /etc/kernel/cmdline_fallback"    # NEW

Kernel Command Line Parameters

As mkinitcpio sources command line parameters from a specific file by default, saving them to that file further streamlines the generation process.

First create the directory and open a new file in there:

mkdir /etc/kernel
nano /etc/kernel/cmdline

The parameters to include depend on the kind of initramfs used. You can use any of the persistent block device naming schemes to pass the device. You also need to specify a mapper name under which the decrypted root file system should be made available for mounting.

You can obtain the block device identifier for the LUKS container, e.g. its UUID, with blkid (using /dev/sda1 as an example):

NOTE: Pressing Ctrl + T inside nano allows you to paste the result of a command at the current cursor position.

blkid -s UUID -o value /dev/sda1

Continue to specify additional kernel command line parameters you need. At minimum it should look like this:

TIP: You can further simplify this by using a systemd-based initramfs. Create a file named /etc/crypttab.initramfs and specify your encrypted devices in there (same syntax as regular /etc/crypttab, see crypttab(5)):

# <name>    <device>                                     <passphrase>    <options>
cryptroot   UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX                    discard

This allows you to omit any rd.luks parameters, which leaves you with a kernel command line that looks like this:

root=/dev/mapper/cryptroot rw

ATTENTION: Keep the specialties of your chosen root file system in mind, e.g. if using btrfs you also need to supply the subvolume that should be mounted: rootflags=subvol=@.

NOTE: By default, dm-crypt does not allow TRIM for SSDs for security reasons (information leak). To override this behavior:

Enroll keys in firmware

WARNING: Replacing the platform keys with your own can end up bricking your machine, making it impossible to get into the UEFI/BIOS settings to rectify the situation. This is due to the fact that some device firmware (OpROMs, e.g. GPU firmware), that gets executed during boot, may be signed using Microsoft's keys. Run sbctl enroll-keys --microsoft if you're unsure if this applies to you (enrolling Microsoft's Secure Boot keys alongside your own custom ones) or include the TPM Event Log with sbctl enroll-keys --tpm-eventlog (if your machine has a TPM and you don't need or want Microsoft's keys) to prevent bricking your machine.

ATTENTION: Make sure your firmware's Secure Boot mode is set to setup mode! You can do this by going into your firmware settings and wiping the factory default keys. Additionally, keep an eye out for any setting that auto-restores the default keys on system start.

TIP: If you plan to dual-boot Windows, run sbctl enroll-keys --microsoft to enroll Microsoft's Secure Boot keys along with your own custom keys.

To enroll your keys, simply:

sbctl enroll-keys

Automated signing of UKIs

Next, add the images to the list of files to be signed (one at a time):

sbctl sign --save /efi/EFI/Linux/arch-linux.efi
sbctl sign --save /efi/EFI/Linux/arch-linux-fallback.efi

The sbctl package comes with a pacman hook to execute sbctl sign-all -g on kernel upgrades or installs. The UKIs are ready to be booted directly by the UEFI firmware (EFISTUB booting) or via a bootloader like grub, systemd-boot or rEFInd.

ATTENTION: Currently, the sbctl package also provides a post mkinitcpio hook which runs sbctl after every kernel build. This means with the default linux kernel installed, sbctl will run at least three times, twice for each time mkinitcpio runs during pacman package upgrades and once after pacman finishes. The usefulness of the hook has been disputed. A patch has been submitted.

For the time being, comment out the line calling sbctl sign-all -g in the hook file: /usr/lib/initcpio/post/sbctl

Signing the Bootloader

NOTE: This is the manual method. If you also want to automate the bootloader update process, skip to the section below.

If you plan on using a boot loader, you will also need to add its *.efi executable(s) to the sbctl database, e.g. systemd-boot:

sbctl sign --save /efi/EFI/BOOT/BOOTX64.EFI
sbctl sign --save /efi/EFI/systemd/systemd-bootx64.efi

Upon system upgrades, pacman will call sbctl to re-sign the files listed in sbctl's database.

Automate systemd-boot updates and signing

systemd comes with a systemd-boot-update.service unit file to automate updating the bootloader whenever systemd is updated. However, it only updates the bootloader after a reboot, by which time sbctl has already run the signing process. This would necessitate manual intervention.

Recent versions of bootctl look for a .efi.signed file before a regular .efi file when copying bootloader files during install and update operations. So to integrate better with the auto-update functionality of systemd-boot-update.service, the bootloader needs to be signed ahead of time.

sbctl sign --save -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

This will add the source and target file paths to sbctl's database. The pacman hook included with sbctl will trigger whenever a file in usr/lib/**/efi/*.efi* changes, which will be the case when systemd is updated and a new version of the unsigned bootloader is written to disk at /usr/lib/systemd/boot/efi/systemd-bootx64.efi.

Finally, enable the systemd-boot-update.service unit:

systemctl enable systemd-boot-update

Now when systemd is updated the signed version of the systemd-bootx64.efi booloader will be copied to the ESP after a reboot, completely automating the bootloader update and signing process!

Boot Loader

systemd-boot

systemd comes with systemd-boot already, so no additional packages need to be installed.

Install

ATTENTION: By default, systemd-boot will install itself to either of the well-known ESP locations, e.g. /efi, /boot, or /boot/efi. If your ESP is located somewhere else pass the localtion with the --esp-path parameter.

To install systemd-boot to your EFI System Partition and create a boot loader entry named "Linux Boot Manager" in your firmware:

bootctl install

This will copy /usr/lib/systemd/boot/efi/systemd-bootx64.efi to $ESP/EFI/systemd/systemd-bootx64.efi and $ESP/EFI/BOOT/BOOTX64.EFI.

NOTE: If a signed version of systemd-bootx64.efi exists as systemd-bootx64.efi.signed in the same directory, bootctl copies the signed file instead.

Configure

systemd-boot has two kinds of configs:

Boot loader config

NOTE: For a full list of options and their explanation refer to loader.conf(5) § OPTIONS

Setting Type Description
default string The pre-selected default boot entry. Can be pre-determined value, file name or glob pattern
timeout number Time in seconds until the default entry is automatically booted
console-mode number/string Display resolution mode (0, 1, 2, auto, max, keep)
auto-entries boolean Show/hide other boot entries found by scanning the boot partition
auto-firmware boolean Show/hide "Reboot into firmware" entry

An example loader configuration could look something like this:

ATTENTION: Only spaces are accepted as white-space characters for indentation, do not use tabs!

default         arch    # pre-selects entry from $ESP/loader/entries/arch.conf
timeout         3       # 3 seconds before the default entry is booted
auto-entries    1       # shows boot entries which were auto-detected
auto-firmware   1       # shows entry "Reboot into firmware"
console-mode    max     # picks the highest-numbered mode available

Boot entry config

SEE ALSO: The Boot Loader Specification for a comprehensive overview of what systemd-boot implements.

Available parameters in boot entry config files:

Key Value Description
title string The name of the entry in the boot menu (optional)
version string Human readable version of the entry (optional)
machine-id string The unique machine ID of the computer (optional)
sort-key string Used for sorting entries (optional)
linux path Location of the Linux kernel (relative to ESP)
initrd path Location of the Linux initrd image (relative to ESP)
efi path Location of an EFI executable, hidden on non-EFI systems
options string Kernel command line parameters
devicetree path Binary device tree to use when executing the kernel (optional)
devicetree-overlay paths List of device tree overlays. If multiple, separate by space, applied in order
architecture string Architecture the entry is intended for (IA32, x64, ARM, AA64)
Type 1 (text file based)

NOTE: As of mkinitramfs v38, the CPU microcode is embedded in the initramfs and it is no longer necessary to specify CPU microcode images on a separate initrd line before the actual initramfs.

Type 1 entries specify their parameters in *.conf files under §ESP/loader/entries/.

All paths in these configs are relative to the ESP, e.g. if the ESP is mounted at /boot a boot loader entry located at $ESP/loader/entries/arch.conf would look like this:

title	Arch Linux
linux	/vmlinuz-linux
initrd	/initramfs-linux.img
options	rd.luks.name=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=cryptroot root=/dev/mapper/cryptroot rw
Type 2 (EFI executable)

When using a unified kernel image, any image ending with *.efi placed under $ESP/EFI/Linux/ will be automatically picked up by systemd-boot along with the metadata embedded in that image (e.g. title, version, etc.)

If your UKIs are stored somewhere else, you will need a loader entry *.conf file with an efi key pointing systemd-boot to the location of the *.efi file on the ESP:

title	Arch Linux
efi     /EFI/Arch/linux.efi

EFISTUB

EFISTUB is a method of booting the kernel directly as an EFI executable by the firmware without the need to use a boot loader. This can be useful in cases where you want to reduce the attack surface a boot loader can introduce, or you intend to only ever boot one image. However, some UEFI firmware implementations can be flaky, so this isn't always practical.

Install

To be able to manipulate EFI boot variables install efibootmgr:

pacman -S efibootmgr

Configure

ATTENTION: efibootmgr cannot overwrite existing boot entries and will disregard the creation of a boot entry if one with the same label already exists. If you need to overwrite an existing entry you will need to delete it first. Call efibootmgr without any arguments to list all current boot entries:

efibootmgr

To delete an entry, note its 4-digit boot entry order and instruct efibootmgr to delete it:

efibootmgr -Bb XXXX

To create a new entry efibootmgr needs to know the disk and partition where the kernel image resides on the ESP.

In this example, the ESP is the first partition of the block device /dev/nvme0n1. Kernel parameters are part of the -u option. The partition that holds your root file system needs to be passed as a persistent block device name.

NOTE: If you use LVM or LUKS, you can supply the device mapper name since that already is persistent.

You can get the persistent block device identifier of a file system with the blkid command, i.e. to get the UUID of the root file system:

# /dev/nvme0n1p1 is the ESP, hence /dev/nvme0n1p2 is the root fs
blkid -s UUID -o value /dev/nvme0n1p2

For ease of scriptability, save the values to environment variables:

export ROOT=$(blkid -s UUID -o value /dev/nvme0n1p2)
export CMDL="root=UUID=$ROOT rw add_efi_memmap initrd=\\\initramfs-linux.img"

Then create the boot entry using efibootmgr:

efibootmgr -c -L "Arch Linux" -d /dev/nvme0n1 -p 1 -l /vmlinuz-linux -u $CMDL -v

Unified kernel image

When using a unified kernel image you can instead just point to the UKI without needing to specify any kernel parameters via the -u option (as these will be part of the UKI already):

ATTENTION: If Secure Boot is enabled and the command line parameters are embedded in the UKI, the embedded command line parameters will always take precedence, even if you pass additional parameters with the -u option.

efibootmgr -c -L "Arch Linux" -d /dev/nvme0n1 -p 1 -l "EFI\Linux\archlinux-linux.efi" -v