Project

General

Profile

Actions

action #104259

closed

coordination #104256: [Epic] Research and document issues related with infrastructure in exotic architectures

Research about boot order for PowerVM & potentially relax validation of the scenario

Added by JERiveraMoya over 2 years ago. Updated 4 months ago.

Status:
Rejected
Priority:
Low
Assignee:
-
Target version:
-
Start date:
2021-12-22
Due date:
% Done:

0%

Estimated time:

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.
Actions #1

Updated by JERiveraMoya over 2 years ago

  • Priority changed from Normal to Low
Actions #2

Updated by JERiveraMoya about 2 years ago

  • Subject changed from [timebox: 16h] Research about boot order for PowerVM to Research about boot order for PowerVM & potentially relax validation of the scenario
  • Description updated (diff)
  • Priority changed from Low to High
Actions #3

Updated by JERiveraMoya about 2 years ago

  • Description updated (diff)
Actions #4

Updated by JERiveraMoya about 2 years ago

  • Description updated (diff)
Actions #5

Updated by JERiveraMoya about 2 years ago

  • Tags deleted (qe-yast-refinement)
  • Description updated (diff)
  • Status changed from New to Workable
Actions #6

Updated by JERiveraMoya about 2 years ago

  • Description updated (diff)
Actions #7

Updated by JERiveraMoya almost 2 years ago

  • Priority changed from High to Normal

Setting priority to Normal, not seen for a while. Now focusing in Maintenance, to be revisited when Product validation will resume.

Actions #8

Updated by JERiveraMoya over 1 year ago

  • Description updated (diff)
  • Target version deleted (Current)
Actions #9

Updated by JERiveraMoya over 1 year ago

  • Priority changed from Normal to Low
Actions #10

Updated by JERiveraMoya 11 months ago

  • Status changed from Workable to New
Actions #11

Updated by JERiveraMoya 4 months ago

  • Status changed from New to Rejected

PowerVM infra has even more complex infra issues, discarding this.

Actions

Also available in: Atom PDF