Bug 1704283

Summary: Upgraded PPC64 systems with multipath disks fail at yaboot prompt after upgrade
Product: Red Hat Enterprise Linux 6 Reporter: Renaud Métrich <rmetrich>
Component: preupgrade-assistant-el6toel7Assignee: Petr Stodulka <pstodulk>
Status: CLOSED CANTFIX QA Contact: Alois Mahdal <amahdal>
Severity: high Docs Contact: Miriam Portman <mportman>
Priority: high    
Version: 6.10CC: fkrska, jzeleny, mportman, ovasik, podvody, pstodulk
Target Milestone: rcKeywords: Extras, Reopened
Target Release: ---   
Hardware: ppc64   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-08-20 08:28:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1818077, 1818088    

Description Renaud Métrich 2019-04-29 13:24:06 UTC
Description of problem:

This issue is specific to PPC64 systems because of the change from yaboot to Grub2 between RHEL6 and RHEL7. Also, it only affects systems having multipathed disks.
After upgrade of such system, the boot fails at the yaboot prompt because grub2-install performed in RHEL6_7/system/yaboot/postupgrade.d/postupgrade-yaboot.sh fails due to not finding the PREP partition. The PREP partition is extracted from /etc/yaboot.conf's "boot=<...>" property and passed as-is to the "grub2-install" command, but this fails for many reasons:

1. The upgrade environment has no knowledge of the multipath maps that were in use

  In case the system disk holding PREP partition was not "mpatha" but something else (e.g. "mpathc" or "system" or another custom mapping), the corresponding device will not be found at all or no PREP partition will be found if "mpatha" is not the expected boot disk.

  - root disk is "mpathc", there will be "boot=/dev/mapper/mpathcp1" in /etc/yaboot.conf
  - while in upgrade environment, if there is no other multipathed disk, "mpathc" will now show up as "mpatha" and "grub2-install /dev/mapper/mpathcp1" will be executed on an unknown disk

2. In the upgrade environment (a sort of RHEL7), the multipath partitions are named "mpathXY" instead of "mpathXpY" as seen on RHEL6

  - root disk is "mpatha", there will be "boot=/dev/mapper/mpathap1" in /etc/yaboot.conf
  - while in upgrade environment, the PREP partition above will be accessible through "/dev/mapper/mpatha1", not "/dev/mapper/mpathap1" (no "p") and "grub2-install /dev/mapper/mpathap1" will be executed on an unknown disk

3. The administrator performing the upgrade cannot force using one of the raw partition making the device (e.g. "/dev/sda1") because device nodes will not exist

Version-Release number of selected component (if applicable):


How reproducible:

Always on PPC64 systems with multipath

Additional info:

The huge difference between RHEL6 and RHEL7 is device naming ("mpathXY" instead of "mpathXpY"). So far, the only solution I found was to address the device by ID using the "dm-uuid" name which seems to still be accurate between RHEL6 and RHEL7, as shown in the example below:


All the other paths seemed different between RHEL6 and RHEL7.

Hence, with "boot=/dev/disk/by-id/dm-uuid-partX-mpath-WWID" in /etc/yaboot.conf, I was able to successfully reboot into RHEL7 upon upgrade.

Note however, that WWID may not "survive" the upgrade.
In particular, when simulating a multipath system using qemu-kvm, I found out that my disk initially named "QEMU HARDDISK  DISK" was named as shown below from WWID's perspective:
- Upgrade environment: QEMU_HARDDISK_DISK

With real hardware, this may not be an issue, but I'm not 100% sure at all ...

Comment 10 Petr Stodulka 2021-08-20 08:28:00 UTC
We have documented the issue in the upgrade documentation:

Closing the ticket as we do not plan to do any updates in the package anymore and there is not known reliable fix for the issue we could implement.