Hello Guys,

Could you help to review this request? if there is not any problem, please accept it.

Thanks a lot. Gang

This submission DOES cause problems though - when installing the test system on cryptlvm, then the installation stalls, with this command:

_ lvm vgs --noheadings -o pv_name system

(called by dracut)

Causes openQA failures

Dominique Leuenberger (dimstar) - over 4 years ago

reviewer

https://openqa.opensuse.org/tests/1018187#

Gang He (ganghe) - over 4 years ago

author source maintainer

Hello dimstar,

I think the patches should OK, but why did the rpm encounter this problem? Could you open a bug? since these patches have to be added.

Thanks Gang

---

Dominique Leuenberger (dimstar) - over 4 years ago

reviewer

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

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.

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.

Erronously selected - installer bug not yet addressed

I don't know how much we're in a hurry here, but I'd vote for having this linger in Base:System for a while, and inform users about the pending update on the factory mailing list, encouraging them to test the package. I know Heming Zhao did a good job and made a lot of tests, but it is a major update with serious potential to break stuff.

Gang He (ganghe) - over 4 years ago

author source maintainer

Hello Martin,

I agree, we will fix this problem, and then, keep the source code in Base:System for a while. By the way, how can we let more people know this big change and involve them to attend the testing?

Thanks Gang

---

Martin Wilck (mwilck) - over 4 years ago

source maintainer

I suggest an email to the openSUSE-factory mailing list. Possibly "research", too, to increase SUSE-internal awareness.