I am troubleshooting a debian system that will not boot; the system booted fine, and one day ceased to do so (possibly but not definitely related to an apt upgrade). It has a small boot partition (sda1), a LUKS container on sda2. Inside the LUKS container is an LVM layer with two members formatted as ext4 (/ and /home).

Upon booting, cryptsetup does not even run and the following error is shown: "WARNING: Failed to connect to lvmetad. Falling back to internal scanning." The computer then drops to an initramfs console.

Mounting and chrooting the affected disk on another computer, I find when attempting to update initramfs that /etc/cryptsetup is invalid, despite appearing to be fine. The error is: "cryptsetup: WARNING: invalid line in /etc/crypttab for sd1 -"

My crypttab file has merely the following:

crypt    UUID=<uuid>    none    luks

blkid or lsblk confirm that the appropriate UUID has been selected (that of /sda2, whose child is a LUKS container named crypt).

Some version information:

debian: 9.8
cryptsetup: 1.7.3
lvm: 2.02.168(2)

Note that sd1 is another LUKS device, that of the computer on which the faulty drive has been mounted for troubleshooting. Perhaps in that case, the warning can simply be ignored? Even so, the problem (crypt is bypassed) persists after update-initramfs when the faulty drive is used as the boot device.

At this point, since I'm not really sure what the problem is, I am considering reinstalling grub and reinstalling the kernel. However, I would appreciate suggestions on alternative steps. Many thanks.


The error about an invalid crypttab resulting from attempting to run update-initramfs was merely a result of the fact that the host computer also had a LUKS container. The solution was to perform exactly the same steps from a system without any other LUKS devices (I used a "live" bootable .iso image for the task). After booting the .iso, update-initramfs -u -k all worked without a hitch and the system regained bootability. Perhaps there is an option by which cryptsetup can be instructed to ignore irrelevant LUKS devices that happen to be present on the machine used as a rescue system.

  • did this "update-initramfs -u -k all" line have to be performed on the original Luks volume, or did you simply open up a terminal window fresh from the .iso and type it. Also, I assume this would be done with sudo? I have nearly the same issue and am ending up (unable to even use the keyboard, at a initramfs console. I have been able to access the encrypted partition via a Live USB. I am hopeful that your solution will work for me but would love to make sure I'm doing it correctly. Thank you!! – user1149499 May 13 '20 at 20:40
  • @user1149499: Yes, it had to be performed on the damaged LUKS volume. What I did was the following: log in to a system that doesn't have any native LUKS volumes; mount the disk that had a faulty LUKS container, and prepare to chroot it; within the chrooted session, run update-initramfs (requires superuser privileges). While this worked for me, I don't know if your issue is exactly the same, so you might want to open a new question. Be sure to have back-up(s) available in case something goes wrong. – user001 May 14 '20 at 20:00

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.