Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
The PReP Boot partition is not always required on Power7/8 systems equipped with Petitboot. It's only required on Power7 systems with the SMS Menu, but the installer rejects to begin the installation till the PReP Boot area is created. We should display a warning, that the PReP Boot is missing and it could lead to an unbootable state, but that's all. We should not force users to do what they don't want to do. However, we should keep creating the partition automatically because of two reasons which I don't want to explain here to avoid messing your head with details. What we need is a possibility to manually remove the automatically created PReP Boot partition and to begin the installation without this partition.
Version-Release number of selected component (if applicable):
RHEL-7.1-20141201.0-Server
How reproducible:
always
Let's talk about the complicated solution for a moment. Is there a way to reliably detect at install time whether a Power 7/8 system will need a prepboot partition? In other words, can we detect whether it has an SMS menu? And what are the two reasons to continue with creating it automatically?
Hello David.
Many versions of Petitboot exist and that makes any automagic difficult. Moreover, I'm not aware of any reliable way, how to easily read info about the flashed firmware without requiring additional tools. The missing PReP Boot can affect the default entry selection during the boot menu auto-generation and therefore this option requires some knowledge about the metal and admin who knows exactly what he wants to achieve. Therefore it's wiser/safer to keep the automatic PReP Boot creation intact and only allow a manual removal without blocking the whole installation.
(In reply to Jaromír Cápík from comment #5)
> Closed as notabug? I don't understand why.
Because there is no bug. There is no crash or other actual problem. Yes, it might be fun to support the latest thing, but this is something to play with in Fedora -- not RHEL.
(In reply to David Lehman from comment #6)
> (In reply to Jaromír Cápík from comment #5)
> > Closed as notabug? I don't understand why.
>
> Because there is no bug. There is no crash or other actual problem. Yes, it
> might be fun to support the latest thing, but this is something to play with
> in Fedora -- not RHEL.
There is no crash, but the current behaviour IS a problem. Support "LATEST" thing? The thing is "LATEST" more than 3 years. Moreover, we decided to support Power8 in OPAL mode in RHEL 7.2 with introduction of PPC64LE.
You don't need to "play" with that. The only thing that is required is that you disable the prepboot presence check that prevents users from starting the installer.
Clarifying request based on IRC discussion:
The request is to turn the missing PReP condition from an error to a warning.
There is no request to change any defaults. This provides the petitboot/OPAL
user a way to opt out of PReP while limiting the likelihood that the
SMS/powervm user will mistakenly omit PReP.
NOTE: One more thing might be needed and that's a skip of grub installation if there's no target for storing the stage1 blob. PetitBoot only requires a valid grub.cfg generated as it parses the cfg content.
NOTE2: grub2-install apparently doesn't touch the prepboot content when the prepboot partition is not passed as argument. I successfully installed grub even without prepboot partition. The /boot/grub2 content got created.
This is still present in 7.4 and is obviously too late for 7.3. Should we retarget to 7.5?
Regarding the initial description I think the question of POWER7 vs POWER8, SMS vs whatever is missing the point a bit.
The main distinction is between "pSeries" (KVM guest or PowerVM LPAR) and "PowerNV" (bare metal) contexts. "pSeries" boots with Open Firmware and requires a PReP boot partition in most circumstances I'm aware of. "PowerNV" boots with petitboot and doesn't require a PReP boot partition on any supported configuration.
Note that implementing this may require changes in the grub installer as well. Right now I suspect it will error out if it can't write to a PReP boot partition, even though this step can be safely skipped on a PowerNV/petitboot machine.
Note that the PowerNV boot system is a bit magic. Although we use the grub installer, GRUB is actually *never* executed during boot - which is why we can get away without putting the grub image anywhere. Instead petitboot just knows how to read grub configuration and uses those to locate the kernels which it boots directly.
Comment 17RHEL Program Management
2020-12-15 07:32:22 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.