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-el6toel7 | Assignee: | Petr Stodulka <pstodulk> |
| Status: | CLOSED CANTFIX | QA Contact: | Alois Mahdal <amahdal> |
| Severity: | high | Docs Contact: | Miriam Portman <mportman> |
| Priority: | high | ||
| Version: | 6.10 | CC: | fkrska, jzeleny, mportman, ovasik, podvody, pstodulk |
| Target Milestone: | rc | Keywords: | Extras, Reopened |
| Target Release: | --- | ||
| Hardware: | ppc64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1818077, 1818088 | ||
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.
|
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 ...