QA » openQA Project » openQA Tests

Could you please check if it has broken: https://openqa.suse.de/tests/2279361#step/partitioning_raid/11
Would be weird, but seems that change exposed some issue we have had in our code.

Same here: https://openqa.suse.de/tests/2279329

I have updated the code over here. https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/partition_setup.pm#L250
AFAIK raid tests are not using fully partition_setup https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/installation/partitioning_raid.pm#L19

There is a change in the buttons field again Add Pa(r)tition vs separated buttons. Can I fix it as part of this ticket ?

Another change in the overview vs overview with buttons

mloviska wrote:

Can I fix it as part of this ticket ?

From my point of view: Sure, you never need to ask for allowance and using the same ticket instead of creating a new one with additional "buerocrazy" should be preferred as long as we can ensure we are not getting lost and don't follow the plan. The idea of this ticket was to make sure the test scenario passes again or shows obvious product issues so in the case you mentioned I think it's part of the ticket.

okurz wrote:

mloviska wrote:

Can I fix it as part of this ticket ?

From my point of view: Sure, you never need to ask for allowance and using the same ticket instead of creating a new one with additional "buerocrazy" should be preferred as long as we can ensure we are not getting lost and don't follow the plan. The idea of this ticket was to make sure the test scenario passes again or shows obvious product issues so in the case you mentioned I think it's part of the ticket.

Thanks for clarification. I was not sure whether there is a separate ticket or not ( I could not find any ). Alright I will update the partitioner_raid along with partition_setup library

There is also a difference between archs especially ARM vs Intel and ppc. At this moment we have to wait if this issue hits s390x as well. Otherwise it looks like a regression on ARM.

arm vs intel

<mloviska> Are the warnings regarding obsolete  yast2-storage-ng from OBS normal ? http://pastebin.suse.de/23564  https://build.suse.de/public/build/SUSE:SLE-15-SP1:GA/standard/aarch64/yast2-storage-ng/_log
<snwint> mloviska: installation-images hasn't been built for ages due to the mentioned dependency problem
<HuHa> mloviska: that ISO is ancient and not fit for any testing
<snwint> mloviska: I would say the aarch64 tree is not in a good shape at the moment....
<HuHa> mloviska: the project manager has to take care to get this arch built properly
<HuHa> right now it's pointless to test that ISO
<HuHa> you'll just rediscover that all the storage stack is incomplete - just like it was in mid-April

So we have a build problem on aarch64

I see. It is good that you have found this out. At best we have an internal issue to describe this problem which we can "block" this ticket by. If you are not aware of any I recommend you create a bug on bugzilla, mention it here and set this ticket to "Blocked" to not loose time. Then we can use this bug to label the according test failures as well or just keep this "Blocked" ticket as reference.

Sure, I will open the bug. Thanks!

<snwint> mloviska: Rudi tracked it down to Qt build failing...

https://build.suse.de/package/show/SUSE:SLE-15-SP1:GA/libqt5-qtsvg

[   60s] In file included from /usr/include/GLES3/gl31.h:39:0,
[   60s]                  from /usr/include/qt5/QtGui/qopengl.h:105,
[   60s]                  from /usr/include/qt5/QtWidgets/5.9.7/QtWidgets/private/qwidget_p.h:62,
[   60s]                  from qsvgwidget.cpp:48:
[   60s] /usr/include/GLES3/gl3platform.h:28:10: fatal error: KHR/khrplatform.h: No such file or directory
[   60s]  #include <KHR/khrplatform.h>
[   60s]           ^~~~~~~~~~~~~~~~~~~
[   60s] compilation terminated.
[   60s] make[2]: *** [Makefile:566: .obj/qsvgwidget.o] Error 1
[   60s] make[2]: *** Waiting for unfinished jobs....
[   67s] make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/qtsvg-opensource-src-5.9.7/src/svg'
[   67s] make[1]: *** [Makefile:46: sub-svg-make_first-ordered] Error 2
[   67s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/qtsvg-opensource-src-5.9.7/src'
[   67s] make: *** [Makefile:47: sub-src-make_first] Error 2
[   67s] error: Bad exit status from /var/tmp/rpm-tmp.Wd5IVG (%build)
[   67s] 
[   67s] 
[   67s] RPM build errors:
[   67s]     Bad exit status from /var/tmp/rpm-tmp.Wd5IVG (%build)
[   67s] 
[   67s] centriq5 failed "build libqt5-qtsvg.spec" at Sat Nov 24 10:47:55 UTC 2018.

Nice investigation. I believe there is nothing to be done on our side in the end, so let's see if we get this fixed soon. Thanks again!

riafarov wrote:

Nice investigation. I believe there is nothing to be done on our side in the end, so let's see if we get this fixed soon. Thanks again!

Agreed, at most we can contact PMs/RMs to let them know about the dependency issue in OBS.

With the bug report they should be aware, right?

local run, without any code changes
http://eris.suse.cz/tests/9616#step/partitioning_full_lvm/1

I am wondering how many times the test had to press "right" key to roll down VGs.

[2019-02-11T16:23:32.049 UTC] [debug] <<< testapi::send_key(key='alt-s', do_wait=0)
[2019-02-11T16:23:32.257 UTC] [debug] /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/installation/partitioning_full_lvm.pm:28 called partition_setup::addlv
[2019-02-11T16:23:32.258 UTC] [debug] <<< testapi::send_key(key='home', do_wait=0)
[2019-02-11T16:23:32.466 UTC] [debug] /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/installation/partitioning_full_lvm.pm:28 called partition_setup::addlv
[2019-02-11T16:23:32.467 UTC] [debug] <<< testapi::check_screen(mustmatch='volume_management_feature', timeout=1)

Actions to be performed:

1. Activate System View
2. Go to the top entry -> "linux"
3. Roll down until Volume Management is reached

What happened:

1. SUT exited from VG configuration, therefore Volume Management was active in System View
2. System View was activated
3. SUT pressed "home" but YaST2/SUT did not responded in expected time
4. SUT matched needle from point 3. in the previous list

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: lvm-encrypt-separate-boot
https://openqa.suse.de/tests/2798098