QA (public) » openQA Project (public) » openQA Tests (public)

hm, we just changed the kernel boot parameters for virtio with #51614 , maybe it is about time to change the default graphics adapter away from cirrus? Shouldn't be hard to test using the test parameter QEMUVGA. I do not have enough experience which vga adapter would be a better choice as a sane default – or is it virtio itself? Not sure about that.

Also see #43778#note-12

Maybe I can explore the options:

openqa_clone_job_o3 --skip-chained-deps 963993 _GROUP=0 TEST=okurz_poo53339_std QEMUVGA=std BUILD=okurz_poo53339
openqa_clone_job_o3 --skip-chained-deps 963993 _GROUP=0 TEST=okurz_poo53339_cirrus QEMUVGA=cirrus BUILD=okurz_poo53339
openqa_clone_job_o3 --skip-chained-deps 963993 _GROUP=0 TEST=okurz_poo53339_qxl QEMUVGA=qxl BUILD=okurz_poo53339
openqa_clone_job_o3 --skip-chained-deps 963993 _GROUP=0 TEST=okurz_poo53339_virtio QEMUVGA=virtio BUILD=okurz_poo53339
openqa_clone_job_o3 --skip-chained-deps 964045 _GROUP=0 TEST=okurz_poo53339_std QEMUVGA=std BUILD=okurz_poo53339
openqa_clone_job_o3 --skip-chained-deps 964045 _GROUP=0 TEST=okurz_poo53339_cirrus QEMUVGA=cirrus BUILD=okurz_poo53339
openqa_clone_job_o3 --skip-chained-deps 964045 _GROUP=0 TEST=okurz_poo53339_qxl QEMUVGA=qxl BUILD=okurz_poo53339
openqa_clone_job_o3 --skip-chained-deps 964045 _GROUP=0 TEST=okurz_poo53339_virtio QEMUVGA=virtio BUILD=okurz_poo53339

Created job #964242: opensuse-Tumbleweed-DVD-x86_64-Build20190619-kde@64bit -> https://openqa.opensuse.org/t964242 ok (std) 1:45h
Created job #964243: opensuse-Tumbleweed-DVD-x86_64-Build20190619-kde@64bit -> https://openqa.opensuse.org/t964243 failed to switch consoles (cirrus), retriggered -> https://openqa.opensuse.org/tests/964569
Created job #964244: opensuse-Tumbleweed-DVD-x86_64-Build20190619-kde@64bit -> https://openqa.opensuse.org/t964244 ok (qxl) 1:45h
Created job #964245: opensuse-Tumbleweed-DVD-x86_64-Build20190619-kde@64bit -> https://openqa.opensuse.org/t964245 failed in https://openqa.opensuse.org/tests/964245#step/user_gui_login/8 (virtio), retriggered -> https://openqa.opensuse.org/tests/964570
Created job #964246: opensuse-Tumbleweed-DVD-x86_64-Build20190619-toolkits@64bit -> https://openqa.opensuse.org/t964246 failed to switch consoles (std), retriggered -> https://openqa.opensuse.org/tests/964571
Created job #964247: opensuse-Tumbleweed-DVD-x86_64-Build20190619-toolkits@64bit -> https://openqa.opensuse.org/t964247 failed in swing as expected (cirrus) 0:24h
Created job #964248: opensuse-Tumbleweed-DVD-x86_64-Build20190619-toolkits@64bit -> https://openqa.opensuse.org/t964248 failed to switch consoles (qxl), retriggered -> https://openqa.opensuse.org/tests/964572
Created job #964249: opensuse-Tumbleweed-DVD-x86_64-Build20190619-toolkits@64bit -> https://openqa.opensuse.org/t964249 failed to switch consoles (virtio), retriggered -> https://openqa.opensuse.org/tests/964573

EDIT: The result is horribly unstable and confusing though, updated above

Also scheduled one more, trying out if I can override the video= parameter to check out 32bpp:

openqa_clone_job_o3 --skip-chained-deps 964045 _GROUP=0 TEST=okurz_poo53339_boot32bpp_qxl QEMUVGA=qxl BUILD=okurz_poo53339 EXTRABOOTPARAMS_BOOT_LOCAL=video=1024x768

Created job #964574: opensuse-Tumbleweed-DVD-x86_64-Build20190619-toolkits@64bit -> https://openqa.opensuse.org/t964574

So I will propose to switch the default QEMUVGA to "std", or actually just trust qemu's default and not overwrite it in os-autoinst, "std" in this case still. I will also add specific test cases within "openSUSE Tumbleweed" for "cirrus" and "qxl" as we already have "virtio" and "std" would be the new default for "64bit". DimStar gave his ok for adding the new variants. Added two machine variants "cirrus" and "qxl" to machines on o3, and four scenarios "gnome@64bit_cirrus", "gnome@64bit_qxl", "kde@64bit_cirrus", "gnome@64bit_qxl" to Development: openSUSE Tumbleweed.

