Comment # 9 on bug 1148500 from Martin Wilck

The obvious solution is to make /run available in the chroot.

Honestly, I don't know how installation ever worked without this, in
particular, initrd creation and device detection is bound to fail without /run.
Applications rightfully assume that they can make libudev calls. And libudev
doesn't work if it can't find the udev db under /run/udev.

(Correction wrt comment 0: lvm2 does *not* open files under /run/dev directly.
Rather, we are looking at valid libudev calls).

(One might argue that it's wrong to repeat the search for the udev data over
and over again. lvm iterates 100 times and waits 0.1s each time, for each
device in the system, which makes for a long wait, and then dracut seems to
repeat the "lvm vgs" call, either indefinitely or, at least, very often. But
even if we cut down on these wait times, on systems with may devices, the
OpenQA timeout would occur.)

So, @yast team, please make sure that /run is bind-mounted into the /mnt chroot
during installation, in particular while the initrd is rebuilt.

The open question for me is: why did we see this only with encrypted volumes? 
I would expect this problem to occur whenever lvm2 "scan" commands are run in
the chroot environment and /run isn't available there, which has nothing to do
with encryption.

Is it maybe an OpenQA test artifact? Perhaps, without encryption, there are
less block devices overall, so that the OpenQA timeout is avoided? Or maybe
bind-mounting /run into the chroot simply fails when encryption is on?