"Lvmetad is not active yet, using direct activation during sysinit" on boot?

Question

Some time ago I installed Ubuntu 16.04 on my PC. Everything went well and no problems so far. When the first kernel update came out I could not start it and got the following error:

Lvmetad is not active yet, using direct activation during sysinit
Volume group "ubuntu-vg" not found
Cannot process volume group ubuntu-vg

When I pick the old kernel from the GRUB menu it was ok and no problems there. After that another kernel update came out and also that one did not work out. Basically after clicking the newer kernel version I got the error and was repeated on the screen over and over again (with no end, not tested at least).

I tried the following without any luck:

• Error Run LVM LVMETAD socket connect failed: no such file or directory (both answers)

• lvmetad is not active yet; using direct activation during sysinit (tried the only answer to that one)

Neither worked. I have my disk encrypted as it was an option during the install and I thought why not? I think something is going on with that although it is more like a gut feeling than hard evidence. I searched if it is possible to deactivate the encryption and was a pretty tedious work, so I kind of stopped looking for that, but if that seems to be the solution I can still try it.

So the installed kernel version was 4.4.0-21-generic (as displayed in GRUB). Works fine no problems. After that the installed kernels were4.4.0-22-generic, 4.4.0-24-generic and 4.4.0-28-generic (as seen in GRUB). Which all three don't work and give the exact same previous error.

Why am I getting the error and how do I solve it?

Solution

I had the same error messages after I did a release-upgrade from Ubuntu 14.04 LTS to 16.04 LTS in a chroot (chroot as described in this German article) from a live system.

The error occurred before the password prompt. As the LVM volume group is usually within the encrypted volume, it must be a dm_crypt/LUKS configuration issue.

I found a solution here and will explain it below.

---

In my case, the name of the mapper of the encrypted volume was different from the name given in /etc/crypttab.

I picked the name of the luks mapper from the output of ls -l /dev/mapper, after opening the encrypted device with the the graphical file manager. In my case, the output was:

control
luks-87fc4c8e-017b-8482-cd09-7332fe351628
vgubuntu-root
vgubuntu-swap

Then, as root, I changed my /etc/crypttab (please note the beginning of the line) from:

sda5_crypt UUID=87fc4c8e-017b-8482-cd09-7332fe351628 none luks,discard

to:

luks-87fc4c8e-017b-8482-cd09-7332fe351628 UUID=87fc4c8e-017b-8482-cd09-7332fe351628 none luks,discard

Finally I updated my initramfs:

update-initramfs -u -k all

---

It was a bit confusing that these two names were different. One would assume that when the mapper is created, its name is taken from the crypttab. Anyway, it worked.

I did the whole stuff in a chroot, running a live system. It might also work from the busybox shell in which you drop after booting your system, but I haven't tried.

Comments

[Woeitg]

I have the same problem on xubuntu. did you find a solution?

[Admin]

@Woeitg , nope sorry..... I find it surprisingly quiet around this topic tbh. I hope some people can help us out, since I think that just like u and me there will be more people.

[Woeitg]

maybe you want to invest some reputation on it!? though I see you dont have much of

[Admin]

Lets see what happens

[Admin]

Well, I think asking the question: "why would I install updates?" is basically the same thing. Here is one of the first hits on the internet: superantispyware.com/blog/2013/10/… . Seriously, for both security and features you definitely want to use the last version of the kernel.