https://github.com/os-autoinst/os-autoinst/pull/1169 for the proposal to revert to the qemu defaults.

However, we can still do some upfront testing so I scheduled some more tests for Tumbleweed tests on the special, specific machine "64bit_std" which explicitly sets the "std" graphics adapter. Scheduled many scenarios in Development Tumbleweed.

test results:

• create_hdd_gnome ok
• create_hdd_textmode ok
• desktopapps-gnome ok (as unstable as "64bit" variant)
• extra_tests_on_gnome ok (unstable in gnucash and exiv2 but no failures in steam, so good)
• extra_tests_in_textmode ok (fails in dstat, sssd, libgpiod, same as "64bit" variant)
• kde ok
• minimalx ok
• qemu ok
• textmode ok
• update_13.1-gnome ok
• virtualization ok
• yast2_gui ok (fails in yast2_firewall on boo#1114673 as cirrus)
• yast2_ncurses ok (fails same as cirrus)
• kde-live_installation ok
• zdup-Leap-42.3-kde needs asset, @waitfor new builds fails reproducibly to switch ttys in https://openqa.opensuse.org/tests/972173#step/setup_zdup/4, also in the post_fail_hook. I wonder if this is because of the X server actually running on a different tty? I doubt that because the post_fail_hook should try tty5 which should really be free. The serial port output showed the scheduler in kernel to be a "blocked task". Trying with openqa-clone-job --skip-chained-deps --within-instance https://openqa.opensuse.org 972173 TEST=zdup-Leap-42.3-kde_4G_timeout_scale_3 QEMURAM=4096 TIMEOUT_SCALE=3 to give the machine more head-room: Created job #972175: opensuse-Tumbleweed-DVD-x86_64-Build20190630-zdup-Leap-42.3-kde@64bit_std -> https://openqa.opensuse.org/t972175 , in interactive mode I connected, GUI was not reactive, over VNC at least the machine reacted on "ctrl-alt-del" and rebooted, retriggered as https://openqa.opensuse.org/tests/972176
• gnome-live quite unstable, compare to "update_Leap_15.1_gnome"
• extra_tests_in_kde missing asset of generation job, added to schedule
• extra_tests_in_xfce same as kde variant
• gnome fails reproducibly in "xorg_vt" showing "Xwayland" instead of plain "X"
  • -> need to foresee this in tests, seems like "std" causes the system to automatically select wayland instead of X, asked "DimStar" in IRC, answer: We should accept that wayland is detected as default and rely on that. That has an impact on "create_hdd_gnome-wayland" and downstream jobs
  • first created https://github.com/os-autoinst/os-autoinst-needles-opensuse/pull/565 and https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/7769 to generalize xorg_vt
  • I hardcoded "QEMUVGA=cirrus" on the x86_64 machines which are not "bare-metal" and only when QEMUVGA is not set already, see https://openqa.suse.de/admin/machines . I did the same on https://openqa.opensuse.org/admin/machines to be on the safe side for now (https://openqa.opensuse.org/tests/966421#step/xorg_vt/3 shows that the explicit "cirrus" is fine as well whereas https://openqa.opensuse.org/tests/966446#step/xorg_vt/4 shows that "qxl" fails the same for now as "std" as "wayland" was not expected there)
• toolkit fails showing a correct image but apparently no needle matches this, need to compare with cirrus case -> created https://bugzilla.opensuse.org/show_bug.cgi?id=1139927 and an according workaround needle "tk-ui-toolkit-tk-boo1139927-no_text_string_shown-20190701", retriggered as https://openqa.opensuse.org/tests/972161 -> ok
• update_Leap_15.1_gnome very unstable, xorg_vt (as above) but also oomath, ooffice, firefox, needs further investigation! -> xorg_vt solved with https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/7769 and new needle
• update_Leap_42.3_kde incomplete, needs base image, created, retriggered -> https://openqa.opensuse.org/tests/972172 ok

• DONE: @waitfor gh#os-autoinst/os-autoinst-distri-opensuse#7769 , then
  • DONE: Add gnome@64bit_cirrus for Tumbleweed
  • DONE: Add kde@64bit_cirrus for Tumbleweed

Also I added "gnome@64bit_std" and "kde@64bit_std" to be explicit however I plan to remove these soon again after we actually switched the 64bit machines to "std" instead.

Asked DimStar which TW snapshot would be good to test against std and we agreed that 20190702 should be good. I removed QEMUVGA=cirrus from all machine definitions on o3 except "64bit_cirrus".

I installed the new version of os-autoinst on openqaworker1, rebooted and will check how jobs run there as well.

default graphics adapter in os-autoinst has been changed to "std", the QEMUVGA=cirrus machine variant on o3 has already been removed, special tickets have been created for followup on o3 and osd.

This fail seems to happen in https://openqa.suse.de/tests/3408495 due to cirrus.

Should we switch SLE15SP2 to std?

Yes, you should. That is #55445

Not resolved by U-Team