Created attachment 835240 [details] bug demonstration video Description of problem: This is a fork of bug 1027947. Several bugs have been identified in it, this is one of them. It's not possible to select an existing standard partition and enlarge it, even though there is free space available. It can only be downsized. Version-Release number of selected component (if applicable): anaconda 20.25.14 How reproducible: seems always Steps to Reproduce: 1. create a default LVM installation with / (or swap) smaller a bit, so that there is some free space 2. boot into installer again, go to custom partitioning 3. select an existing standard partition (e.g. /boot) try to increase its size. Can't be done. 4. try to shrink it. That can be done. Additional notes: Also see attachment 834296 [details] for additional demonstration of this bug, just reverse. In that case I could enlarge the standard partition, but not shrink it. Huh?
Created attachment 835241 [details] anaconda.log
Created attachment 835242 [details] program.log
Created attachment 835243 [details] storage.log
Created attachment 835244 [details] syslog
Proposing a Final blocker: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation. " https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Storage_volume_resize
Does it have free space right after /boot in such case? If not it needs to relocate PV partition which is not supported, I guess.
Discussed in 2013-12-11 Blocker Review Meeting [1]. Voted as an RejectedBlocker. This is probably a UI issue failing to inform the user properly what can and what cannot be achieved. It's not possible to redesign UI to fix this in a short time. If this really affects real cases where there is enough contiguous space for resize, please propose again. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-11/
Confirming the assessment of comment 7: /boot cannot be enlarged because there's nowhere to enlarge it into: the pv starts on the next sector. anaconda will not move existing partitions.
How is the user supposed to know that something starts on the next sector, when you don't offer any graphical layout representation? On the one hand, you try to offer a dumbed-down partitioning editor for users with no advanced knowledge in this area, but on the other hand in certain cases you simply reject an operation based on something the users couldn't have possibly known, even if they were partitioning gurus, because you decide to not provide this information in the first place. This is not a NOTABUG. This is a bug, a design flaw, just different from the original description.