action #131366
closed
[opensuse] test fails in hostname on `@cpu_max` machine
Added by ggardet_arm over 1 year ago.
Updated about 1 year ago.
Category:
Bugs in existing tests
Description
Observation¶
openQA test in scenario opensuse-Tumbleweed-JeOS-for-AArch64-aarch64-jeos@aarch64_cpu_max-HD20G fails in
hostname
Test suite description¶
Maintainer: fvogt, mnowak
Start JeOS from the HDD image, configure it using the firstboot wizard and then run basic tests. console=tty0 added as needed for aarch64.
Test fails in hostname on @cpu_max machine. This machine is an aarch64 qemu machine without KVM to enable new CPU features not available on openQA workers yet.
So, this is a slow qemu machine and the 10 seconds timeout is way too short.
Reproducible¶
Fails since (at least) Build 20230602
Expected result¶
Last good: 20230531 (or more recent)
Further details¶
Always latest result in this scenario: latest
@favogt could you have a look please?
The timeout is set by nmcli itself. It can be increased by adding the -w flag AFAICT. However this operation usually takes less than a second, here it appears to be 10-100x slower at least. Meanwhile the overall test usually only takes about 3x longer than the KVM version.
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: jeos@
https://openqa.opensuse.org/tests/3414793#step/journal_check/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
- Assignee deleted (
favogt)
It appears like the command really takes that long to execute, so it's a product issue that needs a closer look.
I tried to reproduce it locally with a very similar qemu line but it worked fine and took ~2s.
favogt wrote:
It appears like the command really takes that long to execute, so it's a product issue that needs a closer look.
I tried to reproduce it locally with a very similar qemu line but it worked fine and took ~2s.
I reproduced on a local qemu with 2 network interfaces. One took few seconds while the other one timed out. Playing with -w option, I managed to get it working within ~12s.
WIP PR to increase the timeout value: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17455
- Subject changed from test fails in hostname on `@cpu_max` machine to [opensuse] test fails in hostname on `@cpu_max` machine
- Status changed from New to Resolved
PR merged and test run fine now.
Also available in: Atom
PDF