action #109710
open[virtualization][hyperv] Failed to calculate checksum for ISO located in: D:\cache\SLE-15-SP4-Full-x86_64-Build119.1-Media1.iso
0%
Description
Observation¶
We can see this in the logs:
[2022-04-01T02:29:16.662864+02:00] [debug] [run_ssh_cmd(sha256sum D:\cache\SLE-15-SP4-Full-x86_64-Build119.1-Media1.iso)] stderr:
sha256sum: D:\cache\SLE-15-SP4-Full-x86_64-Build119.1-Media1.iso: Permission denied
[2022-04-01T02:29:16.664586+02:00] [debug] [run_ssh_cmd(sha256sum D:\cache\SLE-15-SP4-Full-x86_64-Build119.1-Media1.iso)] exit-code: 1
substr outside of string at sle/lib/data_integrity_utils.pm line 44.
openQA test in scenario sle-15-SP4-Full-x86_64-select_modules_and_patterns+registration@svirt-hyperv fails in
bootloader_start
Test suite description¶
Full Medium installation that covers the following cases:
1. Additional modules enabled using SCC (Legacy, Development Tools,
Web and Scripting, Containers, Desktop Applications);
2. Yast patterns installed;
3. System registration is skipped during installation;
4. Installation is validated by successful boot and that YaST does not
report any issues;
5. Registration is performed on the installed system.
Reproducible¶
Fails since (at least) Build 79.1
Expected result¶
Last good: (unknown) (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by openqa_review almost 2 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: select_modules_and_patterns+registration@svirt-hyperv-uefi
https://openqa.suse.de/tests/8670315#step/bootloader_start/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
Updated by xlai over 1 year ago
- Status changed from New to Workable
I ever met once such failure in virtualization's own test. Although this failure happens in tests not owned by VT, but root cause is in hyperv automation. So move it to our squad's backlog.
Updated by slo-gin about 1 month ago
This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.