Project

General

Profile

action #62096

coordination #9576: [epic][opensuse][sle][functional][y] VNC+SSH Installations

[functional][y][opensuse][timeboxed:16h] remote intallation doesnt communicate correctly after reboot

Added by ybonatakis almost 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 31
Start date:
2020-01-13
Due date:
2020-01-28
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

Follow up for #52310 as scenario is still not enabled.

In remote installation through ssh and vnc in opensuse the remote_target doesn't close the yast2 to get into the installed desktop. The support qcow is support_server_opensuse-15.0-x86_64-GM-gnome.qcow2. I believe that there is something wrong with the image. We may need to create and test with a new one. Otherwise we need to investigate the problem.

for now there is a workaround for opensuse to do so manually pressing the "ctl-alt-delete" but this is not the expected behavior.

openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-remote_vnc_target_nfs@64bit fails in
remote_target

We need to investigate the issue and at least report the bug, which we can use as a soft-failure for the workaround.

Test suite description

remote installation with vnc. setup for target

Reproducible

Fails since (at least) Build 20191214 (current job)

Expected result

Last good: 20191214 (or more recent)

Further details

Always latest result in this scenario: latest

History

#1 Updated by riafarov almost 2 years ago

  • Description updated (diff)
  • Due date set to 2020-01-28

#2 Updated by riafarov almost 2 years ago

  • Parent task set to #9576

#3 Updated by riafarov almost 2 years ago

  • Target version set to Milestone 31

#4 Updated by riafarov almost 2 years ago

  • Subject changed from [functional][y][opensuse] remote intallation doesnt communicate correctly after reboot to [functional][y][opensuse][timeboxed:16h] remote intallation doesnt communicate correctly after reboot
  • Description updated (diff)
  • Status changed from New to Workable

#5 Updated by riafarov almost 2 years ago

  • Description updated (diff)

#6 Updated by ybonatakis almost 2 years ago

  • Assignee set to ybonatakis

#7 Updated by ybonatakis almost 2 years ago

  • Status changed from Workable to In Progress

#8 Updated by ybonatakis almost 2 years ago

  • Status changed from In Progress to Feedback

I have worked on this for more than 16h for many and different reasons. I havent come up with any solid answer yet. The reason is that i didnt manage to reproduce the manual tests in the automation manner.

What i have tried out is to build a new support server and test it in both manual and automated way. Also i tried to go through the source code in yast-installation. What i havent investigated is the reasons of the current's qcow behavior and to take a deeper look in the MM network configuration.

support_server_opensuse-15.0-x86_64-GM-gnome.qcow2 is the current qcow which using it manual to perform remote installation, is stuck in the yast instead to log in the desktop.

One of the images that i tried to use to replace the latter, it was opensuse-15.1-x86_64-GM-gnome@64bit.qcow2 which is already available in the O3. Manual: seems to work(the system opens and goes to desktop). Automation: fails in some weird way[0]. briefly, the target is not running when the controller tries to access it and it dies. Multiple tries to find why the test has this different behavior but i run from one issue to another.
Pretty much i encountered the same problems with any other image i tried(at least the one that i considered appropriate. because i tried also some that for various reasons they were not the correct one.

In the process to build a new supportserver i came across some other challenges. the command i used to build the supportserver is

 sudo /usr/share/openqa/script/client jobs post DISTRI=opensuse VERSION=15.2 ISO=openSUSE-Leap-15.0-DVD-x86_64.iso  ARCH=x86_64 FLAVOR=DVD TEST=supportserver_generator MACHINE=64bit DESKTOP=gnome  INSTALLONLY=1 AUTOYAST=supportserver/autoyast_supportserver_x86.xml SUPPORT_SERVER_GENERATOR=1 PUBLISH_HDD_1=supportserver_15_0_gnome_iob.qcow2 --host https://openqa.opensuse.org/

replacing the ISO and AUTOYAST variables with different variables. for AUTOYAST i tried to use the xml found in data directory. The only one which seems to fit for opensuse is supportserver/autoyast_supportserver_x86.xml as the others look to be made for sle. Although i tried also AY files from data/autoyast_opensuse/ and data/autoyast/.
However the results were all unsuccessful[1]

from my side i think that a new image might solve the problem but i need to learn how is the proper way to create a supportserver for opensuse (what xml works, extra variables that might needs).

Due to the timebox i am leaving this for now and set it to feedback for further discussion.

[0] http://aquarius.suse.cz/tests/1367#step/setup/42
[1] https://openqa.opensuse.org/tests/1150274#next_previous

#9 Updated by ybonatakis almost 2 years ago

  • Status changed from Feedback to Resolved

Follow up ticket has been created https://progress.opensuse.org/issues/62498. I close this

Also available in: Atom PDF