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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1573982 Title: LVM boot problem - volumes not activated after upgrade to Xenial To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1573982/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
