== Comment: #0 - Shubham Goyal <shubgoya.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.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.
Created attachment 823405 [details] PReP boot default size assigned by installer is 10 MB
Created attachment 823406 [details] After continuing with 10 MB PReP I got this error
Created attachment 823407 [details] /tmp/anaconda.log
Created attachment 823408 [details] /tmp/anaconda-yum.conf
Created attachment 823409 [details] /tmp/X.log
Created attachment 823411 [details] /tmp/ifcfg.log
Created attachment 823412 [details] /tmp/packaging.log
Created attachment 823415 [details] /tmp/program.log
Created attachment 823420 [details] /tmp/storage.log
Created attachment 823425 [details] /tmp/storage.state
Created attachment 823427 [details] /tmp/syslog
Created attachment 823428 [details] /tmp/vncserver.log
(In reply to IBM Bug Proxy from comment #0) > == Comment: #0 - Shubham Goyal <shubgoya.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!
Created attachment 823809 [details] updates.img to get more debugging information
Created attachment 830196 [details] anaconda.log file after booting with provided "updates.img" images ------- Comment (attachment only) From shubgoya.com 2013-11-28 11:54 EDT-------
(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?
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.
(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?
(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.
(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 From onmahaja.com 2014-01-02 07:52 EDT------- *** Bug 99561 has been marked as a duplicate of this bug. ***
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.