Project

General

Profile

Actions

action #97325

closed

Collect logs in autoyast_reinstall when failing detecting disk after installation

Added by syrianidou_sofia over 2 years ago. Updated about 2 years ago.

Status:
Closed
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>

Files

Actions #1

Updated by syrianidou_sofia over 2 years ago

  • Project changed from openQA Tests to qe-yam
  • Category deleted (Bugs in existing tests)
Actions #2

Updated by JERiveraMoya over 2 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
Actions #3

Updated by JERiveraMoya over 2 years ago

  • Description updated (diff)
Actions #4

Updated by JERiveraMoya over 2 years ago

  • Status changed from New to Workable
Actions #5

Updated by JERiveraMoya over 2 years ago

  • Priority changed from Normal to High
Actions #6

Updated by geor over 2 years ago

  • Status changed from Workable to In Progress
  • Assignee set to geor
Actions #7

Updated by geor over 2 years ago

  • % Done changed from 0 to 50
Actions #8

Updated by geor over 2 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.

Actions #9

Updated by geor over 2 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.

Actions #10

Updated by okurz over 2 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).

Actions #11

Updated by oorlov over 2 years ago

  • Priority changed from High to Normal
Actions #12

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

Actions

Also available in: Atom PDF