replacing initramfs-tools with dracut

Patrick · February 6, 2023, 7:19pm

dracut support was implemented in grml-debootstrap.

Kicksecure will move to dracut with its next major release (when rebasing to Debian 12 / bookworm).
(required for ram-wipe - Wipe RAM on shutdown and reboot - Kicksecure)

Patrick · July 9, 2023, 9:32pm

dracut support was completed in git tag 17.0.2.5-developers-only.

Patrick · July 22, 2023, 10:12am

This is a major issue for Kicksecure hosts (currently cannot use dracut):

Debian bug report:
unbootable system after installing dracut on a standard Debian installation

Not an issue for Kicksecure VMs or Whonix VMs because there dracut works for some reason.

Patrick · July 22, 2023, 1:02pm

Might be a duplicate of Debian bug report dracut: generic initrd does not work with encrypted root FS without further configuration.

Thanks to Laszlo Gombos, this has been reported upstream.

github.com/dracutdevs/dracut

Generic initrd does not work with encrypted root FS without further configuration

opened 01:31PM - 20 Jul 23 UTC

LaszloGombos

bug crypt

Moving downstream discussion here upstream from https://bugs.debian.org/cgi-bin/…bugreport.cgi?bug=1029324 with an encrypted root fs, the system will end up with a configuration which looks something like this: ``` /etc/crypttab: <dev>_crypt UUID=<some_uuid> none luks,discard /etc/fstab: /dev/mapper/<some_LVM_LV> / ext4 <options> /boot/grub/grub.cfg: linux /vmlinuz-6.0.0-6-amd64 root=/dev/mapper/<some_LVM_LV> ro quiet ``` Now, after switching to dracut, the new initrd which is built will not contain the necessary configuration to actually setup the "<dev>_crypt" device, since autoconfiguration (rd.auto) is disabled and a hostonly initrd (which would include a custom /etc/crypttab in the initrd) is not built. The result is an initrd which will hang waiting for /dev/mapper/<some_LVM_LV> to show up, and which will eventually time out. A workaround for now is to change /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet rd.auto=1" This, however, means that the name of the crypt device will change from "<dev>_crypt" (as specified in /etc/crypttab) to "luks-<some_uuid>", which will result in ugly error messages during boot (that's mostly cosmetic though) since systemd will fail to setup the device "<dev>_crypt". That, in turn, can be fixed by changing /etc/crypttab from: <dev>_crypt UUID=<some_uuid> none luks,discard so that it reads: luks-<some_uuid> UUID=<some_uuid> none luks,discard A further problem with building the generic initrd is that custom crypt addons (like the fido2 support) won't be included in the initrd even if fido2 is defined in /usr/lib/dracut/modules.d/90crypt/module-setup.sh ("fido2-device=auto"). CC @Alphix

Patrick · November 8, 2023, 7:46pm

github.com/grml/grml-debootstrap

INITRD_GENERATOR=dracut yet initramfs-tools is installed during the build process

opened 07:46PM - 08 Nov 23 UTC

adrelanos

Even with environment variable `INITRD_GENERATOR=dracut`, first initramfs-tools …is being installed. Later during grml-debootstrap's run, dracut is being installed The previous installation of initramfs-tools is unnecessary, takes time and might even cause issues in case there are any bugs. This happens during the function `kernel` because of installation of packages `linux-image-amd64 linux-headers-amd64 busybox firmware-linux-free`. This is because linux-image-amd64 depends on linux-image-6.1.0-13-amd64 which then depends on [linux-initramfs-tool](https://packages.debian.org/bookworm/linux-initramfs-tool) and the default is initramfs-tools. To fix this, the `kernel` function could be modified. currently: ``` DEBIAN_FRONTEND=$DEBIAN_FRONTEND $APTINSTALL $KERNELPACKAGES dracut ``` suggested: ``` if [ "$INITRD_GENERATOR" = 'dracut' ] ; then # install dracut here already to avoid needlessly pulling initramfs-tools # shellcheck disable=SC2086 DEBIAN_FRONTEND=$DEBIAN_FRONTEND $APTINSTALL $KERNELPACKAGES dracut else DEBIAN_FRONTEND=$DEBIAN_FRONTEND $APTINSTALL $KERNELPACKAGES fi ``` I will test this and send a PR if possible.

Patrick · November 8, 2023, 7:58pm

Patrick · November 22, 2023, 4:40am

Debian bug report:
missing dependency on init / systemd-sysv / libpam-systemd

Patrick · December 11, 2023, 3:42pm

dracut has many optional modules:
https://wiki.gentoo.org/wiki/Dracut

Patrick · December 15, 2023, 1:22pm

github.com/dracutdevs/dracut

auto-detect, prompt for potential root devices in case the `root=` device is misconfigured or missing

opened 01:22PM - 15 Dec 23 UTC

adrelanos

enhancement

It might not be possible to auto-detect the root device in very complex cases (c…ustom dual boot setups, network boot) but how about auto detection for the most common cases such as common environments set up by the Fedora or Debian installers? Maybe dracut developers think root device auto detection bad idea? Maybe it's considered insecure as it risks booting the wrong device? If so, they probably have a valid point. Then how about auto detection of potential root devices but prompt the user before booting from an auto detected root device? Or otherwise provide more guidance than a dracut rescue shell? That seems better to me than dropping to a dracut rescue shell. A situation most users will be stuck with.

