action #97325
closedCollect logs in autoyast_reinstall when failing detecting disk after installation
Description
After the installation is finished and the system tries to reboot, it is stuck at splash screen. Pressing Esc shows that a job, related to a hard drive doesn't finish. This doesn't seem as hardware issue because the test suite has ran and failed for different workers. We should try to figure out a way to collect more data, probably reproduce locally, as via vnc we cannot reboot the machine and collect the logs. Pressing Ctrl+F* just moves to splash screen. Attached there is screenshot of the stalled job.
Observation¶
openQA test in scenario sle-15-SP4-Online-x86_64-autoyast_reinstall@64bit fails in
installation
Test suite description¶
Parent job produces autoyast profile after successful completion. This test uses generated profile to do autoyast installation.
Reproducible¶
Fails since (at least) Build 18.1
Expected result¶
Last good: (unknown) (or more recent)
Further details¶
Always latest result in this scenario: latest
Suggestion¶
Check with YaST developers about resume option (as it didn't appear in GMC):
<bootloader t="map">
<global t="map">
<append>splash=silent video=1024x768 plymouth.ignore-serial-consoles console=ttyS0 console=tty kernel.softlockup_panic=1 resume=/dev/disk/by-uuid/d62912b9-aad8-427b-843b-625a7d23ee5e mitigations=auto</append>
Files
Updated by syrianidou_sofia over 3 years ago
- Project changed from openQA Tests to qe-yam
- Category deleted (
Bugs in existing tests)
Updated by JERiveraMoya about 3 years ago
- Subject changed from test fails in installation to Collect logs in autoyast_reinstall when failing detecting disk after installation
- Target version set to Current
Updated by geor about 3 years ago
- Status changed from Workable to In Progress
- Assignee set to geor
Updated by geor about 3 years ago
After small investigation:
When running yast clone_system in an installed SLES 15-SP4 (build 31.2) x86_64 system in order to generate the autoyast file, the generated autoinst.xml contains, inside the <append> block, the line resume=/dev/disk/by-uuid/dc9e40d9-f15a-4355-bf08-bf6f4a4a5332, where dc9e40d9-f15a-4355-bf08-bf6f4a4a5332 is the UUID of the swap partition. I presume this occurs because we have hibernation by default on x86_64.
The issue is that when creating a new SLES system with this autoyast file, the resume=/dev/disk/by-uuid/dc9e40d9-f15a-4355-bf08-bf6f4a4a5332 parameter is now added in the boot parameters in the grub.cfg entries. This in turn causes the system to hang indefinitely on boot, with A start job is running for /dev/disk/by-uuid/dc9e40d9-f15a-4355-bf08-bf6f4a4a5332, which is expected since the swap partition now has a different UUID and, either way this UUID does not exist in a new system.
Updated by geor about 3 years ago
- Status changed from In Progress to Blocked
A bugzilla entry for this exists already, https://bugzilla.suse.com/show_bug.cgi?id=1187690
Issue will be marked as blocked until fixed.
Updated by okurz about 3 years ago
Please consider picking up this ticket within the next 30 days or just set the ticket to the next lower priority of "Normal" (SLO: updated within 365 days).
Updated by geor almost 3 years ago
- Status changed from Blocked to Closed
There is a chance that this has been fixed in the meanwhile.
The latest job is booting normally: https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=64bit&test=autoyast_reinstall&version=15-SP4#step/installation/21
The clone-autoinst.xml still contains the append section with the resume=UUID info, so I can only assume that either it is ignored now, or the UUID of the swap partition is no longer written in the xml.
Either way, I commented on the bug about this and we ll be waiting for a response.