LVM-based filesystem does not boot with kernel 4.4 (but works with 4.2)

[Frédéric Grosshans]

I‘ve updated my home-made NAS from wily to xenial and it stopped booting.

Selecting the 4.2 kernel on the grub menu makes it work again.

The working kernel is 4.2.0-35-generic

The failing kernel is 4.4.0-21-generic.

When the booting sequence freezes, I can have a terminal with the following text :

 lvmetad is not active yet, using direct activation during sysinit
Scannig for Btrfs flesystems
_

Actually my set-up is lvm based, and the correponding lines of the output of a mount command are

/dev/mapper/clio-root on / type btrfs (rw,relatime,nospace_cache,subvolid=256,subvol=/@)
/dev/mapper/clio-root on /mnt/clio-root type btrfs (rw,relatime,nospace_cache,subvolid=5,subvol=/)
/dev/mapper/clio-root on /home type btrfs (rw,relatime,nospace_cache,subvolid=257,subvol=/@home)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Paul Coleman (pcoleman)]

Similar issue, same kernel version, same workaround. Message is:

[ 1.883338] nouveau 0000:02:00.0: bus: NMIO write of 00000002 FAULT at 4188ac
  [ IBUS ]
    1vmetad is not active yet, using direct activation during sysinit

and then hangs until I reboot into the older 4.2 kernel.

[Paul Coleman (pcoleman)]

Didn't wait long enough - eventually got a "couldn't stat the resume device file ' ...

then got the option to continue boot and it worked. After boot verified the existence of the file noted above that couldn't be stat'ed - no obvious problem there. On next boot, problem re-occurred.

[Frédéric Grosshans (fgrosshans)]

Update : It works now with 4.4.0-22, in recovery mode, and continuing the normal boot sequence.

[Nick Buonanno (nick-buonanno)]

I'm currently encountering this with 4.4.0-36, although I had no other 4.x kernels installed to begin with, so haven't tried any of those. Still boots fine with 3.13.

[qwerty (foramail)]

I encounter the issue as u. Here is a summary of the problem and what I tried: http://askubuntu.com/questions/797128/lvmetad-is-not-active-yet-using-direct-activation-during-sysinit-on-boot

[Tjalling Ran (tjallingran)]

The issue is still present with 4.4.0-42. It's completely preventing me from booting into Ubuntu. The error message is as follows:

lvmetad is not active yet, using direct activation during sysinit
rootfs: clean, 271911/1831424 files, 1561286/7323648 blocks

Here, "rootfs" is my root filesystem (ext4), located on an LVM logical volume.

I also tried the following kernels (from http://kernel.ubuntu.com/~kernel-ppa/mainline/) as well:
- v4.4.14-xenial (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.14-xenial/)
- v4.7.7 (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.7/)
- v4.8.1 (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8.1/)

I installed these by booting a live cd and chrooting into the "rootfs" filesystem, and then updating grub.

The problem is still present in all of these kernels (with the slight variation that the error message is only shown briefly, and replaced by a blank screen)

[Tjalling Ran (tjallingran)]

I edited the title, as it applies to desktop installs of xenial (such as mine) as well.

[Tjalling Ran (tjallingran)]

In case anyone is looking for a (sort of) workaround: a separate non-LVM boot partition (/boot as mountpoint) circumvents the problem.

I'm not sure how easy this is to set up on an existing system. I had the luxury of being able to do a clean install without much trouble. Of course, this "workaround" is a bit heavy-handed, and should not be necessary at all, as grub2 supports booting from LVM. But at least it allows having the rest of the root filesystem on LVM volume(s).

[Nick Buonanno (nick-buonanno)]

I'll back up Tjalling's work-around. I already had my boot partition on a separate non-LVM partition at the front of my drive. My system started booting normally on 4.4.0-38, and continues to do so on 4.4.0-42.

[Frédéric Grosshans (fgrosshans)]

For 4.4.0-45, it only works in recovery mode, one hit on the return key + two confirmations to resume normal boot.

Everything works fine withe the 4.8.0-26 kernel of Yaketty Yak (Ubuntu 16.10)