+++ This bug was initially created as a clone of Bug 959723 +++ Description of problem: A BTRFS volume configured to use a Size Policy of "As large as possible" isn't Version-Release number of selected component (if applicable): anaconda 19.24-1 How reproducible: Always. Steps to Reproduce: 1. Choose four 1 TB disks as targets for installation. 2. Installation options, choose partition scheme BTRFS 3. Manual partitioning: create a root mount point, set the size to 500GB. In Configure Volume, set raid level to raid 0. 4. Manual partitioning: create a home mount point; create a new volume, in Configure Volume, set the raid level to raid 1, and set the Size Policy to "as large as possible." Actual results: The /home volume size is not as large as it can be, 1.6TB of available space remains, unallocated. And by click back and forth on the two mount points, bug 959723 is triggered. Expected results: No available space remains. And the back and forth behavior results in a consistent, non-changing size, for both mount points. Additional info:
Premature submission. Description of problem: A BTRFS volume configured to use a Size Policy of "As large as possible" isn't consuming all available space, lease a large amount of space unallocated. Additional info: If I accept one of the possible "as large as possible" values in the UI, of 923.57GB for /home, which is raid1, and proceed with the installation, each of the four devices has 727GB free space on them. So the installer is definitely not making /home (fedoraR1) as large as possible.
Created attachment 743672 [details] anaconda.log
Created attachment 743673 [details] program.log
Created attachment 743674 [details] storage.state
Created attachment 743675 [details] storage.log
I'm trying this with LVM now, and when I change VG 'fedora2' to use "as large as possible" nothing happens. When I click on Modify, to go back into Configure Volume Group, the Size policy is still set to Automatic. So I change it to As large as possible, click Save. But nothing happens again. No error message. Back into Configure Volume Group and Size Policy is back to Automatic. Appears to be broken for LVM as well.
Created attachment 743680 [details] anacond.log LVM
Created attachment 743681 [details] program.log LVM
Created attachment 743682 [details] storage.log LVM
Fixed size doesn't work either. The Size Policy dialog seems to always revert to Automatic. I set it to something else, accept the change, click on Modify, and the setting is back to Automatic.
As with other dialogs, you have to apply the changes to the current mountpoint to see the changes take effect. Please try that and report back.
You still should see your recent selection on subsequent visits to the dialog, so maybe something is wrong.
UI wise, the Update Settings button needing to be clicked is confusing because it applies to the mount point, but in the Configure Volume Group (LVM) or Volume (Btrfs) dialog I'm only making changes to the VG. Upon clicking the Save button in that dialog, it should in fact be Saved. So I think there's a discontinuity if Update Settings needs to be clicked. For sure, if I change the Size Policy, click Save, then immediately click Modify to get back into the Configure dialog, the Size Policy setting is back to Automatic, not what I set it to and Saved as. And further Update Settings button is grayed out so I can't click it anyway, but actually I expect it to be grayed out because I haven't actually changed any details about the mount point, just the VG the mount point is contained in.
(In reply to comment #13) I retested with Fedora-Live-Desktop-x86_64-19-Beta-TC4-1.iso / anaconda 19.25-1
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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 19 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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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.