This has some history. For some time, "use_lvmetad = 1" in /etc/lvm/lvm.conf used to work. With some update this got reset to "0" by default. While the system used to work, it became apparent that running "dracut" (former "mkinitrd") now takes appr. 1 minute per installed kernel. Also, running "lvs" almost takes forever... When I compared my Tumbleweed installation with my other Leap installations, I found out that on Leap "lvmetad" is running, resulting in snappy responses after "lvs" commands, and also pretty fast "dracut" runs.
OK, let's activate "lvmetad" in Tumbleweed. First I activated/enabled and started "lvm2-lvmetad.socket", followed by stopping a potentially running (but there was't any) "lvm2-lvmetad.service". I then set "use_lvmetad = 1" in /etc/lvm/lvm.conf, started and enabled "lvm2-lvmetad.service" and rebuilt the initrd. The following reboot then got hung at
"Waiting for /dev/mapper/rdisk00-swapdev1 to appear"
and a similar message for the corresponding LV for /var.
My setup is using /dev/md0 (MD-raid10) as a physical volume, providing space for such volumes as /var, /swapdev1 and /home. It is my understanding that at some point "/usr/lib/udev/rules.d/69-dm-lvm-metad.rules" should run "pvscan --cache" to provide the necessary udev events feeding into dm/udev to actually activate volumes, but, apparently this doesn't happen. Yes, your understanding is quite right. In case of use_lvmetad=1, for NON-ROOT partitions on LVM, it is the command `pvscan --cache --activate ay major:minor` in lvm2-pvscan@.service to activate
http://bugzilla.suse.com/show_bug.cgi?id=982329
http://bugzilla.suse.com/show_bug.cgi?id=982329#c8
--- Comment #8 from Liuhua Wang
Whe I got stuck in the single-boot/rescue phase after the boot, running "pvscan --cache" manually, followed by a "udevadm trigger" made the missing VG and LVs available; but, since /var is on an LV, the system is not actually usable at that point in time. I then downgraded the "lvm2" package (from "2.02.141-64.2" in current TW) to "2.02.120-67.1" to Leap's most current version, repeated all the lvmetad related configs from above, rebuilt the initrd, rebooted and - voila - my system boots again - and running "dracut" is not at all that boring again (appr. 10 secs. per kernel now).
It looks to me that the current LVM2 package is not lvmetad capable.
Would you please tell me whether the following service is running or not? systemctl status initrd-udevadm-cleanup-db.service Thank you for reporting and sorry for the problems brought to you! -- You are receiving this mail because: You are on the CC list for the bug.