Bug 1029893 - F20 - Handle default PReP boot size creation during manual partitioning properly
F20 - Handle default PReP boot size creation during manual partitioning properly
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: python-blivet (Show other bugs)
20
ppc64 All
unspecified Severity high
: ---
: ---
Assigned To: Vratislav Podzimek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-13 08:25 EST by IBM Bug Proxy
Modified: 2015-05-29 12:52 EDT (History)
13 users (show)

See Also:
Fixed In Version: python-blivet-0.35-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-05-29 12:52:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
PReP boot default size assigned by installer is 10 MB (80.60 KB, image/png)
2013-11-13 08:26 EST, IBM Bug Proxy
no flags Details
After continuing with 10 MB PReP I got this error (67.08 KB, image/png)
2013-11-13 08:26 EST, IBM Bug Proxy
no flags Details
/tmp/anaconda.log (53.49 KB, text/plain)
2013-11-13 08:26 EST, IBM Bug Proxy
no flags Details
/tmp/anaconda-yum.conf (351 bytes, text/plain)
2013-11-13 08:27 EST, IBM Bug Proxy
no flags Details
/tmp/X.log (6.45 KB, text/plain)
2013-11-13 08:27 EST, IBM Bug Proxy
no flags Details
/tmp/ifcfg.log (643 bytes, text/plain)
2013-11-13 08:27 EST, IBM Bug Proxy
no flags Details
/tmp/packaging.log (341.11 KB, text/plain)
2013-11-13 08:27 EST, IBM Bug Proxy
no flags Details
/tmp/program.log (18.52 KB, text/plain)
2013-11-13 08:27 EST, IBM Bug Proxy
no flags Details
/tmp/storage.log (218.37 KB, text/plain)
2013-11-13 08:28 EST, IBM Bug Proxy
no flags Details
/tmp/storage.state (64.00 KB, text/plain)
2013-11-13 08:28 EST, IBM Bug Proxy
no flags Details
/tmp/syslog (44.89 KB, text/plain)
2013-11-13 08:28 EST, IBM Bug Proxy
no flags Details
/tmp/vncserver.log (1.70 KB, text/plain)
2013-11-13 08:28 EST, IBM Bug Proxy
no flags Details
updates.img to get more debugging information (18.36 KB, application/x-gzip)
2013-11-14 03:15 EST, Vratislav Podzimek
no flags Details
anaconda.log file after booting with provided "updates.img" images (49.87 KB, text/plain)
2013-11-28 07:01 EST, IBM Bug Proxy
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 99801 None None None Never

  None (edit)
Description IBM Bug Proxy 2013-11-13 08:25:57 EST
== Comment: #0 - Shubham Goyal <shubgoya@in.ibm.com> - 2013-11-13 00:43:29 ==
Description of problem: While creating a PReP boot partition during manual partitioning, below is the problem am experiencing:

By default PReP boot size which installer is defaulting to is 10 MB, means if I provide something big like 1 GB, 2 GB, 50 MB, installer is changing it to 10 MB (Desired Capacity) automatically. Now when I press 'DONE' its not considering the PReP partition created as proper & giving "bootloader stage 1" error. You need to delete this & create a PReP boot with *ONLY* 4MB capacity to get it working. Now my suggestion is if the default PReP size expected is 4 MB than shouldn't installer defaults its "Desired Capacity" to 4 MB instead of 10 MB.

I think we should properly handle default size creation of PReP specially considering the fact that many users don't know about prep partition size limits & to avoid confusion for users working on Fedora PPC.

How reproducible: Always


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

Steps to Reproduce:

1) Try creating a PReP partition (in manual partitioning screen) of size other than *4 MB* like 1 GB, 2 GB or 50 MB.
2) Update & continue with installation after creating other relevant partitions like root, boot etc.

Actual results: Installer is defaulting PReP size to 10 MB & if u continue with installation it will show u a "Stage 1 bootloader" error

Expected results: If installer has to assign a default value than it should assign something which is anticipated (like in this case 4 MB is the PReP default size).

