User:Krin/dracut

This article is not officially supported.

The Arch Linux community does not offer support for the information contained in this page; for installation procedures, the Installation guide is the only officially supported document. The content below is mainly maintained by User:Krin, who last reviewed it on 1 October 2021, and it may be out of date or inaccurate.

Introduction

These notes will follow in the format of EFI system partition and refer to the mount point of your EFI system partition as esp.

Tips and tricks

Testing Unified Kernel Image changes

If a machine is only booting only from signed Unified Kernel Images (hereafter UKIs) built from dracut, changes to the kernel command line or the addition of drivers and files to the image should be tested first, without overwriting your old image. Otherwise, you could be left in an un-bootable state requiring the disabling of Secure Boot and the use of a recovery environment. There are multiple ways to do this.

Warning All of these approaches will cause changes to your TPM PCR registers. If you use TPM in anyway, you will invalidate sealed secrets including but not limited to LUKS volumes. Have your recovery keys and pass phrases on hand and backed up before attempting.

There are two primary approaches one can take. Both may be utilized for a greater measure of safety.

Option 1: backup Your Current Image

Simply copy the currently booted UKI to a new name.

# cp esp/EFI/Linux/linux-5.14.8-arch1-1-df10c5e79c5444b78ef1b154eef3ca32-rolling.efi esp/EFI/Linux/linux-backup.efi

Edit options in /etc/dracut.conf.d and rebuild your UKI with dracut --force --uefi.

Option 2: build using a different config directory

Copy all dracut config files to a new working directory.

$ cp -r /etc/dracut.conf etc/dracut.conf.d ~/

Build a new UKI with a different name:

$ sudo dracut --force --uefi --conf ~/dracut.conf --confdir ~/dracut.conf.d esp/EFI/Linux/linux-new.efi

Other testing tips

See #Debugging dracut for why, but preemptively adding rd.shell and removing quiet is a good idea. It will save time when, inevitably, things go wrong. A reboot is already necessary to boot into the new, permanent image upon successful testing. So there is no penalty for making these additional changes, even if the first test is successful.

You can change the naming of your test image easily by copying /etc/os-release somewhere, updating the BUILD variable from rolling to testing. Add the option --include path/to/new/os-release /etc/os-release to your dracut command. This should change Arch (rolling) to Arch (testing) on your systemd-bootd selection screen. This may have useful effects with other bootloaders too.

If building using a virtual console with limited scroll, all of the build messages are on stderr, not stdout so be sure to redirect stderr to your pager.

Debugging dracut

Refer to dracut(8) § TROUBLESHOOTING.

Further disorganized tips:

Do not jump immediately to rd.shell and rd.debug. rd.debug is extremely noisy, especially if utilizing a low resolution virtual console. Rather, utilize rd.shell and drop the quiet parameter if present. This should help you identify what exactly is failing and then drop you into an emergency shell where you can peruse the wealth of information within /run/initramfs/rdsosreport.txt.