coordination #9576: [epic][opensuse][sle][functional][y] VNC+SSH Installations
[functional][y][opensuse][timeboxed:16h] remote intallation doesnt communicate correctly after reboot
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
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
Fails since (at least) Build 20191214 (current job)
Last good: 20191214 (or more recent)
Always latest result in this scenario: latest
#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
#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-GMfirstname.lastname@example.org which is already available in the O3. Manual: seems to work(the system opens and goes to desktop). Automation: fails in some weird way. 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
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.