Bug 892388
| Summary: | adding a biosboot partition to a disk without free space is refused (correctly) but causes secondary effects on other entries and even tertiary effects | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Reartes Guillermo <rtguille> |
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | anaconda-maint-list, g.kaviyarasu, jonathan, sbueno, vanmeeuwen+fedora |
| Target Milestone: | --- | Flags: | rtguille:
needinfo?
|
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-02-05 14:29:47 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: | |||
| Attachments: | |||
Created attachment 673580 [details]
screenshot, before trying to add the biosboot partition
Created attachment 673582 [details]
screenshot, after trying to add the biosboot partition
Created attachment 673583 [details]
screenshot of the 'tertiary' effect
Created attachment 673584 [details]
anaconda.log
Created attachment 673585 [details]
program.log
Created attachment 673586 [details]
storage.log
Created attachment 674987 [details]
screenshot, before trying to add a /foo partition
Created attachment 674988 [details]
screenshot, in this case the secondary effect is just a 'reordering'
There seems to be some rough edges on the 'red banner' check. While it main function is ok, sometimes it does more.
Created attachment 677145 [details] anaconda-tb F18 RC4 (18.37.11) I was able to get this by hitting the issue, finish partitioning and going back to manual partitioning. ABRT Pointed to Bug 889875 (it might be a DUP of this one) It crashed with: anaconda 18.37.11 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 788, in <lambda> key=lambda p: p.partedPartition.number, File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 789, in clearPartitions reverse=True) File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 445, in execute storage.clearPartitions() File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 1480, in doKickstartStorage ksdata.clearpart.execute(storage, ksdata, instClass) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 399, in _doExecute doKickstartStorage(self.storage, self.data, self.instclass) File "/usr/lib64/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 91, in run threading.Thread.run(self, *args, **kwargs) AttributeError: 'NoneType' object has no attribute 'number' Since this happens once the user makes a mistake, it probable should be added to common bugs. In manual partitioning, if you make a mistake and get a 'red banner' please reboot and try again. (unless you known to recognize when anaconda is failing or not). This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 'version' of '18'. 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 prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 to Fedora 18's end of life. 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. Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: Trying to add a biosboot partition to a disk without free space disturbs the storage configuration, even if anaconda rejected the creation of such partition Version-Release number of selected component (if applicable): RC1 (18.37.10) How reproducible: always Steps to Reproduce: 0. do manual partitioning (scheme btrfs) with two disks, delete whatever there was. 1. add a /boot standard partition on the first disk (512mb) 2. add a swap standard partition on the second disk (512mb) 3. add a btrfs / mirror of the two disks. (4.98gb) 4. check that there are no more than 969kb of free space per disk left 5. try to ad a 1mb biosboot partition, a red banner rejects it but there are some secondary effects. Actual results: >>> Secondary effects: * The 'swap' is now 1mb size * The '/' entry now dissapears from the 'New Fedora 18 Installation' tree. A. If one just 'finish partitioning' anaconda will return to the MAIN HUB, but a yellow banner will say 'Not enough space in filesystems [...] Additional 2.69gb is needed' which indicates that the '/' went to limbo. B. If one changes back 'swap' to 512mb and then 'finish partitioning', anaconda will accept the storage configuration, even if it is not shown in is corresponding tree. Tertiary Effects (after B.): If one enters back to manual partitioning, the '/' will be shown, so it looks like a graphical glitch. However, if i try to test it again, anaconda will gets stuck (GUI becomes unresponsive), and by pressing one 'esc' and then 'back to ...' and 'done' buttons, i was able to reach the MAIN HUB with 'begin installation' UNLOCKED and 'No disks slected', i clicked 'begin installation' and it stared installing happily (and correctly). Expected results: anaconda should just refuse the biosboot partition creation (as it does now) but do not touch anything else. Additional info: