http://bugzilla.opensuse.org/show_bug.cgi?id=1148500 http://bugzilla.opensuse.org/show_bug.cgi?id=1148500#c2 --- Comment #2 from Martin Wilck --- Created attachment 815984 --> http://bugzilla.opensuse.org/attachment.cgi?id=815984&action=edit strace of dracut This is strace -f -p output of dracut trying to build the initrd. You can see vgs trying to access files under /run/udev/data and getting -ENOENT.

12453 openat(AT_FDCWD, "/run/udev/data/b7:0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 12453 openat(AT_FDCWD, "/run/udev/data/b7:0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

dracut seems to re-run vgs in this situation, so that the problem occurs repeatedly:

12453 execve("/sbin/lvm", ["lvm", "vgs", "--noheadings", "-o", "pv_name", "system"], 0x555dec58c490 /* 101 vars */) = 0 12575 execve("/sbin/lvm", ["lvm", "vgs", "--noheadings", "-o", "pv_name", "system"], 0x555dec58c490 /* 101 vars */) = 0 12671 execve("/sbin/lvm", ["lvm", "vgs", "--noheadings", "-o", "pv_name", "system"], 0x555dec58c490 /* 101 vars */) = 0 ...

At a certain point, I created the bind mount as mentioned in comment 0. From that point on, dracut made progress.

12817 execve("/sbin/lvm", ["lvm", "vgs", "--noheadings", "-o", "pv_name", "system"], 0x555dec58c490 /* 101 vars */) = 0 12817 openat(AT_FDCWD, "/run/udev/data/b7:1", O_RDONLY|O_CLOEXEC) = 5 12817 openat(AT_FDCWD, "/run/udev/data/b7:29", O_RDONLY|O_CLOEXEC) = 5 ...

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1148500 http://bugzilla.opensuse.org/show_bug.cgi?id=1148500#c5 --- Comment #5 from Martin Wilck --- You can ignore all "grey" pictures. Basically you have to install using the media linked on the OpenQA page, and choose "LVM based proposal" and "Disk encryption" in the "guided setup". I don't think the rest matters much. I used "minimal X" installation type, as the OpenQA test did. Anyway, perhaps you want to focus on the results I already obtained. Are these checks for /run/udev/data files ("openat(AT_FDCWD, "/run/udev/data/b7:1", O_RDONLY|O_CLOEXEC)") introduced by the new code base and/or the added patches? If not, I'd focus on the question why /run is not bind-mounted into the chroot. I believe it should be, whether or not encryption and/or LVM is being used. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1148500 http://bugzilla.opensuse.org/show_bug.cgi?id=1148500#c6 --- Comment #6 from Gang He --- Hello All, commit a188b1e513ed5ca0f5f3702c823490f5610d4495 Author: David Teigland Date: Fri Nov 30 16:32:32 2018 -0600 pvscan lvmetad: use udev info to improve md component detection When no md devs are started, pvscan will only scan the start of an md component, and if it has a superblock at the end may not exclude it. udev may already have info identifying it as an md component, so use that. This patch looks related to udev related hang, although I feel the patch is useful to the bsc#1145231. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1148500 http://bugzilla.opensuse.org/show_bug.cgi?id=1148500#c9 --- Comment #9 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? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1148500 http://bugzilla.opensuse.org/show_bug.cgi?id=1148500#c11 Martin Wilck changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsrain@suse.com Flags| |needinfo?(jsrain@suse.com) --- Comment #11 from Martin Wilck --- @Jiri, can someone from your team please look at this? We need /run mounted in the /mnt chroot during installation. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1148500 Gang He changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |heming.zhao@suse.com -- You are receiving this mail because: You are on the CC list for the bug.