action #18344
closed[sled][functional] test fails in remote_vnc_controller_sled boot_to_desktop
0%
Description
Observation¶
openQA test in scenario sle-12-SP3-Desktop-MINI-ISO-x86_64-remote_vnc_controller_sled@64bit fails in
boot_to_desktop
The FLAVOR of this job is Desktop-MINI-ISO but the qcow2 image which is defined in testsuit
is HDD_1=sle-12-SP1-Server-DVD-x86_64-gnome.qcow2/
Reproducible¶
Fails since (at least) Build 0170 (current job)
Expected result¶
Last good: (unknown) (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by qkzhu over 6 years ago
- Assignee set to RBrownSUSE
I saw the Audit log, this was created by Richard.
Updated by yfjiang over 6 years ago
qkzhu wrote:
I saw the Audit log, this was created by Richard.
Hi Chingkai,
As I understand, Remote installation is in Desktop's acceptance test scope, so can we look into more details :-)
Is there a PR/concrete idea how we can make it better? e.g. What's the preferred qcow2/FLAVOR here.
Thanks and please correct if I misunderstood anything.
Updated by qkzhu over 6 years ago
- Assignee changed from RBrownSUSE to qkzhu
I found that
- The FLAVOR of this job is: Desktop-MINI-ISO but
- the qcow2 image which is defined in testsuit is: HDD_1=sle-12-SP1-Server-DVD-x86_64-gnome.qcow2
I am not sure if this caused the misunderstanding of wait_boot, I will look into this issue on my openQA environment.
Updated by RBrownSUSE over 6 years ago
qkzhu wrote:
I found that
- The FLAVOR of this job is: Desktop-MINI-ISO but
- the qcow2 image which is defined in testsuit is: HDD_1=sle-12-SP1-Server-DVD-x86_64-gnome.qcow2
This is not a problem.
remote_vnc_controller_sled is the test for a multi-machine job. VNC installations need two machines, the system under test (which is what you are installing on) and the system conducting the test, running the VNC client and doing the installation.
remote_vnc_controller_sled is the system conducting the test, for which we use SLE-12-SP1-Server because it's what we use for doing the test on SLES and the whole point of this test appearing quickly was because we were given the responsibility to look into SLED Beta 1 at very short notice and it was quicker to automate it in openQA than teach someone how to do VNC installations
I'll look into the issue with the test run, as I created it and this initial hiccup is probably something I can fix, but I would appreciate it if someone with more SLED expertise helps as I suspect we'll need it next :)
I am not sure if this caused the misunderstanding of wait_boot, I will look into this issue on my openQA environment.
Updated by RBrownSUSE over 6 years ago
Fixed it with a fresh needle - sorry I couldn't get the needle done before I left last night but was a long day with this and everything else we had to look at for Beta 1
Test is now running, should give good results regarding VNC installations for Beta 1 and in the future
Regards
PS. I also added an LVM test to the SLED job groups, as this is also in scope of validation testing and was easy to add to openQA
Updated by yfjiang over 6 years ago
Some thing maybe irrelevant - from the video, the grub2 was there and gdm was booted. So it gave me a feeling openQA didn't catch the grub screenshot in time?
Updated by yfjiang over 6 years ago
RBrownSUSE wrote:
Fixed it with a fresh needle - sorry I couldn't get the needle done before I left last night but was a long day with this and everything else we had to look at for Beta 1
Test is now running, should give good results regarding VNC installations for Beta 1 and in the future
Regards
PS. I also added an LVM test to the SLED job groups, as this is also in scope of validation testing and was easy to add to openQA
Gee... brilliant, thank you Richard! :-)
Updated by qkzhu over 6 years ago
- Status changed from Feedback to Resolved
- Assignee changed from qkzhu to RBrownSUSE
fixed at: https://openqa.suse.de/tests/overview?distri=sle&version=12-SP3&build=0170&groupid=61
Thank you for taking care of it Richard.