Description of problem: In Manual Partitioning, with four disks chosen, Standard Partition selected, I can't choose which disk any mount point appears on. Version-Release number of selected component (if applicable): anaconda 19.24-1 How reproducible: Always Steps to Reproduce: 1. Choose four disks (possibly fewer, I haven't tested) 2. Get to Manual Partitioning. 3. Create a root mount point, Standard Partition, ext4. 4. The Name field says /dev/sdb1 but I don't want it on that disk, so I click the "hardware select" button and choose the drive I want it on and click OK. Actual results: Name still says /dev/sdb1. The Apply button is grayed out. Expected results: I expect to be able to choose the device I want the mountpoint on. Additional info:
Created attachment 744299 [details] anaconda.log
Created attachment 744300 [details] program.log
Created attachment 744301 [details] storage.log
Created attachment 744302 [details] storage.state
Proposing as beta blocker: "When using the custom partitioning flow, the installer must be able to Assign mount points to existing storage volumes."
That's not what that criterion means. It means you should be able to say 'use this existing partition as /home' or whatever. The term "storage volumes" is used in preference to "partitions" because an LV or btrfs subvol is not really a partition.
OK fine but I should still be able to choose which disk a particular mount point appears on, that's the whole point of the button and dialog that lets me make this choice. Yet it doesn't do what it suggests it should do.
Sure, it's clearly a bug, it's just not a blocker under that criterion at least.
> Name still says /dev/sdb1. The Apply button is grayed out. Yep, i "touch" the label field to workaround the grayed out 'update settings' button. I do agree that it should not be grayed out. The button 'restrict mount point to certain storage devices' (as i call it, i really don't know its name, and the used icon does not help) does generally works ok. There is an issue there, but since i have not yet reproduced it i could not open a bug-report. I will put an example that works, but also suffers of the grayed out issue. I also do not believe that it should block beta, it surely must block release. ~~ WORKING EXAMPLE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0. Reach the Main Hub, leave deaults at the Welcome Screen. (Or set english for F19b TC3 if it is not default). 1. Leave defaults at all spokes, wait and got to Storage: Installation Destination 2. Select the six disks (vda,vdb,vdc,vdd,vde,vdf). The KVM Guest is new, so these disks are untouched without any data. 3. In Installation Options, seledt 'I want to review/modify my disk partitions before contining.' and set the Partition Scheme to 'standard partition' 4. Reach Manual Partitioning, it should be empty. I want to create this: SWAP (vda,vdb) 768mb RAID (MDADM RAID1) /boot (vda,vdb) 512mb RAID (MDADM RAID1) / (vda,vdb) Whatever is free on vda and vdb RAID (MDADM RAID1) Other mount points will use the other disks, so they must not be used for /. 5. Clicl '+' to add a mount point, type swap and set it to 768 and click Add mount point. 6. Make sure that 'swap' item is selected (it should) and change its device type to RAID, by default it is set as RAID1 so do an 'update settings'. 7. Add a label 'swap-fs' and do another 'update settings'. 8. Click the icon that leads to the 'configure mount point' dialog, restrict swap to the first two disks. (click and ctrl+click the second, i can identify them by the S/N i set in virt-manager, but it should display the devices vda,vdb too). Click select. 9. Clicl '+' to add a mount point, type /boot and set it to 512 and click Add mount point. 10. Make sure that 'swap' item is selected (it should) and change its device type to RAID, by default it is set as RAID1 so do an 'update settings'. 11. Add a label 'boot-fs' and do another 'update settings'. 12. Click on /boot entry and then click the icon that leads to the 'configure mount point' dialog, restrict /boot to the first two disks. (click and ctrl+click the second, i can identify them by the S/N i set in virt-manager, but it should display the devices vda,vdb too). Click select. 13. In this case, 'update settings' is grayed out, touch the label field, then click 'update settings' hoping that /boot has been restricted to vda and vdb. Up to this point, all seems ok. Now i will try to create the / on the remaining space of vda and vdb using MDADM RAID1. 14. Clicl '+' to add a mount point, type / and leave it blank, anaconda will use all space. 15. Make sure that '/' item is selected (it should) and change its device type to RAID, by default it is set as RAID1 so do an 'update settings'. 16. Add a label 'root-fs' and do another 'update settings'. Now it comes the problem, i have to relly on anacondas way of assingning all free space for whatever space there is. By restricting the mount point to certain disks (vda,vdb which does still have free space). 17. Click on /boot entry and then click the icon that leads to the 'configure mount point' dialog, restrict /boot to the first two disks. (click and ctrl+click the second, i can identify them by the S/N i set in virt-manager, but it should display the devices vda,vdb too). Click select. 18. In this case, 'update settings' is grayed out, touch the label field, then click 'update settings' hoping that /boot has been restricted to vda and vdb. It was.
Clarification: 10. Make sure that 'swap' (it is really /boot, it was a typo).
So, I tested this out in a much simpler case. I can't really interpret Reartes' complex test, sorry, but here are my findings. Start with a VM with two disks. In custom partitioning, wipe anything existing, and create a simple layout: /boot , swap, / , ensuring that the partitions could fit on either disk alone. Now just play with assigning each partition to a given disk. The actual bug here so far as I can make out is simply that the display of the partition information on the right hand side is not updated immediately after you assign a partition to a disk. But the function does work. So say /boot starts out as 'vda1', and I hit the 'tools' button and say it can only be on vdb. When I confirm that selection, at first, the Name: field still says vda1, and the Update Settings button is greyed out. As Reartes found, you can 'touch' the Label field and hit Update Settings and it'll change to vdb1. You can also simply click on a different partition and then back to /boot , and it'll now show as vdb1. I'm pretty sure that the assignment is working fine behind the scenes, and this is just a visual bug - the Name field should be updated immediately after the action, but it isn't. But the actual function is working fine, and the 'workaround' should be pretty much automatic, people usually click here and there in custom part.
Discussed at 2013-05-08 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-08/f19beta-blocker-review-4.2013-05-08-16.00.log.txt . Rejected as a blocker but accepted as a freeze exception issue: the function does actually work, but the visual response is very confusing. This might be considered a Final blocker if it's not fixed before then, re-proposing.
This is working as designed. No changes are applied until you hit the -- you guessed it -- "Apply changes" button (or you switch to a different mountpoint/selector).
(In reply to comment #13) > This is working as designed. No changes are applied until you hit the -- you > guessed it -- "Apply changes" button (or you switch to a different > mountpoint/selector). As stated in the description: **Actual results: Name still says /dev/sdb1. The Apply button is grayed out.** The Apply Changes button is unavailable. I just retested this with beta TC4 / anaconda 19.25-1 and two disks, and the problem is still reproducible except the grayed out button is labeled "Update Settings".
Yep, same as Chris. The description did clearly state that, and so did my comment #11. Re-opening.
And, as this change occurs in a separate screen I don't see any reason to require the 'Update Settings' button to be pressed to 'apply' the changes. The only reason that button exists, as I understand it, is that we can't safely 'live apply' changes made on the custom partitioning screen itself in all cases, but this problem does not seem to apply to the Configure Mount Point dialog. I can see no logical reason that changes made on that dialog shouldn't be applied as soon as the user clicks 'Select'; you know that their action is complete at that point.
I checked how F18 behaves: it behaves as dlehman expected it to in c#13, the changes aren't instantly applied, but the "Apply Changes" (as it was called then) button is active and clickable and causes the change to be applied. I still don't see why we can't simply apply changes from the dialog instantly, but eh.
We decided to queue the changes until the user applies them. The "Apply changes" button not getting updated is a bug. I'll update this one to track that.
anaconda-19.27-1.fc19, pykickstart-1.99.31-1.fc19, python-blivet-0.14-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/python-blivet-0.14-1.fc19,pykickstart-1.99.31-1.fc19,anaconda-19.27-1.fc19
Package anaconda-19.27-1.fc19, pykickstart-1.99.31-1.fc19, python-blivet-0.14-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-19.27-1.fc19 pykickstart-1.99.31-1.fc19 python-blivet-0.14-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-8322/python-blivet-0.14-1.fc19,pykickstart-1.99.31-1.fc19,anaconda-19.27-1.fc19 then log in and leave karma (feedback).
Package pykickstart-1.99.31-1.fc19, anaconda-19.28-1.fc19, python-blivet-0.14-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing pykickstart-1.99.31-1.fc19 anaconda-19.28-1.fc19 python-blivet-0.14-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-8322/python-blivet-0.14-1.fc19,pykickstart-1.99.31-1.fc19,anaconda-19.28-1.fc19 then log in and leave karma (feedback).
pykickstart-1.99.31-1.fc19, anaconda-19.28-1.fc19, python-blivet-0.14-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.