After investigation the problem is inside pvscan itself I test with and without this commit and it does the trick. Without I can reproduce, with I can't.
--- commit 15da467b52465076a8d587b94cc638bab8a0a95c Author: David Teigland <teigl...@redhat.com> Date: Wed Jun 15 14:19:18 2016 -0500 pvscan: do activation when lvmetad is not running When pvscan --cache -aay fails to connect to lvmetad it will simply exit and do nothing. Change this so that it will skip the lvmetad cache step and do the activation step from disk. --- The commit above introduce a regression fix later in : -- commit f77fe436afb76ddb798d236d34daf50413a184f6 Author: David Teigland <teigl...@redhat.com> Date: Thu Jun 16 12:04:05 2016 -0500 pvscan: don't activate LVs when use_lvmetad=0 commit 15da467b was meant to address the case where use_lvmetad=1 in lvm.conf, and lvmetad is not available, in which case, pvscan --cache -aay should activate LVs. But the commit unintentionally also changed the case where use_lvmetad=0 in lvm.conf, in which case pvscan --cache -aay should not activate LVs, so fix that here -- Both above commits have been applied on top on a major code refactoring not yet in lvm2 xenial-updates : -- commit 9b640c36841e2790731d54a5830dcea8203f9e80 Author: David Teigland <teigl...@redhat.com> Date: Thu Apr 28 09:37:03 2016 -0500 pvscan: use process_each_vg for autoactivate This refactors the code for autoactivation. Previously, as each PV was found, it would be sent to lvmetad, and the VG would be autoactivated using a non-standard VG processing function (the "activation_handler") called via a function pointer from within the lvmetad notification path. Now, any scanning that the command needs to do (scanning only the named device args, or scanning all devices when there are no args), is done first, before any activation is attempted. During the scans, the VG names are saved. After scanning is complete, process_each_vg is used to do autoactivation of the saved VG names. This makes pvscan activation much more similar to activation done with vgchange or lvchange. The separate autoactivate phase also means that if lvmetad is disabled (either before or during the scan), the command can continue with the activation step by simply not using lvmetad and reverting to disk scanning to do the activation. -- I'll investigate and see how feasible a backport and if eligible for SRU. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1573982 Title: LVM boot problem - volumes not activated after upgrade to Xenial Status in curtin: Incomplete Status in MAAS: Incomplete Status in lvm2 package in Ubuntu: Confirmed Bug description: Soon after upgrade to Xenial (from 15.10) the boot process got broken. I'm using LVM for /root swap and other partitions. === The current behaviour is: When I boot short after the Grub login screen I'm getting log messages like: --- Scanning for Btrfs filesystems resume: Could not state the resume device file: '/dev/mapper/VolGroup....' Please type in the full path... --- Then I press ENTER, for a few minutes some errors about floppy device access are raised (for some reason it tries to scan fd0 when floppy drive is empty). And then: --- Gave up waiting for root device. Common problems: ... ... ALERT! UUID=xxx-xxx.... does not exist. Dropping to a shell. --- From the BusyBox shell I managed to recover the boot by issuing "lvm vgchange -ay", then exit and then boot continues fine (all LVM file systems are successfully mounted). === One workaround so far is creating /etc/initramfs-tools/scripts/local-top/lvm2-manual script doing "lvm vgchange -ay". But I'm looking for cleaner solution. Boot used to work fine with 15.10. Actually the first boot after upgrading to Xenial actually worked OK too, I'm not sure what might changed meanwhile (I've been fixing some packages installation since mysql server upgrade has failed). === # lsb_release -rd Description: Ubuntu 16.04 LTS Release: 16.04 To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1573982/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
