Bug 906906 - Potential size incorrectly capped to available unpartitioned space when editing a pre-existing LV in custom partitioning
Potential size incorrectly capped to available unpartitioned space when editi...
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All All
unspecified Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: 892269 (view as bug list)
Depends On:
Blocks: F19Blocker/F19FinalBlocker
  Show dependency treegraph
Reported: 2013-02-01 16:14 EST by Adam Williamson
Modified: 2013-05-12 19:42 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-05-12 19:42:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2013-02-01 16:14:32 EST
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.
Comment 1 Adam Williamson 2013-02-01 17:05:53 EST
*** Bug 892269 has been marked as a duplicate of this bug. ***
Comment 2 Peter Larsen 2013-02-07 21:25:26 EST
Please refer to https://bugzilla.redhat.com/show_bug.cgi?id=892269#c17 for additional information about installer space management issues.
Comment 3 Fedora End Of Life 2013-04-03 09:41:02 EDT
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:
Comment 4 Adam Williamson 2013-05-12 19:42:14 EDT
This appears to be fixed in 19 Beta TC4. Closing.

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