RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1704283 - Upgraded PPC64 systems with multipath disks fail at yaboot prompt after upgrade
Summary: Upgraded PPC64 systems with multipath disks fail at yaboot prompt after upgrade
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: preupgrade-assistant-el6toel7
Version: 6.10
Hardware: ppc64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Petr Stodulka
QA Contact: Alois Mahdal
Miriam Portman
URL:
Whiteboard:
Depends On:
Blocks: 1818077 1818088
TreeView+ depends on / blocked
 
Reported: 2019-04-29 13:24 UTC by Renaud Métrich
Modified: 2021-08-20 08:28 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-20 08:28:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.

  Example:
  - 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

  Example:
  - 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):

preupgrade-assistant-el6toel7-0.7.9-1


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:

/dev/disk/by-id/dm-uuid-partX-mpath-WWID

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:
- RHEL6: QEMU\x20HARDDISK\x20\x20DISK
- 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:
    https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/upgrading_from_rhel_6_to_rhel_7/index#known-issues_troubleshooting-rhel-6-to-rhel-7

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.
Note You need to log in before you can comment on or make changes to this bug.