Bug 1203012 - [Build 19.1] openQA test fails in disable_grub_timeout: The system is using by-uuid but it finds by-path
[Build 19.1] openQA test fails in disable_grub_timeout: The system is using b...
Status: CONFIRMED
Classification: openSUSE
Product: PUBLIC SUSE Linux Enterprise Server 15 SP5
Classification: openSUSE
Component: Bootloader
unspecified
Other Other
: P2 - High : Normal
: ---
Assigned To: YaST Team
https://openqa.suse.de/tests/9426235/...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2022-09-01 08:44 UTC by Chenzi Cao
Modified: 2022-09-21 08:25 UTC (History)
11 users (show)

See Also:
Found By: openQA
Services Priority:
Business Priority:
Blocker: Yes
Marketing QA Status: ---
IT Deployment: ---
mfilka: needinfo? (jreidinger)


Attachments
y2log (312.49 KB, application/x-xz)
2022-09-07 08:59 UTC, Chenzi Cao
Details
screenshot_manual_test (62.89 KB, image/png)
2022-09-07 09:01 UTC, Chenzi Cao
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chenzi Cao 2022-09-01 08:44:00 UTC
## Observation

openQA test in scenario sle-15-SP5-Migration-from-SLE15-SPx-x86_64-offline_sles15sp4_media_basesys-srv-desk-dev_all_full@64bit fails in
[disable_grub_timeout](https://openqa.suse.de/tests/9426235/modules/disable_grub_timeout/steps/14)

## Test suite description
The base test suite is used for job templates defined in YAML documents. It has no settings of its own.

## Further details

Always latest result in this scenario: [latest](https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Migration-from-SLE15-SPx&machine=64bit&test=offline_sles15sp4_media_basesys-srv-desk-dev_all_full&version=15-SP5)

Steps to reproduce:
- Boot up a qcow of SLES15SP4, register the product & some modules, fully patch the packages
- Reboot and perform upgrade to SLES15SP5 build19.1
- Click Next step by step
- In the page of Installation Settings, click "Booting"

Then observe an error:

Unsupported Configuration
YaST cannot process current bootloader configuration (Unknown udev device '/dev/disk/by-path.pci-0000:00:09.0'). Propose new configuration from scratch?

Checking the qcow of SLES15SP4, it is using "by-uuid", not "by-path", please see the log as below:

susetest:~ # cat /etc/fstab    
UUID=02cd1e1f-11d2-47ab-a5fb-f7ad301e79c4  /                       btrfs  defaults                      0  0
UUID=02cd1e1f-11d2-47ab-a5fb-f7ad301e79c4  /var                    btrfs  subvol=/@/var                 0  0
UUID=02cd1e1f-11d2-47ab-a5fb-f7ad301e79c4  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=02cd1e1f-11d2-47ab-a5fb-f7ad301e79c4  /tmp                    btrfs  subvol=/@/tmp                 0  0
UUID=02cd1e1f-11d2-47ab-a5fb-f7ad301e79c4  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=02cd1e1f-11d2-47ab-a5fb-f7ad301e79c4  /root                   btrfs  subvol=/@/root                0  0
UUID=02cd1e1f-11d2-47ab-a5fb-f7ad301e79c4  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=02cd1e1f-11d2-47ab-a5fb-f7ad301e79c4  /home                   btrfs  subvol=/@/home                0  0
UUID=02cd1e1f-11d2-47ab-a5fb-f7ad301e79c4  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=02cd1e1f-11d2-47ab-a5fb-f7ad301e79c4  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=02cd1e1f-11d2-47ab-a5fb-f7ad301e79c4  /.snapshots             btrfs  subvol=/@/.snapshots          0  0
UUID=584e64f0-dcd2-4011-ba78-707b9b8977be  swap                    swap   defaults                      0  0

susetest:~ # cat  /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.14.21-150400.22-default root=UUID=02cd1e1f-11d2-47ab-a5fb-f7ad301e79c4 splash=silent video=1024x768 plymouth.ignore-serial-consoles console=ttyS0 console=tty kernel.softlockup_panic=1 resume=/dev/disk/by-uuid/584e64f0-dcd2-4011-ba78-707b9b8977be security=apparmor mitigations=auto

susetest:~ # cat /etc/sysconfig/bootloader

## Path:        System/Bootloader
## Description: Bootloader configuration
## Type:        list(grub,grub2,grub2-efi,none)
## Default:     grub2
#
# Type of bootloader in use.
# For making the change effect run bootloader configuration tool
# and configure newly selected bootloader
#
#
LOADER_TYPE="grub2"

## Path:        System/Bootloader
## Description: Bootloader configuration
## Type:        yesno
## Default:     "no"
#
# Enable Secure Boot support
# Only available on UEFI systems and IBM z15+.
#
#
SECURE_BOOT="yes"

## Path:        System/Bootloader
## Description: Bootloader configuration
## Type:        yesno
## Default:     "no"
#
# Enable Trusted Boot support
# Only available on hardware with a Trusted Platform Module.
#
TRUSTED_BOOT="no"

## Path:        System/Bootloader
## Description: Bootloader configuration
## Type:        yesno
## Default:     "yes"
#
# Update nvram boot settings (UEFI, OF)
# Unset to preserve specific settings or workaround firmware issues.
#
UPDATE_NVRAM="yes"

This issue happens on all migration cases of sles15sp4 to sles15sp5:

https://openqa.suse.de/tests/9426235#step/disable_grub_timeout/14
https://openqa.suse.de/tests/9426231#step/disable_grub_timeout/14
https://openqa.suse.de/tests/9426233#step/disable_grub_timeout/14
Comment 1 Michael Chang 2022-09-01 09:44:43 UTC
In light of the error message, I think this should have yast team take a look first ...
Comment 2 Michal Filka 2022-09-02 11:41:24 UTC
(In reply to Chenzi Cao from comment #0)

> Then observe an error:
> 
> Unsupported Configuration
> YaST cannot process current bootloader configuration (Unknown udev device
> '/dev/disk/by-path.pci-0000:00:09.0'). Propose new configuration from
> scratch?
> 

@Josef:
Could you comment? Any idea why "by-path" is proposed instead of "by-uuid", moreover with wrong value?
Comment 3 Josef Reidinger 2022-09-02 19:46:49 UTC
I failed to find yast logs in that openqa runs. Can we get it? I need to check where that udev device is read.
Comment 4 Chenzi Cao 2022-09-07 08:59:49 UTC
Created attachment 861342 [details]
y2log

Please find the attached y2log and the screenshot of the error which is from a manual case. 

The openqa case didn't generate the y2log, so I reproduce it with a manual test. The error is a little bit different: it finds by-id, but I checked the qcow of sles15sp4, it is using by-uuid.
Comment 5 Chenzi Cao 2022-09-07 09:01:06 UTC
Created attachment 861343 [details]
screenshot_manual_test

This is the screenshot of the error on manual test.
Comment 6 Huajian Luo 2022-09-19 09:06:06 UTC
I've recreated the qcow files with QEMU_VIRTIO_RNG=0 and the failed cases
passed.

The job to create the qcow: 
https://openqa.nue.suse.com/tests/9536760

The VR:
https://openqa.nue.suse.com/tests/9537020