3

I have a new installation of ubuntu 22.04, with full disk encryption (LUKS) and ZFS picked from the ubuntu installer options.

I need to make some edits to /etc/crypttab so that unlocking my drives works in an automatic way (fancy usb auto unlock), but the edits I'm making to /etc/crypttab aren't persisting to initramfs.

What I'm doing is:

  • Editing /etc/crypttab
  • Running update-initramfs -u
  • Rebooting my machine into the the system that asks for the LUKS password (initramfs)
  • Checking the contents of /etc/ but crypptab isn't there.

Have I got my concept of how this works incorrect? I need to persist some version of crypttab to the loader but it isn't working.

Any pointers to what I'm doing wrong?

Bob Arezina
  • 131
  • 1
  • 3

4 Answers4

5

I'm here because I ran into the same problem, found this question via Google, and have some information to add. I am attempting to auto-unlock a LUKS drive without having type a passphrase.

First, I edited /etc/crypttab and changed its entry to the following:

sda3_crypt UUID=2d661ff8-d6a8-49c9-ae96-4d6e234bffe2 /dev/zero luks,discard,keyfile-size=32

Then, I added a new key using the following command:

sudo cryptsetup luksAddKey --new-keyfile-size 32 /dev/sda3 /dev/zero

Finally, I ran update-initramfs which produced the following output:

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.0.0-2-amd64
cryptsetup: WARNING: sda3_crypt: key file /dev/zero has insecure ownership, see 
    /usr/share/doc/cryptsetup/README.Debian.gz.
cryptsetup: WARNING: Skipping root target sda3_crypt: uses a key file

This already seemed suspicious, but I rebooted anyway. Unfortunately, these actions made the system unbootable:

Gave up waiting for suspend/resume device
Gave up waiting for root file system device: Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/legend--vg-root does not exist. Dropping to a shell!


BusyBox v1.35.0 (Debian 1: 1.135.0-2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) cat /etc/crypttab
cat: can't open '/etc/crypttab': No such file or directory

I was able to successfully boot the system again by entering the following commands at the BusyBox prompt:

cryptsetup luksOpen --key-file /dev/zero --keyfile-size 32 /dev/sda3 sda3_crypt
exit

The original question still stands though: why is /etc/crypttab not available in the initramfs?

Update

After more research, I can now finally answer the original question: /etc/crypttab is not present in initramfs because the default unlock script does not use that location; it uses /cryptroot/crypttab instead.

To make /etc/crypttab available as /cryptroot/crypttab in initramfs, create the following script in the /etc/initramfs-tools/hooks directory and make it executable:

#!/bin/sh
cp /etc/crypttab "${DESTDIR}/cryptroot/crypttab"
exit 0

Finally, let it be noted that using auto-unlocking LUKS devices by using empty passphrases defeats the purpose of encryption. It is just as insecure as using no encryption at all.

Jaap Joris Vens
  • 833
  • 6
  • 19
2

Instead of running sudo update-initramfs -u, run sudo update-initramfs -c -k -all

I ran into this problem after adding a new nvme drive, encrypting.

AdminBee
  • 21,637
  • 21
  • 47
  • 71
shazam
  • 21
  • 1
1

On my system (Ubuntu 22.04) all went as expected when I ran the following commands after having edited the /etc/crypttab:

sudo systemctl daemon-reload
sudo systemctl restart cryptsetup.target

I.e. after having added a line in the crypttab I can now see:

  • the new decrypted device in /dev/mapper/
  • the changes are persisted also after the reboot
user1182474
  • 371
  • 3
  • 5
  • 1
    This only works if your root partition is not the one you are trying to decrypt---this process does not do the `update-initramfs`. However, it will allow you to decrypt partitions other than root. Note that the daemon-reload causes the crypttab to be re-read, otherwise the cryptsetup.target will ignore your change. – Seth Robertson Apr 12 '23 at 01:56
0

I had a similar problem, which this discussion helped me fix, but without the need to add a hook, as suggested above.

My encrypted partition is on sda3, but because I copied data from a prior configuration with a different partition scheme, my /etc/crypttab looked like this:

sda6_crypt UUID={uuid] none luks,discard

It appears that when the initramfs image is generated (as when a new kernel is installed, but also on other updates), a mismatch between the naming in /etc/crypttab and the actual partition causes an error (which of course I didn't see) such that the file in the initramfs (located at /cryptroot/crypttab) was empty (zero bytes). This lack of a file is what causes the boot process to hang. Correcting /etc/crypttab to:

sda3_crypt UUID={uuid} none luks,discard

solves the problem. Of course, if your initramfs is already honked it needs to be regenerated:

sudo update-initramfs -u

But future updates should proceed normally.

Gary
  • 1