Collect logs in autoyast_reinstall when failing detecting disk after installation
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.
openQA test in scenario sle-15-SP4-Online-x86_64-autoyast_reinstall@64bit fails in
Test suite description¶
Parent job produces autoyast profile after successful completion. This test uses generated profile to do autoyast installation.
Fails since (at least) Build 18.1
Last good: (unknown) (or more recent)
Always latest result in this scenario: latest
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>
#8 Updated by geor about 2 months ago
After small investigation:
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
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.