Patrick · December 17, 2023, 5:41pm

Patrick · December 17, 2023, 6:17pm

github.com/dracutdevs/dracut

auto detect root device according to Discoverable Partitions Specification (DPS) (boot without `root=` and without `/etc/fstab`)

opened 06:16PM - 17 Dec 23 UTC

adrelanos

enhancement

By supporting the [Discoverable Partitions Specification (DPS)](https://uapi-gro…up.org/specifications/specs/discoverable_partitions_specification/) the following things would be possible: * booting without the root device (`root=`) on the kernel command line, and * without `/etc/fstab`. The benefit for the user would be that corner cases such as changed disk uuids after backup/restore no longer result in a broken boot with a dracut rescue shell. It could also simplify operating system build scripts and installers. DPS is also supported by systemd-boot. history: * https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ * https://systemd.io/DISCOVERABLE_PARTITIONS/ related but non-duplicate: * https://github.com/dracutdevs/dracut/issues/2589 (because that would auto-detect legacy systems as well as prompt the user. This ticket however is about supporting DPS.)

Patrick · January 4, 2024, 6:06pm

Summary why Kicksecure was ported from initramfs-tools to dracut:

From the initrd generators I was aware of at the time, only dracut has an exitrd feature. Which means the system drops back into the initrd at shutdown time. It then (hopefully) cleanly unmounts encrypted devices. Then ram-wipe runs.

This couldn’t have been implemented with initramfs-tools unless contributing the exitrd functionality upstream first.

Switching to dracut was actually quite expensive. Specifically because nobody had shared in simple steps how to create a Debian based Live ISO using dracut.

Once dracut is running, writing initrd or exitrd modules is quite doable.

However, it’s best to not over invest into dracut as its days might be counted. One day it might get replaced by mkosi-initrd. On the other hand since Debian by default did not even move to dracut, it could take many Debian releases, years until that happens, if that ever happens.

Patrick · February 13, 2024, 7:52am

Issue happening with initramfs-tools only: pam-tmpdir-helper breaks certain initramfs-update actions on systems with noexec on the /tmp mount · Issue #198 · Kicksecure/security-misc · GitHub
Same issue is not happening with dracut.

Patrick · May 23, 2024, 3:53pm

Useful for dracut-ng builds from source code only for testing:

github.com/dracut-ng/dracut-ng

please provide signing key for dracut

opened 03:52PM - 23 May 24 UTC

adrelanos

bug

git tags are signed, which is nice. But I could not find the signing key for the… e-mail address or key fingerprint. ``` git tag -v 101 ``` ``` object 2255bf3464536b02342d13398c5331999fcfd4fa type commit tag 101 tagger Laszlo Gombos <laszlo.gombos@gmail.com> 1712502326 -0400 101 gpg: Signature made Sun 07 Apr 2024 11:05:26 AM EDT gpg: using EDDSA key 90060B4439A5A5C347FFBF1BAA698639643D9C14 gpg: Can't check signature: No public key zsh: exit 1 git tag -v 101 ``` Could you upload the link please and perhaps link to it from the documentation? Perhaps https://keys.openpgp.org/?

Patrick · May 28, 2024, 12:45pm

https://github.com/laszlogombos.gpg

Patrick · May 28, 2024, 12:48pm

Great news, Debian will likely switch dracut-ng in Debian trixie.

Debian feature request:
dracut: Consider switching to the fork dracut-ng

This will fix two important bugs.

One bug where migrating from initramfs-tools to dracut while using full disk encryption:

github.com/dracutdevs/dracut

fix(crypt): Encrypted root FS handling with generic initrd

dracutdevs:master ← DanWin:encrypted-root-with-generic-initrd

opened 05:31PM - 16 Sep 23 UTC

DanWin

+7 -1

This pull request adds missing modules potentially required for disk decryption …to a generic initrd. Additionally it changes the default for unlocking LUKS encrypted devices at boot from previously only doing so when rd.auto=1 was specified. ## Checklist - [X] I have tested it locally - [ ] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it Fixes #2437

And a bug that matters for ram-wipe as per Is RAM Wipe possible inside Whonix? Cold Boot Attack Defense - #57 by Patrick.

Patrick · September 7, 2024, 1:40pm

Debian bug report:
unbootable system after installing dracut on a standard Debian installation - #2

Patrick · September 27, 2024, 1:15am

Great progress!

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078792#15

Thanks to @arraybolt3!

Patrick · September 27, 2024, 2:55am

github.com/dracut-ng/dracut-ng

With encrypted root + unencrypted boot + systemd, dracut may generate an initrd incapable of decrypting the root disk without showing any warnings or errors

opened 09:50PM - 26 Sep 24 UTC

ArrayBolt3

bug

**Describe the bug** If: * Your system is installed with root (`/`) encrypte…d, * And `/boot` is on a separate, unencrypted partition, * And you do not have `systemd-cryptsetup` installed, * And systemd is being used within dracut, * Then dracut will generate an initrd that is unable to decrypt the root partition on next boot. No errors are generated when this happens. **Distribution used** Debian 13 (Testing/Trixie) **Dracut version** 103 **Init system** systemd **To Reproduce** * Install Debian 13 Live XFCE into a VirtualBox VM, using manual partitioning to create a setup wherein `/boot` is unencrypted and root is encrypted. * Reboot, decrypt the disk, and log in. * Run `sudo apt install dracut`, notice that no errors about disk encryption are displayed after dracut generates an initrd for the system. * Reboot. You will never be given a disk decryption prompt and the system will be unbootable. **Expected behavior** A disk decryption prompt should be given and the system should be bootable. If dracut is missing dependencies that are required for this to work, it should display an error message warning the user that they may be unable to boot with the current initrd. **Additional context** The root cause of this problem is the fact that `systemd-cryptsetup` is not a dependency of dracut. The 90crypt module requires either cryptsetup OR systemd-cryptsetup to exist, and dracut will install the module if either are present. cryptsetup is present in the Debian install made above, so 90crypt is installed. However, in the actual installation code, cryptsetup is only copied into the initrd if systemd is NOT in use. Debian uses systemd, and so cryptsetup gets missed, and systemd-cryptsetup doesn't exist at all so it also gets omitted. Thus the generated initrd has no way to decrypt the root partition. Ultimately the failure to boot is a Debian packaging flaw, however it seems to me that dracut should say *something* when a situation like this arises. Perhaps if systemd is in use, the root partition is encrypted, and systemd-cryptsetup is missing, 90crypt can print a warning like `WARNING: system requires systemd-cryptsetup to be bootable but it was not found! Your system may fail to boot` in the `install()` function of `modules.d/90crypt/module-setup.sh`.

Patrick · October 3, 2024, 6:10am

github.com/dracut-ng/dracut-ng

Add emerg-automount module for autodetecting and mounting a root device in emergency mode

dracut-ng:main ← ArrayBolt3:main

opened 04:55AM - 02 Oct 24 UTC

ArrayBolt3

+214 -0

dracut is currently only able to find and mount the root device if it is told ex…actly where to look. If something happens to the system that causes disk identification info to change (for instance cloning a partition and forgetting to change the root UUID specified on the kernel command line), it's possible for dracut to be unable to locate the root filesystem. In this instance the user is dropped unceremoniously into an emergency shell, where they are left to "figure out" how to mount the root filesystem on their own. Depending on the skill level of the user, this may be impossible. This pull request makes it much easier for a new user to get their system to boot after being dropped into an emergency shell. It adds a new dracut module, `95emerg-automount`, that automates the process of finding and mounting a root filesystem "in the dark" (i.e. without prior info about which filesystem to mount or where it is located). Roughly speaking, the algorithm used is: * Find all available disk partitions. * For each partition, mount it, and see if it looks like a usable root filesystem. * Present a list of all usable-looking root filesystems to the user, along with what OS they appear to contain. * Allow the user to choose which of these to boot. * Mount the chosen filesystem to `/sysroot` and instruct the user to exit the emergency shell. This script is NOT run automatically when the emergency shell is entered, as mounting arbitrary partitions comes with security risks and just blindly mounting everything to check it was not considered an acceptable solution. Instead, a small emergency hook is added that informs the user they can try to automount the root partition if they want to by running `automount.sh`. If they don't want to, they don't have to. In the event a user has multiple operating systems installed on the same system, it can be difficult to determine which one is the correct one to boot. In order to make things easier, the module's installation routine copies `/etc/os-release` from the root filesystem into the initramfs. This allows the automounter to determine which OS release the user is trying to boot. The automounter can then compare this OS release info with the OS release info from each partition it scans for usability. If it finds a match, it knows the user *probably* wants to boot that OS, in which case it will show that partition to the user with a "this is probably what you want to boot" message, and will automatically attempt to boot it if the user doesn't choose the OS to boot (i.e. they just hit Enter when asked what to do). ## TODOs * There's a mechanism for detecting which root filesystem is most likely to be the one the user wants to boot, but it seems to be being foiled by some part of dracut messing with the `/etc/os-release` file that `module-setup.sh` gets to see. Probably using rather than a Dracut install command will fix this. * All operating systems with a matching OS release will be seen as "this is probably what you want to boot" and they will *all* be shown with this messaging. This could be confusing, so it may be better to only mark the first "probably correct" OS and always attempt to boot it if the user fails to choose which OS to try booting. * Needs a LOT more testing with various different filesystems, partitioning setups, multiboot configurations, and distros. ## Changes * Add a new dracut module, `95emerg-automount`, with the features listed above. ## Checklist - [x] I have tested it locally - Note: I have only tested it on Fedora 40, and have not tested all codepaths. It needs more rigorous testing. this is being pushed out "early" to get feedback sooner rather than later. - [x] I have reviewed and updated any documentation if relevant - [x] I am providing new code and test(s) for it Fixes https://github.com/dracutdevs/dracut/issues/2589.