Request 725506 (superseded)

Why do you need a bug from me? This broken package is not in any product - you are submitting something which we encounter as causing a problem before it integrates. With this knowledge, the task is back on the engineering dept to identify the reason and to fix it.

Gang He (ganghe) - over 4 years ago

author source maintainer

Hi Dimstar,

Since we do not know about the details about this failure. Could you provide more details about this test failure? if possible, please give some steps to reproduce this failure.

Thanks Gang

Dominique Leuenberger (dimstar) - over 4 years ago

reviewer

The openQA system is fully reproducible - all steps are clearly followed by a recipe (openQA can even be installed on your own system to reproduce)

The failed test was https://openqa.opensuse.org/tests/1018187#

The special bits for this test is the 'sequence in https://openqa.opensuse.org/tests/1018187#step/encrypt_lvm/1 - so preparing and installing the system on an encyrpted LVM partition.

Martin Wilck (mwilck) - over 4 years ago

source maintainer

Well, installing OpenQA is not an everyday routine task, even for engineering :-)

Anyway, it seems that "lvm vgs", called from dracut while creating the initrd, is not making progress (https://openqa.opensuse.org/tests/1018187/file/await_install-ps_auxf). Unfortunately the sysrq "show blocked tasks" output is garbled on the console.

@ganghe, I suggest you try installing manually on encrypted LVM, using the ISO image from https://openqa.opensuse.org/tests/1018187#downloads, and try to reproduce the problem.

Gang He (ganghe) - over 4 years ago

author source maintainer

Hi mwilck,

Thank for your information. It looks there is a incompatibility problem in v2.02.183. I will try to reproduce this bug.

Thanks Gang

Martin Wilck (mwilck) - over 4 years ago

source maintainer

I have reproduced this locally. See boo#1148500 for details. Although "vgs" is hanging, I am not convinced that the problem is caused by the LVM2 update.

Dominique Leuenberger (dimstar) - over 4 years ago

reviewer

After removing this submission from Staging:G and getting a new media built, the tests passed. That feels conclusive

Martin Wilck (mwilck) - over 4 years ago

source maintainer

Well, the reason for the failure was that /run wasn't bind-mounted into the chroot for the installed system. That's not LVM's fault. It's just that the LVM tools check for this, and fail. We are trying to figure out in what respect the behavior of LVM2 changed.

Jan Engelhardt (jengelh) - over 4 years ago

reviewer

at this point, I'd be more interested in the "why" rather than the "what" (that's known now: checking /run in some fashion) ;-)

Martin Wilck (mwilck) - over 4 years ago

source maintainer

I believe that this bind mount should be present during installation.

But let's continue the discussion about "what" and "why" on the bug.

Martin Wilck (mwilck) - over 4 years ago

source maintainer

Update: upstream patches were added to LVM2 that make lvm2 call libudev to figure out certain device properties. It's these calls that hang waiting udev information to become available under /run/udev. We need these patches to fix other bugs.

So again, /run must be available in the chroot. I am wondering how initrd creation ever worked without that, and I believe that LVM2 was just a casual victim. Passed on to the installer team for now.

Dominique Leuenberger (dimstar_suse) - over 4 years ago

reviewer target maintainer

Erronously selected - installer bug not yet addressed