action #153105
closedtest fails in boot_windows: password expired
100%
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
Updated by dimstar 4 months ago
https://openqa.opensuse.org/tests/3847233#step/boot_windows/5
That test is windows 11 based though - and also has an expired password :(
Updated by openqa_review 3 months ago
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.
Updated by pherranz 3 months ago
- 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.
Updated by pherranz 3 months ago
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
Updated by dimstar about 2 months ago
- Status changed from Resolved to In Progress
Issue just re-appeared:
https://openqa.opensuse.org/tests/4013266#step/boot_windows/6
Updated by ph03nix about 2 months ago
@pherranz can we not just re-create the Windows HDDs in the meantime?
Updated by pherranz about 2 months ago
- % 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.
Updated by pherranz about 2 months ago
I've added some fallback code to ensure this does not happen again:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18948
Updated by pherranz about 1 month ago
- Status changed from In Progress to Resolved
- % Done changed from 50 to 100