Red Hat Bugzilla – Bug 906906
Potential size incorrectly capped to available unpartitioned space when editing a pre-existing LV in custom partitioning
Last modified: 2013-05-12 19:42:14 EDT
This is a bug to split out one element of the previous report https://bugzilla.redhat.com/show_bug.cgi?id=892269 - see https://bugzilla.redhat.com/show_bug.cgi?id=892269#c15 . We decided that bug was actually covering three different problems, and leading to confusion.
If you are in custom partitioning and you have a pre-existing LV, and there is empty space in that LV, you cannot edit VGs within that VG and make them larger - the 'Desired Capacity (MB)' spinbutton element incorrectly caps the maximum possible size. This applies both to LVs that already exist within the VG, and if you create a new mount point and it is created as a new LV within the existing VG: in both cases, what happens is you cannot make the LV any larger than its current size.
This is pretty easy to reproduce: the simplest reproducer is to set up a system where you have a VG with space within it, say a 14GB VG with a 6GB 'root' LV and a 2GB 'swap' LV. There is therefore 8GB of space remaining in the VG. But if you go to custom partitioning, select the 'root' VG and try to edit its size up to anything larger than 6000MB, anaconda will refuse. You can edit it *down* to a smaller size - say, 5000MB - but once you do so and hit 'Apply Changes', you cannot make it any larger even than the smaller size you just set. You can't edit it back to 6000MB, even.
The same applies if you hit the + button to create a new mount point for the proposed F18 install. It will be created as a new LV within the existing VG, if you have no or little unpartitioned space remaining, and again, you will not be able to edit it to be any size larger than the size it was created with.
*** Bug 892269 has been marked as a duplicate of this bug. ***
Please refer to https://bugzilla.redhat.com/show_bug.cgi?id=892269#c17 for additional information about installer space management issues.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
This appears to be fixed in 19 Beta TC4. Closing.