action #42632
closed
[functional][y][fast] test fails in bootloader_uefi - it doesn't get into GRUB - SUT already running while checking data integrity
Added by zluo over 5 years ago.
Updated over 5 years ago.
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 20
Description
Compare with last successful test run, we have now problem with bootloader. I can see that installer tries to coming up however, but it didn't make it to get into GRUB.
Stall was detected during assert_screen fail and # wait_serial expected: 'SysRq : Show Blocked State' found
Observation¶
openQA test in scenario sle-12-SP4-Server-DVD-aarch64-RAID0@aarch64 fails in
bootloader_uefi
Reproducible¶
Fails since (at least) Build 0426 (current job)
Expected result¶
Last good: 0421 (or more recent)
Further details¶
Always latest result in this scenario: latest
- Priority changed from Normal to Urgent
- Assignee set to JERiveraMoya
This is related to the new data_integrity test that steals us ~1 minute while the SUT is already running while we are calculating the ISO checksum.
This makes the bootloader timeout. See also the timestamps at the log and the video.
This also happens on x86_64: https://openqa.suse.de/tests/2178161#step/bootloader/37
- Assignee changed from JERiveraMoya to szarate
That explains a lot more (why it didn't happen before)... Anyway, I think that calling freeze_vm within that data_integrity module, should do the trick and simply resume_vm after it has finished, but before that changes need to be done at os-autoinst level to support this, as freeze_vm is meant to be called from the post_fail_hook level...
- Subject changed from test fails in bootloader_uefi - it doesn't get into GRUB to [functional][y][fast] test fails in bootloader_uefi - it doesn't get into GRUB - SUT already running while checking data integrity
- Due date set to 2018-10-23
- Target version set to Milestone 20
And when we are talking about changes to the backend I would go for making sure – what I expected – but of course: We should only trigger isosize and the data integrity module before starting the actual SUT.
I suggest @JERiveraMoya to take this ticket as he introduced the data integrity check. For a start we could remove the test module from the schedule again and then – less urgent – work on making sure that we can trigger some test/check steps before the SUT is started.
@okurz I can submit the pr to enable freeze_vm to be called at any point. However if the test have DELAYED_START=1 then the qemu backend will simply not start the cpu (or rather it will be paused), making a call to resume_vm() to be required after the integrity check is done...
- Related to action #41414: [functional][y][tools] Checksum of the images is verified on the worker side added
- Status changed from New to Feedback
@szarate vm freeze will not help the bare metal tests which can be affected the same I guess
What we could do is to just schedule the test module in a specific testsuite which only checks the asset integrity. It will help to show if the medium is fine on the openqa instance itself and at least within the cache of one worker
OK, so gonna go freeze_vm -> check integrity -> resume_vm, for qemu backends. Gonna use poo#41414 to define better what to do, since this could be done in the cache service (https://github.com/os-autoinst/openQA/pull/1783) and is an operation that can be executed before the tests are even initialized.
- Status changed from Feedback to In Progress
- Status changed from In Progress to Feedback
- Priority changed from Urgent to Normal
- Status changed from Feedback to Resolved
I call ticket resolved by riafarov on #note-10. Check poo#41414 for more details
Also available in: Atom
PDF