Added by emiura 5 months ago. Updated 5 months ago.
Description
In the following test:
https://openqa.suse.de/tests/13004656
(this issue is only seen in nvdimm (baremetal) tests)
mr_test install saptune/sapconf, then calls for a reboot. After the reboot, it fails to match the pxe screen (it is not present on the screenshots).
However, checking the video recorder, the pxe prompt can be seen for almost 30s until it timeouts and boots to the SUT.
Hi emiura, I suggest to always use the "Report test issue" button on openQA to provide more details in tickets. Can you update the ticket description accordingly?
In autoinst-log.txt I found references to errors and warnings that I suggest you fix first, e.g.
[2023-12-08T16:46:26.821448Z] [debug] [pid:1352] tests/sles4sap/saptune/mr_test.pm:106 called mr_test::setup -> tests/sles4sap/saptune/mr_test.pm:87 called mr_test::reboot_wait -> tests/sles4sap/saptune/mr_test.pm:35 called sles4sap::reboot -> lib/sles4sap.pm:810 called ipmi_backend_utils::switch_from_ssh_to_sol_console -> lib/ipmi_backend_utils.pm:36 called power_action_utils::prepare_system_shutdown -> lib/power_action_utils.pm:52 called backend::console_proxy::__ANON__
[2023-12-08T16:46:26.821582Z] [debug] [pid:1352] <<< backend::console_proxy::__ANON__(wrapped_call={
"console" => "root-ssh",
"function" => "kill_ssh",
"args" => [],
"wantarray" => undef
})
Use of uninitialized value $opts{"reset_console_flag"} in string eq at sle/lib/ipmi_backend_utils.pm line 41.
ipmi_backend_utils::switch_from_ssh_to_sol_console() called at sle/lib/sles4sap.pm line 810
sles4sap::reboot(mr_test=HASH(0x55c114d512a0)) called at sle/tests/sles4sap/saptune/mr_test.pm line 35
mr_test::reboot_wait(mr_test=HASH(0x55c114d512a0)) called at sle/tests/sles4sap/saptune/mr_test.pm line 87
mr_test::setup(mr_test=HASH(0x55c114d512a0)) called at sle/tests/sles4sap/saptune/mr_test.pm line 106
mr_test::run(mr_test=HASH(0x55c114d512a0)) called at /usr/lib/os-autoinst/basetest.pm line 352
…
sles4sap::reboot -> lib/sles4sap.pm:812 called opensusebasetest::wait_boot -> lib/opensusebasetest.pm:888 called testapi::assert_screen
[2023-12-08T16:47:09.808411Z] [debug] [pid:1352] <<< testapi::assert_screen(mustmatch=[
"virttest-pxe-menu",
"qa-net-selection",
"prague-pxe-menu",
"pxe-menu"
], timeout=600)
[2023-12-08T16:47:09.944519Z] [debug] [pid:1353] no match: 1799.9s, best candidate: boot_from_pxe-20190110 (0.00)
[2023-12-08T16:47:10.813753Z] [debug] [pid:1353] no change: 1798.9s
[2023-12-08T16:47:10.861707Z] [debug] [pid:1353] no match: 1798.9s, best candidate: boot_from_pxe-20190110 (0.00)
[2023-12-08T16:47:11.870367Z] [debug] [pid:1353] no match: 1797.9s, best candidate: boot_from_pxe-20190110 (0.00)
[2023-12-08T16:47:12.868009Z] [debug] [pid:1353] no match: 1796.9s, best candidate: boot_from_pxe-20190110 (0.00)
[2023-12-08T16:47:14.507264Z] [warn] [pid:1353] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.69 seconds for 11 candidate needles - make your needles more specific
those might be related to the problem you observe.
About the failures:
This screen is the last one before reboot:
https://openqa.suse.de/tests/13004656#step/mr_test/41
Until https://openqa.suse.de/tests/13004656#step/mr_test/57 you can only see the baremetal machine pxe boot steps. Then in https://openqa.suse.de/tests/13004656#step/mr_test/58 the system already booted past grub.
The code is trying to match a pxe bootscreen from qam networks, but it is not "visible" there (but they are present on the video recording)
Also, how do I prevent that test to be erased automatically?
emiura wrote in #note-3:
Also, how do I prevent that test to be erased automatically?
An "important" job is kept for longer, based on job group settings. That has already happened here because you referenced the job URL in the ticket here and I followed that link so that openQA automatically added a backlink. See
http://open.qa/docs/#_referer_settings_to_auto_mark_important_jobs
for details.