I've followed this tutorial to install Ubuntu 15.10:


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?

  • ash console or bash console? typo?
    – Thufir
    Commented Feb 5, 2017 at 20:48

5 Answers 5


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.)

  • "aformentioned tutorial" went away - so this answer is only half-useful now :(
    – codeling
    Commented Mar 24, 2020 at 10:28
  • @codeling Well, there's always the Wayback Machine (remember that this topic is rather old and newer tutorials exist): web.archive.org/web/20180530122126/http://… Commented Mar 24, 2020 at 12:56
  • There is no use_lvmetad Commented Feb 25, 2021 at 17:12

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 .
    grub-install /dev/sda
    update-initramfs -u -k all
    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
  • I had this problem due to a nearly full drive, and was able to solve it by booting into recovery mode via grub, getting a root shell, and removing some unnecessary files (apt-get clean and some rms).
    – ntc2
    Commented May 9, 2020 at 6:16
  • 1
    For those who are in this bucket, this worked like a charm. Things to watch out for, your drive may not be /dev/sda5, so you might need to ls /dev/sda* to see the list of drives and then choose one. You should change the number for both /dev/sda5 sda5_crypt e.g. /dev/sda3 sda3_crypt
    – nycynik
    Commented Jul 6, 2020 at 23:17
  • Thanks! Worked for me.
    – Juampy NR
    Commented Nov 10, 2020 at 18:34

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.

  • with mount /dev/mapper/data /tmp/data I get unknown filesystem type LVM2_member. Commented Jul 18, 2019 at 12:09

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.

  • Thanks, this is my problem too. Actually lvmetad is always not working, but the driver problem makes it apparent. After all lvmetad needs no fixing at all. I just reinstall my video driver, my input driver and my kernel, and all is back again.
    – WesternGun
    Commented Mar 29, 2021 at 9:10

It's not necessary boot your system from a USB or something else. I had the same problem and a reason - because the disk is 100% full. Next solution helped me.

  1. Restart your system. With BIOS, quickly press and hold the Shift key, which will bring up the GNU GRUB menu.

  2. After press 'e' to edit Ubuntu settings. In this problem you can find screens. Find a string starting like 'linux *', like this:

    linux     /boot/vmlinuz-4-4.0-22-generic root=UUID=43ad24d3-e\
    c5b-44ee-a099-a88eb9520989 ro  quiet splash $vt_handoff


    ro  quiet splash $vt_handoff

    And add:


    Once ready press Ctrl+x or F10 to boot.

  3. The root partition is mounted read-only. To mount it read/write, enter the command

    mount -o remount,rw /
  4. Find out what is went wrong:

    df -hT
  • This is the only solution that worked to me (not nvidia problem, not kernel image problem...) I couldn't finish the 3rd step, because the erro messaged appered in the root terminal while I was writing (!)... I rebooted the computer and everything it's working fine (finger crossed). Thanks!
    – ifrit
    Commented Mar 14, 2022 at 8:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .