26

I'm trying to setup an encrypted volume following this guide

Everything is setup but mounting the encrypted volume fails at boot-time with the error:

fsck.ext4: No such file or directory while trying to open /dev/mapper/safe_vault Possibly non-existent device?

This is my setup:

crypttab

$ sudo cat /etc/crypttab
safe_vault  /dev/disk/by-uuid/d266ae14-955e-4ee4-9612-326dd09a463b  none    luks

NOTE:

The uuid comes from:

$ sudo blkid /dev/mapper/<my_logical_group>-safe_vault 
/dev/mapper/<my_logical_group>-safe_vault: UUID="d266ae14-955e-4ee4-9612-326dd09a463b" TYPE="crypto_LUKS" 

fstab

$ sudo cat /etc/fstab | grep safe_vault
/dev/mapper/safe_vault      /safe-vault     ext4    defaults    0 2

What I've done...

So I went to the devoper's website and in the Common Problems FAQ they say:

Check that you have the device mapper and the crypt target in your kernel. The output of "dmsetup targets" should list a "crypt" target. If it is not there or the command fails, add device mapper and crypt-target to the kernel.

So I did, turns out I don't have a crypt target:

$ sudo dmsetup targets
striped          v1.4.1
linear           v1.1.1
error            v1.0.1

The problem is that I don't know how to add such a target.

I think this (not having the crypt target) maybe causing the crypttab configuration to be ignored at boot-time and thus trying to mount the entry in fstab fails because cryptsetup has not mapped my encrypted volume to /dev/mapper/safe_vault.

NOTE:

The encrypted volume can successfully be manually mapped, mounted and written:

$ sudo cryptsetup luksOpen /dev/mapper/<my_logical_group>-safe_vault safe_vault
Enter passphrase for /dev/mapper/<my_logical_group>-safe_vault: 

$ sudo mount /dev/mapper/safe_vault /safe_vault

This is how it looks after mapping and mounting it:

$ sudo lsblk -o name,uuid,mountpoint
NAME                                  UUID                                   MOUNTPOINT
sda                                                                          
├─sda1                                28920b00-58d3-4941-889f-6249357c56ee   
├─sda2                                                                       
└─sda5                                uhBLE7-Kcfe-RMi6-wrlX-xgVh-JfAc-PiXmBe 
  ├─<my_logical_group>-root (dm-0)       1bed9027-3cf7-4f8d-abdb-28cf448fb426   /
  ├─<my_logical_group>-swap_1 (dm-1)     a40c16c4-7d0c-46d7-afc8-99ab173c20bb   [SWAP]
  ├─<my_logical_group>-home (dm-2)       e458abb7-b263-452d-8670-814fa737f464   /home
  ├─<my_logical_group>-other (dm-3)      0a1eec42-6534-46e1-8eab-793d6f8e1003   /other
  └─<my_logical_group>-safe_vault (dm-4) d266ae14-955e-4ee4-9612-326dd09a463b   
    └─safe_vault (dm-5)               9bbf9f47-8ad8-43d5-9c4c-dca033ba5925   /safe-vault
sr0  

UPDATE

  • It turns out that I do have the crypt target but for it to show up with dmsetup targets I had to first cryptsetup luksOpen <my-device>
  • I've tried using UUIDs instead according to @Mikhail Morfikov's answer but it still fails at boot-time.

I still think the issue is that somehow the encrypted volume is not being mapped(opened with cryptsetup luksOpen) at boot-time thus no /dev/mapper/<safe_vault or UUID> exists, then trying to mount it (fstab) fails.

UPDATE 2

It turns out I didn't have the necessary scripts to mount at boot time. See the note in @MikhailMorfikov's answer.

pgpb.padilla
  • 363
  • 1
  • 3
  • 8
  • 1
    Does the crypt target show up after you manually do `luksOpen`? I'd expect that if it wasn't there, luksOpen would fail too. – user Jan 04 '14 at 20:03
  • Ok, after `sudo cryptsetup luksOpen` two new targets appear for `sudo dmsetup targets`: `error` and `crypt`. I guess I need to change the question then... – pgpb.padilla Jan 04 '14 at 21:35
  • Is it a partition or a file container? – Mikhail Morfikov Jan 05 '14 at 05:07
  • `/dev/mapper/-safe_vault` is a logical volume created with LVM and `/dev/mapper/safe_vault` is the device to which it is mapped by doing `cryptsetup luksOpen /dev/mapper/-safe_vault`. Do you know if `crypttab` works with LVM volumes? – pgpb.padilla Jan 05 '14 at 06:45
  • I have lvm inside a luks partition, actually I have my entire 1,5TB disk encrypted (except `/boot`). All mounted at boot without a problem. Are you sure that you updated `initramfs` after editing `/etc/crypttab`? Can you show the output of `lsblk -o name,uuid,mountpoint` when everything is mounted and works as it should? – Mikhail Morfikov Jan 05 '14 at 10:42
  • I have indeed run `update-initramfs -u -k all` before rebooting. I do this everytime I try a different configuration but so far I get the same result. – pgpb.padilla Jan 05 '14 at 19:20
  • @MikhailMorfikov you said you have an encrypted partition and inside it the LVM volumes. I'm trying to do it the other way around, I have an unencrypted partition `sda5`, everything inside it is managed with LVM and I want to encrypt only the volume corresponding to `safe_vault`. I have updated the question with the ouput of `lsblk`. – pgpb.padilla Jan 05 '14 at 19:24
  • You have to run `lsblk` as root. – Mikhail Morfikov Jan 05 '14 at 23:41
  • I tested the configuration -- see details in the answer. – Mikhail Morfikov Jan 06 '14 at 06:47
  • If you like me are trying to setup encrypted root on Gentoo with systemd and dracut, make sure to **enable the `cryptsetup` use flag on systemd**. Not posting as an answer because this question is about debian, but I hope it helps someone. – Shelvacu Jun 19 '23 at 05:55

