Description of problem: User chooses a single drive with much of the space used, gets to Reclaim Disk Space and decides to cancel, returning back to disk selection and adding an additional drive. The installer recognizes the new selection, but will not use any space from it, e.g. for /home. Version-Release number of selected component (if applicable): anaconda 19.25-1 How reproducible: Only when initially selecting one disk, then subsequently selecting additional disks. It's necessary to restart the installer to use the additionally selected drive. Steps to Reproduce: 1. 4 disks, three not partitioned, one partitioned and mostly used with one file system. 2. Installation Destination: Choose the partitioned disk, click Done. 3. Reclaim Disk Space says there isn't enough space, click Custom partitioning. 4. Delete existing partitions. 5. Click Autopartition link. 6. Click Done. 7. Click Installation Destination. 8. Add one or more disks, click Done. 9. Installation Options, choose review/modify to go back to custom partitioning. 10. In Manual partitioning, click on /home and change its size to be larger, click Update Settings. Actual results: Nothing happens, /home size remains the same. Installer says in my case there's 3TB of available space, but I can't increase the size of /home. Expected results: For /home size to be increase to the smaller of specified or available. Additional info:
Created attachment 746734 [details] anaconda.log
Created attachment 746735 [details] program.log
Created attachment 746736 [details] storage.log
Created attachment 746737 [details] storage.state
Proposing as beta blocker under beta criterion: "When using the custom partitioning flow, the installer must be able to Assign sizes to newly-created storage volumes and containers Could be related to bug 959725 or bug 959723.
-1 blocker. This is clearly a long way from the criterion cited.
Really. A long way? I'm trying to assign a size to a newly created volume using custom partitioning, yet the installer can't do it. It meets 90% of the criterion text. It can only be a "long way" if there's a pile of unwritten exceptions that give a pass for the installer having a major brain fart when the user does rather non-exotic things.
It says "the installer must be able to", not "must be able to in all circumstances whatsoever". To trigger this bug you have to introduce the complicating factor of a second disk that is added to the target set on a second attempt. This is a *beta*, remember; the point of a beta is to be tested. The goal of the beta criteria is to ensure that a reasonably complete set of installer functionality is in a testable state. We are not trying to ship a bug-free image.
Just my vote of course, and I'm not trying to be rude - I just don't want to get into the trap of setting the bar too high. When I wrote that criterion the kind of bug I was thinking of was "I tried to change the size of /boot and the installer crashed", or "the size dialog doesn't show up at all", you know? It's a list of basic custom partitioning functionality that is supposed to be in place and working in a 'normal' situation, it wasn't really written to be stretched to fit all sorts of different bugs.
Discussed at 2013-05-13 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-13/f19beta-blocker-review-5.2013-05-13-16.00.log.txt . Rejected as a blocker: we all agreed this doesn't really violate the criteria, as it only fails on one specific path and is easy enough to 'work around' by just selecting all the target disks the first time. Accepted as a freeze exception bug, however; clearly it'd be beneficial to get this fixed for the images.
Try modifying the volume's disk set to include the newly added disks.
If you meant the "configured selected mount point" button which reveals a dialog letting me choose what disk the device may reside on, it already shows all four disks highlighted in blue. Altering the disk selection makes no difference due to bug 960254 as the Update Settings button is grayed out.
You can also select a different mountpoint to apply the changes to the current mountpoint.
OK I finally figured this out and it's mostly user error so I'm closing as worksforme. In the tested version of anaconda, I was allowed to click on the hardware icon button (configure selected mountpoint) even though the mountpoint was an LV... but I can't reproduce this on beta TC4. What I needed to do before changing the LV size, is change the VG, which in the newui isn't as visually obvious what the relationship is between PV, VG, and LV. So as a user, I actually have to know I need to make the VG bigger before I can make the LV bigger. Once I go to to Modify and do what David said in c11, I get a VG specific listing of disks. Using shift-click, I can choose both disks, which adds them to the VG. I am then allowed to change the mount point (LV) size, which sticks when I click Update Settings.