Bug 1172791 - The installer forces users to create PReP Boot partition even when it is not always required
Summary: The installer forces users to create PReP Boot partition even when it is not ...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.1
Hardware: ppc64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: 7.3
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
: 1447195 (view as bug list)
Depends On: 1303219
Blocks: PPCTracker F-ExcludeArch-ppc64le, PPC64LETracker
TreeView+ depends on / blocked
 
Reported: 2014-12-10 18:25 UTC by Jaromír Cápík
Modified: 2018-12-02 02:43 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1303219 (view as bug list)
Environment:
Last Closed: 2015-05-06 16:57:04 UTC


Attachments (Terms of Use)

Description Jaromír Cápík 2014-12-10 18:25:56 UTC
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

Comment 2 David Shea 2014-12-10 18:34:19 UTC
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?

Comment 3 Jaromír Cápík 2014-12-11 12:51:50 UTC
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.

Comment 4 David Cantrell 2014-12-17 16:33:16 UTC
Closing per comment #3.

Comment 5 Jaromír Cápík 2015-01-07 17:58:45 UTC
Closed as notabug? I don't understand why.

Comment 6 David Lehman 2015-05-06 16:57:04 UTC
(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.

Comment 8 Jaromír Cápík 2015-05-11 13:48:50 UTC
(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.

Comment 9 David Lehman 2015-05-14 14:15:35 UTC
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.

Comment 10 Jaromír Cápík 2015-05-14 15:38:06 UTC
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.

Comment 11 Jaromír Cápík 2015-05-14 16:10:54 UTC
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.

Comment 13 David Gibson 2017-07-25 03:09:26 UTC
*** Bug 1447195 has been marked as a duplicate of this bug. ***

Comment 14 David Gibson 2017-07-25 03:41:24 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.