== Comment: #17 - Kamalesh Babulal <kamaleshb@in.ibm.com> - 2013-11-13 04:13:52 ==
While trying to reproduce the issue, Its not dropping to stage 1 error while rebooting. Am getting this error as soon as I press "DONE -> Accept Changes" from manual partitioning screen. Check 2nd attachment.
Comment 1 IBM Bug Proxy 2013-11-13 08:26:12 EST
Created attachment 823405 [details]
PReP boot default size assigned by installer is 10 MB
Comment 2 IBM Bug Proxy 2013-11-13 08:26:31 EST
Created attachment 823406 [details]
After continuing with 10 MB PReP I got this error
Comment 3 IBM Bug Proxy 2013-11-13 08:26:45 EST
Created attachment 823407 [details]
/tmp/anaconda.log
Comment 4 IBM Bug Proxy 2013-11-13 08:27:00 EST
Created attachment 823408 [details]
/tmp/anaconda-yum.conf
Comment 5 IBM Bug Proxy 2013-11-13 08:27:13 EST
Created attachment 823409 [details]
/tmp/X.log
Comment 6 IBM Bug Proxy 2013-11-13 08:27:26 EST
Created attachment 823411 [details]
/tmp/ifcfg.log
Comment 7 IBM Bug Proxy 2013-11-13 08:27:39 EST
Created attachment 823412 [details]
/tmp/packaging.log
Comment 8 IBM Bug Proxy 2013-11-13 08:27:52 EST
Created attachment 823415 [details]
/tmp/program.log
Comment 9 IBM Bug Proxy 2013-11-13 08:28:04 EST
Created attachment 823420 [details]
/tmp/storage.log
Comment 10 IBM Bug Proxy 2013-11-13 08:28:16 EST
Created attachment 823425 [details]
/tmp/storage.state
Comment 11 IBM Bug Proxy 2013-11-13 08:28:29 EST
Created attachment 823427 [details]
/tmp/syslog
Comment 12 IBM Bug Proxy 2013-11-13 08:28:41 EST
Created attachment 823428 [details]
/tmp/vncserver.log
Comment 13 Vratislav Podzimek 2013-11-14 03:14:44 EST
(In reply to IBM Bug Proxy from comment #0)
> == Comment: #0 - Shubham Goyal <shubgoya@in.ibm.com> - 2013-11-13 00:43:29 ==
> Description of problem: While creating a PReP boot partition during manual
> partitioning, below is the problem am experiencing:
> 
> By default PReP boot size which installer is defaulting to is 10 MB, means
> if I provide something big like 1 GB, 2 GB, 50 MB, installer is changing it
> to 10 MB (Desired Capacity) automatically. Now when I press 'DONE' its not
> considering the PReP partition created as proper & giving "bootloader stage
> 1" error. You need to delete this & create a PReP boot with *ONLY* 4MB
> capacity to get it working. Now my suggestion is if the default PReP size
> expected is 4 MB than shouldn't installer defaults its "Desired Capacity" to
> 4 MB instead of 10 MB.
> 
> I think we should properly handle default size creation of PReP specially
> considering the fact that many users don't know about prep partition size
> limits & to avoid confusion for users working on Fedora PPC.
> 
> How reproducible: Always
> 
> 
> Version-Release number of selected component (if applicable):
> TC6.0
> 
> Steps to Reproduce:
> 
> 1) Try creating a PReP partition (in manual partitioning screen) of size
> other than *4 MB* like 1 GB, 2 GB or 50 MB.
> 2) Update & continue with installation after creating other relevant
> partitions like root, boot etc.
> 
> Actual results: Installer is defaulting PReP size to 10 MB & if u continue
> with installation it will show u a "Stage 1 bootloader" error
Installer sets the value to the maximum size for that type of format (because your value exceeds it) -- i.e. 10 MB for a PReP format. The default is 4 MB.

