Description of problem: After creating mount points, approximately 4MB free space remains. Installer will not create a 500MB /boot mount point, and also doesn't provide an error message or any feedback to the user. Version-Release number of selected component (if applicable): anaconda 19.24-1 How reproducible: Always Steps to Reproduce: 1. Choose multiple disks as targets. 3. Manual partitioning, create two mount points, / and /home that consume all space on the selected drives. 3. Try to create /boot 500MB. Actual results: Nothing happens. No error message. Expected results: Either a banner should appear telling the user there isn't enough space. Or the fact the Size policy is Automatic by default, the installer should steal the needed space from one of the mount points. Additional info:
Created attachment 743664 [details] anaconda.log
Created attachment 743665 [details] program.log
Created attachment 743666 [details] storage.state
Created attachment 743667 [details] storage.log
Odd. I've tried to reproduce this but I get the error in the info bar every time.
Description steps to reproduce lack sufficient details. New steps to reproduce with beta TC4 / anaconda 19.25-1 1. Choose 4 1TB disks as targets. 2. Installation Options, change partition scheme to Btrfs, and select review/modify. 3. Manual partitioning, create a new / mount point with size 100gb; create new /home mount point with size blank. 4. Create new /boot mount point with size 500MB. Nothing happens at step 4, mount point not created, no error message.
OK so even easier to reproduce, with just two disks, still with Installation Options > Partition Scheme pop-up set to Btrfs: Manual partitioning > create new / mount point with size blank; create new /boot mount point with size 500mb.
Also reproducible with just one disk. So it's likely a Partition Scheme set to Btrfs thing, where /boot gets an exception to being created Btrfs, is ext4 instead but doesn't trigger out of space as if it were a Btrfs subvolume. Or something like that.
Choosing BTRFS as the default scheme was what I was missing. I'm testing a patch now.
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.