Bdtyktl

I've followed this tutorial to install Ubuntu 15.10:

https://thesimplecomputer.info/full-disk-encryption-with-ubuntu

After restarting my computer I got to the grub menu and chose Ubuntu. Shortly after that I got this error:

/run/lvm/lvmetad.socket: connect failed: No such file or directory

WARNING: Failed to connect to lvmetad. Falling back to internal scanning.

These messages keep adding up on a black screen every second. After a while, I get access to the initramfs ash console.

what am I doing wrong?

I've seen the same error today on a laptop running Ubuntu 15.10 which I always kept up-to-date but had not rebooted for a month until I wanted to test a current kernel (i.e., there might have been a recent change).

Anyways, I found that in my case the underlying cause was actually a "missing" swap partition due to a setup glitch when following the above tutorial. If this is the case and/or you're actually using lvm, you might be able to skip step 2 below.
Of course, you might also see the above error message in case your system (or a secondary data) partition has been damaged or cannot be found (see step 3).

Step 1: Mount your system, boot partitions following the aformentioned tutorial

Let's say your (ext2) boot partition is /dev/sdX1, your (encrypted) swap partition is /dev/sdX2, your (encrypted) data partition is /dev/sdX3 and you've successfully decrypted the latter using cryptsetup luksOpen /dev/sdX3 data, followed by mounting it: mkdir /tmp/data; mount /dev/mapper/data /tmp/data.

Pay attention to the bind mounts in the tutorial and make sure to mount /dev/sdX1 so that you can access it from your system partition's /boot directory (this is crucial as we have to execute update-initramfs).

In the following, we're assuming you've sucessfully executed chroot /tmp/data/@ubuntu1510 (or whatever your mounted system partition is called)

Step 2: Get rid of the above error message

I'm using btrfs (as you might have guessed from the mentioned subvolume name), so lvmetad can easily be disabled as follows without loss of functionality:

• edit /etc/lvm/lvm.conf and change use_lvmetad=1 to use_lvmetad=0
  


• execute update-initramfs -k *KERNEL_VERSION* -u ; sync
  

Now, you could reboot and the error message should be gone. However, in my case, the next error message[1] pointed me to the underlying problem mentioned above, so while we're at it, ...

Step 3: Make sure that /etc/crypttab points to the correct, undamaged partitions

First, run sfdisk --list /dev/sdX and check that your encrypted swap partition (in my case, /dev/sdX2) actually does not show up as a (normal) swap partition. If it did (as in my case), this meant that booting, e.g., using a rescue disk will likely make use of that available swap partition, thereby overwriting your cryptsetup related metadata (keyphrase and UUID).

Next, have a look at /dev/disk/by-uuid and compare the respective UUIDs of your encrypted partitions with those contained in /etc/crypttab. My guess at this point: In your case, there's a mismatch.

If the dedicated encrypted swap partition is nowhere to be found below /dev/disk/by-uuid, that's because it's currently in use by your rescue system. In that case, do the following:

• make sure to stop using the partition: swapoff -a
  


• reformat it: mkfs.ext2 /dev/sdX2 (this is crucial, especially when using GPT partitions[2], as it undoes the glitch I mentioned earlier. The likely cause of the partition showing up as type "swap" in the sfdisk listing is that you/I mistakenly used mkswap /dev/sdX2 when setting up the partition in the beginning.)


• follow the tutorial to encrypt the partition and set a passphrase; afterwards, open it using cryptsetup and properly reformat the now-decrypted partition (using something like mkswap /dev/mapper/swap)


• ensure that sfdisk --list /dev/sdX will not identify the swap partition as such (in that case, repeat the last steps)

Now, recheck that the UUIDs listed in /etc/crypttab are in line which what you see below /dev/disk/by-uuid for your respective encrypted partitions.

Again, to make the changes permanent, you must execute update-initramfs as shown above.

If you're satisfied, make sure everything is written to disk and reboot the system (no need to unmount everything manually). Afterwards, your problem should be gone.

[1] maybe I did not pay attention the first time or the first error message "masked" the second one; i.e., only after rebooting (with use_lvmetad=0), I was presented with "Reading all physical volumes. This may take a while..." (repeated multiple times), followed by "ALERT! /dev/disk/by-uuid/... does not exist.". (It should be noted that update-initramfs also complained about a missing partition.)

[2] because their type is deducted from analysing their contents and not ultimately specified by a flag/byte (that's why there's no easy way to, e.g., change the GPT file system type using [g]parted.)

Ubuntu 18.04.1 LTS here. It had run for a couple of months unattended, but when I returned I found the keyboard unrecognized. When I rebooted, I got the 'cannot connect to lvmetad' message and more about more about not being able to get "UEFI db list".

I had installed without disk encryption.

The UEFI message was worrisome because this was my first install on a UEFI computer, so I had no experience, and am frankly still uninformed about the usefulness. My problem was compounded by the fact that I had made used 'lvm' on what was going to be my '/', root, volume. (In fact, I've already forgotten how I accomplished THAT in the first place! Hey. I'm old.)

However, when the machine would not reboot, I searched for a solution and found nothing definitive, but did notice that a) my EFI partition was smaller than the 500MB recommended on one site, and b) the separate /boot/ partition I had arranged for was probably irrelevant and unused. I thought it possible that an unattended upgrade, perhaps, had caused something, possibly, to fill up its allotted space.

I decided to reinstall--which worked, and left my /home/ directory structure unmolested. I haven't checked /etc/, but did make copies of both of them beforehand[1], so I can check later. /etc/ is really small.

I also deleted deleted and combined the partitions for EFI and /boot/ into a single, larger EFI partition (>750MB).

It reboots now, but a single error message flashes too fast to read, and I am not offered a boot 'menu' of Linux images to boot, it boots directly into Ubuntu instead. There is still more work to do, with grub I suppose, to address this. But at least my files are back.

[1] I booted the Ubuntu installation from a USB stick, and chose to "try" Ubuntu, which allowed me to make copies of etc and home, before choosing "Install" from the desktop.