Ubuntu won't boot because of lvmetad

Solution 1:

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 $(uname -r) -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.)

Solution 2:

The Failed to connect to lvmetad error can happen because the disk is 100% full. To fix this, boot from a USB thumb drive, mount the full disk, delete some unneeded files, and reboot. I also reinstalled the boot system - I don't know if that is necessary or not.

These are the commands that resolved the problem for me, run from a terminal after booting from the USB drive. I have stock Ubuntu 18.04 with full-drive encryption. YMMV.

1. Mount the drive:

   sudo cryptsetup luksOpen /dev/sda5 sda5_crypt
   sudo vgscan --mknodes
   sudo vgchange -ay
   sudo mount /dev/mapper/ubuntu--vg-root /mnt
   

2. Delete unneeded files (cd /mnt/home/your_username ... rm ...)

3. (may not be necessary) reinstall the boot system:

   cd /mnt/
   sudo mount /dev/sda1 boot
   for d in dev sys proc run; do sudo mount --bind /$d $d; done
   sudo vi etc/crypttab # make sure first line uses "sda5_crypt"
   sudo chroot .
   update-grub
   grub-install /dev/sda
   update-initramfs -u -k all
   exit
   sudo umount dev sys proc run boot
   

4. Unmount:

   cd /
   sudo umount /mnt
   sudo vgchange -an
   sudo cryptsetup close sda5_crypt
   

5. Reboot:

   sudo reboot
   

Solution 3:

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.

Solution 4:

I've encountered this problem after playing with my Intel drivers on my laptop. I used a third-party PPA to install the drivers and that went wrong, since I only had one graphics card, the integrated one, I couldn't boot.

To solve the issue I've booted in recovery mode, removed the third party PPA and reinstalled the drivers.

sudo dpkg  --purge --force-all libgl1-mesa-dri
sudo dpkg  --purge --force-all libgl1-mesa
sudo dpkg  --purge --force-all libgl1-mesa-glx:i386

sudo apt-get autoremove
sudo apt-get update

sudo apt-get install --reinstall xserver-xorg-video-intel libgl1-mesa-glx libgl1-mesa-dri xserver-xorg-core
sudo dpkg-reconfigure xserver-xorg

To boot in recovery mode I used grub.