action #153105
closed
test fails in boot_windows: password expired
Added by dimstar 5 months ago.
Updated about 2 months ago.
Description
Observation¶
This ticket is very similar to https://progress.opensuse.org/issues/151624;
Except: last time it was the Windows 11 disk, this time it's the Windows 10 disk.
openQA test in scenario opensuse-Tumbleweed-WSL-x86_64-wsl-main@win10_uefi fails in
boot_windows
Test suite description¶
Basic WSL test Test scope:
1) Prepare WSL and other features in Windows
2) Download the image
3) Import embedded certificate from the image
4) Load image
5) Define users
6) Register SUT
7) Exit WSL
Reproducible¶
Fails since (at least) Build 20240103 (current job)
Expected result¶
Last good: 20231228 (or more recent)
Further details¶
Always latest result in this scenario: latest
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: wsl-main@win11_uefi
https://openqa.opensuse.org/tests/3948416#step/boot_windows/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.
- Project changed from openQA Tests to 199
- Category deleted (
Bugs in existing tests)
- Status changed from New to Workable
- Priority changed from Normal to High
- Project changed from 199 to openQA Tests
- Status changed from Workable to In Progress
Seems that the fix @etchubykalo and me applied to the registry to prevent password expiring is not working.
I'll look for another solution to this.
The failure is not happening in OSD images, neither in the BIOS one. I've checked that the UEFI images in the O3 server are older than the other ones so maybe the fix did not apply propperly.
I'll re-copy the UEFI images from OSD to O3 again.
In OSD:
openqa:~/factory/hdd/fixed> ls -lah .. | grep 22H2
-rw-r--r-- 1 geekotest nogroup 11G Feb 2 13:18 windows-10-x86_64-22H2@windows_bios_boot.qcow2
-rw-r--r-- 1 geekotest nogroup 11G Feb 1 16:46 windows-10-x86_64-22H2@windows_uefi_boot.qcow2
-rw-r--r-- 1 geekotest nogroup 330K Feb 1 16:38 windows-10-x86_64-22H2@windows_uefi_boot-uefi-vars.qcow2
-rw-r--r-- 1 geekotest nogroup 14G Feb 2 13:22 windows-11-x86_64-22H2@windows_uefi_boot.qcow2
-rw-r--r-- 1 geekotest nogroup 330K Feb 2 13:11 windows-11-x86_64-22H2@windows_uefi_boot-uefi-vars.qcow2
In O3:
new-ariel:~/factory/hdd/fixed> ls -lah | grep 22H2
-rw-r--r-- 1 geekotest nogroup 11G Feb 5 14:40 windows-10-x86_64-22H2@windows_bios_boot.qcow2
-rw-r--r-- 1 geekotest nogroup 12G Jan 12 10:16 windows-10-x86_64-22H2@windows_uefi_boot.qcow2
-rw-r--r-- 1 geekotest nogroup 330K Jan 12 09:29 windows-10-x86_64-22H2@windows_uefi_boot-uefi-vars.qcow2
-rw-r--r-- 1 geekotest nogroup 12G Jan 12 11:20 windows-11-x86_64-22H2@windows_uefi_boot.qcow2
-rw-r--r-- 1 geekotest nogroup 330K Jan 12 10:16 windows-11-x86_64-22H2@windows_uefi_boot-uefi-vars.qcow2
qcow2 images re-copied and tests running
- Status changed from In Progress to Resolved
- Status changed from Resolved to In Progress
@pherranz can we not just re-create the Windows HDDs in the meantime?
Yes, sure. Let me start with it.
- % Done changed from 0 to 50
Images re-generated in OSD. The three WSL builds have been re-run.
I'm moving the new images to O3 right now.
- Status changed from In Progress to Resolved
- % Done changed from 50 to 100
Also available in: Atom
PDF