> 
> Expected results: If installer has to assign a default value than it should
> assign something which is anticipated (like in this case 4 MB is the PReP
> default size).
The problem here is that a 10 MB PReP boot should be a valid stage1 device. And the code looks like it should work. Maybe there is some problem with rounding size of the partition or something like that.

Could you please try using the attached updates.img, reproduce the issue and attach the anaconda.log file? It should provide us additional debugging information. Thanks!
Comment 14 Vratislav Podzimek 2013-11-14 03:15:48 EST
Created attachment 823809 [details]
updates.img to get more debugging information
Comment 15 IBM Bug Proxy 2013-11-28 07:01:36 EST
Created attachment 830196 [details]
anaconda.log file after booting with provided "updates.img" images


------- Comment (attachment only) From shubgoya@in.ibm.com 2013-11-28 11:54 EDT-------
Comment 16 Vratislav Podzimek 2013-11-29 03:07:24 EST
(In reply to IBM Bug Proxy from comment #15)
> Created attachment 830196 [details]
> anaconda.log file after booting with provided "updates.img" images
Thanks! And now we have the answer:

11:52:14,595 DEBUG anaconda: _is_valid_disklabel(sda1) returning True
11:52:14,595 DEBUG anaconda: _is_valid_size(sda1) returning True
11:52:14,595 DEBUG anaconda: _is_valid_location info:
11:52:14,595 DEBUG anaconda: 	max_mb: 10
11:52:14,596 DEBUG anaconda: 	device type: partition
11:52:14,596 DEBUG anaconda: 	partedPartition: True
11:52:14,596 DEBUG anaconda: 	end_sector: 22527
11:52:14,596 DEBUG anaconda: 	sector_size: 512
11:52:14,596 DEBUG anaconda: 	end_mb: 10.9995117188
11:52:14,596 DEBUG anaconda: 	end_mb greater than max_mb
11:52:14,597 DEBUG anaconda: _is_valid_location(sda1) returning False
11:52:14,597 WARN anaconda: sda1 not bootable
11:52:14,597 DEBUG anaconda: _is_valid_format(sda1) returning True
11:52:14,597 DEBUG anaconda: is_valid_stage1_device(sda1) returning False

10MB request rounded to sectors (and maybe cylinders) results in almost 11MB partition that exceeds the maximum of 10 MB and is thus rejected as a valid stage1 device.

David, any idea how to deal with this? Should we decrease the maximum size of the PReP boot format to 9 MB? Or should the check be more benevolent?
Comment 17 David Lehman 2013-12-02 15:46:11 EST
We have an overzealous limit to the end sector of PReP partitions. It is 10MB but it only needs to be 2GB. The default alignment puts the start of the first partition at 1MiB. The max/default size for a PReP partition is 10MB. Therefore you end up with 1MiB + 10MB, which is obviously more than 10MB.

The reason I have not posted a patch for this relatively simple fix is the total lack of documented requirements for PReP -- I am waiting for some comprehensive set of requirements for these systems instead of always fumbling around in the dark, having to fix one or two bugs just like this one nearly every release.
Comment 18 Vratislav Podzimek 2013-12-03 03:16:11 EST
(In reply to David Lehman from comment #17)
> We have an overzealous limit to the end sector of PReP partitions. It is
> 10MB but it only needs to be 2GB. The default alignment puts the start of
> the first partition at 1MiB. The max/default size for a PReP partition is
> 10MB. Therefore you end up with 1MiB + 10MB, which is obviously more than
> 10MB.
> 
> The reason I have not posted a patch for this relatively simple fix is the
> total lack of documented requirements for PReP -- I am waiting for some
> comprehensive set of requirements for these systems instead of always
> fumbling around in the dark, having to fix one or two bugs just like this
> one nearly every release.
Ah, okay, thanks for the explanation!

IBM, is there any documentation of the PReP requirements we could use?
Comment 19 Gustavo Luiz Duarte 2013-12-06 19:17:27 EST
(In reply to Vratislav Podzimek from comment #18)
> (In reply to David Lehman from comment #17)
> > We have an overzealous limit to the end sector of PReP partitions. It is
> > 10MB but it only needs to be 2GB. The default alignment puts the start of
> > the first partition at 1MiB. The max/default size for a PReP partition is
> > 10MB. Therefore you end up with 1MiB + 10MB, which is obviously more than
> > 10MB.
> > 
> > The reason I have not posted a patch for this relatively simple fix is the
> > total lack of documented requirements for PReP -- I am waiting for some
> > comprehensive set of requirements for these systems instead of always
> > fumbling around in the dark, having to fix one or two bugs just like this
> > one nearly every release.
> Ah, okay, thanks for the explanation!
> 
> IBM, is there any documentation of the PReP requirements we could use?

I don't think these requirements are written down in any document other than OpenFirmware's code (which probably depends on firmware version). We have had issues in the past and the 4 to 10 MB (first partition in the disk) seemed to work well and that is what we have been trying to keep. IMHO these are reasonable constraints and I don't see any reason to go anywhere else. If Anaconda can't stick to these constraints for some reason, then we should understand why and act on that, either relaxing the constraints or making Anaconda able to stick to the existing ones.


Some usability considerations for longer term:
 1. I don't see why anyone would care about the PReP partition size. Anaconda should just set it to the default size instead of asking the user.
 2. OpenFirmware does not support multiple PReP partitions. So, Anaconda should not treat the PReP as a regular partition. I believe Anaconda should automatically create a PReP partition without asking anything to the user, or re-use if one exists.
Comment 20 Vratislav Podzimek 2013-12-10 03:52:46 EST
(In reply to Gustavo Luiz Duarte from comment #19)
> (In reply to Vratislav Podzimek from comment #18)
> > (In reply to David Lehman from comment #17)
> > > We have an overzealous limit to the end sector of PReP partitions. It is
> > > 10MB but it only needs to be 2GB. The default alignment puts the start of
> > > the first partition at 1MiB. The max/default size for a PReP partition is
> > > 10MB. Therefore you end up with 1MiB + 10MB, which is obviously more than
> > > 10MB.
> > > 
> > > The reason I have not posted a patch for this relatively simple fix is the
> > > total lack of documented requirements for PReP -- I am waiting for some
> > > comprehensive set of requirements for these systems instead of always
> > > fumbling around in the dark, having to fix one or two bugs just like this
> > > one nearly every release.
> > Ah, okay, thanks for the explanation!
> > 
> > IBM, is there any documentation of the PReP requirements we could use?
> 
> I don't think these requirements are written down in any document other than
> OpenFirmware's code (which probably depends on firmware version). We have
> had issues in the past and the 4 to 10 MB (first partition in the disk)
> seemed to work well and that is what we have been trying to keep. IMHO these
> are reasonable constraints and I don't see any reason to go anywhere else.
> If Anaconda can't stick to these constraints for some reason, then we should
> understand why and act on that, either relaxing the constraints or making
> Anaconda able to stick to the existing ones.
So I believe we could raise the upper bound for the end sector to be 11 MB, i.e. 10MB PreP starting at the first megabyte of the disk. That should fix the issue without giving a lot of space for further issues.

> 
> 
> Some usability considerations for longer term:
>  1. I don't see why anyone would care about the PReP partition size.
> Anaconda should just set it to the default size instead of asking the user.
>  2. OpenFirmware does not support multiple PReP partitions. So, Anaconda
> should not treat the PReP as a regular partition. I believe Anaconda should
> automatically create a PReP partition without asking anything to the user,
> or re-use if one exists.
That's what Anaconda does when automatic partitioning is used. However, if user chooses to do the manual partitioning, we shouldn't try to be wiser than they are by doing things behind their back.
Comment 21 IBM Bug Proxy 2014-01-02 03:03:26 EST
------- Comment From onmahaja@in.ibm.com 2014-01-02 07:52 EDT-------
*** Bug 99561 has been marked as a duplicate of this bug. ***
Comment 22 Fedora End Of Life 2015-05-29 05:45:02 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

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