14

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.

  • 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. – a CVn Jan 4 '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 4 '14 at 21:35
  • Is it a partition or a file container? – Mikhail Morfikov Jan 5 '14 at 5:07
  • /dev/mapper/<my-logical-volume>-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/<my-logical-volume>-safe_vault. Do you know if crypttab works with LVM volumes? – pgpb.padilla Jan 5 '14 at 6: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 5 '14 at 10:42
14

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.

  • I've tried using UUID but I get the same error. I will update the question with details. – pgpb.padilla Jan 4 '14 at 21:48
  • Hi, this is getting a bit too long, can we chat? – pgpb.padilla Jan 7 '14 at 6: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 at 16:24
0

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/systemd-cryptsetup@crypt2.service. However, that service is not automatically run. You can run it manually

systemctl start systemd-cryptsetup@crypt2.service

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,x-systemd.requires=systemd-cryptsetup@crypt2.service 0 2

Here x-systemd.automount is an instruction to systemd to mount /media/crypt-data, and x-systemd.requires=systemd-cryptsetup@crypt2.service 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.