action #104259
closedcoordination #104256: [Epic] Research and document issues related with infrastructure in exotic architectures
Research about boot order for PowerVM & potentially relax validation of the scenario
0%
Description
Observation¶
openQA test in scenario sle-15-SP4-Online-ppc64le-select_disk@ppc64le-hmc-4disk fails SPORADICALLY in
validate_first_disk_selection
In qemu the same boot order holds after reboot, using *-boot order=c*.
For example here: https://openqa.suse.de/tests/8418089#step/validate_first_disk_selection/8 and https://openqa.suse.de/tests/8405891#step/validate_first_disk_selection/8
For ppc64le PowerVM it was working fine but started to fail, https://openqa.suse.de/tests/7887648#step/select_disks/1 now use sdb instead of sda https://openqa.suse.de/tests/7893357#step/validate_first_disk_selection/5.
According to YaST teams IFIR, we can only trust on the UUIDs.
Acceptance criteria¶
AC1: Research about boot order kept after reboot in ppc64le (pVM) / if any interesting finding document it in Confluence. File a bug if needed.
AC2: Ensure scenario does not fail sporadically and first disk selection is validated
Suggestions:¶
- Relax validation, only one of the 4 disks have the expected partitioning (as we erase in pVM https://openqa.suse.de/tests/8420923#step/bootloader_start/59 all the disks at the beginning and in the rest of archs they are fresh images).
- Get UUID of the target disk in some point during installation. There is a file (I don't remember exactly the name that keeps track of those, it is used by yast2 bootloader module) or some other identified? at the point of erasing only for ppc64le pVM and use it later after install. Better try to avoid to use the logs and read some file
- If all the above is not convincing enough, also consider to unschedule the test if it is not predictable.