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.

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.