3 Answers3

21

You have to pay attention to UUIDs . For instance, this is my configuration:

# lsblk -o name,uuid,mountpoint
├─sda2                         727fa348-8804-4773-ae3d-f3e176d12dac
│ └─sda2_crypt (dm-0)          P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi
│   ├─debian_crypt-swap (dm-1) 3f9f24d7-86d1-4e21-93e9-f3c181d05cf0   [SWAP]
│   ├─debian_crypt-tmp (dm-2)  93fc8219-f985-45fb-bd5c-2c7940a7512d   /tmp
│   ├─debian_crypt-home (dm-3) 12e8566c-8f0f-45ec-8524-6d9d9ee91eae   /home
│   └─debian_crypt-root (dm-4) 9685570b-4c9e-43ea-815e-49d10dc7a1bf   /

I have one encrypted partition (sda2) with 4 volumes (LVM). What I need is to set two UUIDs in the right files. The sda2 UUID goes to /etc/crypttab and the volume UUID (for example debian_crypt-root) goes to /etc/fstab .

So, it would be:

# cat /etc/crypttab
sda2_crypt              UUID=727fa348-8804-4773-ae3d-f3e176d12dac   none        luks

# cat /etc/fstab
UUID=9685570b-4c9e-43ea-815e-49d10dc7a1bf       /               ext4    defaults,errors=remount-ro              0 1

After changing the /etc/crypttab file, you have to rebuild initramfs:

# update-initramfs -u -k all

NOTE

The package cryptsetup has to be installed because it has startup scripts which provide support for automounting encrypted volumes at boot.

Why bother to mention this? Well, if you setup LVM during the installation Debian Wheezy installs packages cryptsetup-bin, libcryptsetup4 and lvm2 but not cryptsetup, thus you have the tools to setup LVM & LUKS devices but not the scripts necessary to mount LUKS devices at boot time. Those come in the package cryptsetup.

pgpb.padilla
  • 363
  • 1
  • 3
  • 8
Mikhail Morfikov
  • 10,309
  • 19
  • 69
  • 104
  • I've tried using `UUID` but I get the same error. I will update the question with details. – pgpb.padilla Jan 04 '14 at 21:48
  • Hi, this is getting a bit too long, can we [chat](http://chat.stackexchange.com/rooms/info/12341/lvmdm-crypt)? – pgpb.padilla Jan 07 '14 at 06:44
  • As an aside, even if you do not edit /etc/crypttab, it seems that disks will edit it for you if you alter certain encryption settings. This answer helped me fix the mistakes I made with disks (and perhaps more mistake when trying to undo disks). – sage Apr 29 '19 at 16:24
2

It seems that @Mikhail Morfikov's answer covers mounting during the initramfs stage. An alternative (if it is not the root filesystem) is to decrypt and mount the partition automatically via systemd, after the linuz kernel is loaded. Of course this is only possible if you are running systemd. I will explain the method here:

The /etc/crypttab entry:

crypt2 UUID=e412-blahblah /path/to/crypt2.key luks,noauto

Here noauto is an instruction not to try to decrypt the disk during the initramfs stage.

Above, e412-blahblah is the UUID of partition containing the luks system, in my case a partition /dev/sdb2:

# blkid | grep sdb2
/dev/sdb2: UUID="e41274d8-fd83-4632-b560-ad0ba113ae75" TYPE="crypto_LUKS" PARTUUID="5673a908-02"

During linuz kernel startup, systemd will read the /etc/crypttab file and create a runtime service file /run/systemd/generator/[email protected]. However, that service is not automatically run. You can run it manually

systemctl start [email protected]

but to decrypt it and then mount it during startup the /etc/fstab may require it as follows:

/dev/mapper/crypt2--vg-data /media/crypt-data ext4 defaults,noauto,user,x-systemd.automount,[email protected] 0 2

Here x-systemd.automount is an instruction to systemd to mount /media/crypt-data, and [email protected] is an instruction to systemd that decryption of crypt2 is required before that is possible.

In the systemd will not actually mount the directory until the first time it is accessed, e.g. ls /media/crypt-data, then it will mount just-in-time and appear thereafter in /proc/mounts.


Related

You may ask "*why have an encrypted data disk with the key in the root file system?". It is because the root file system is also encrypted, so the key is safe. The root file system is decrypted during the initramfs stage of boot, a la Mikhail's answer. I have another entry in the /etc/crypttab file for that:

crypt1 UUID=8cda-blahbalh none luks,discard,lvm=crypt1--vg-root

and I describe setting up that and a boot usb here

Craig Hicks
  • 644
  • 8
  • 13
2

In addition: On Debian-based systems before running update-initramfs command make sure that cryptsetup-initramfs package is installed. If not, install it first:

apt-get install -y cryptsetup-initramfs
Vitaalz
  • 31
  • 2