Project

General

Profile

action #97325

Collect logs in autoyast_reinstall when failing detecting disk after installation

Added by syrianidou_sofia 2 months ago. Updated about 21 hours ago.

Status:
Blocked
Priority:
Normal
Assignee:
Target version:
Start date:
2021-08-22
Due date:
% Done:

50%

Estimated time:

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>

History

#1 Updated by syrianidou_sofia 2 months ago

  • Project changed from openQA Tests to qe-yast
  • Category deleted (Bugs in existing tests)

#2 Updated by JERiveraMoya about 2 months 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

#3 Updated by JERiveraMoya about 2 months ago

  • Description updated (diff)

#4 Updated by JERiveraMoya about 2 months ago

  • Status changed from New to Workable

#5 Updated by JERiveraMoya about 2 months ago

  • Priority changed from Normal to High

#6 Updated by geor about 2 months ago

  • Status changed from Workable to In Progress
  • Assignee set to geor

#7 Updated by geor about 2 months ago

  • % Done changed from 0 to 50

#8 Updated by geor about 2 months 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.

#9 Updated by geor about 2 months 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.

#10 Updated by okurz 14 days 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).

#11 Updated by oorlov about 21 hours ago

  • Priority changed from High to Normal

Also available in: Atom PDF