Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: If anaconda finds a disk that has a whole-device file system, it will be unable to handle the situation. For example, i created an ETX4 file system on /dev/vdb. Please remember that while in this case i created such file system for testing purposes, there is no guarantee that anaconda will not find one of these in the future (for reasons unknown, error, mistake, ignorance, others, for part of the user, these things will exists). Anaconda will be unable to perform AUTOMATIC PARTITIONING on the device, also performing MANUAL PARTITIONING will also not work. When selecting vdb (in this case), STORAGE: INSTALLATION DESTINATION will claim that there is not enough free space to install fedora. The space must be reclaimed. But vdb is seen by AUTOMATIC PARTITIONING as having one "0 B Total" 'reclaimable space' and there is NO ACTION possible. For anaconda, the disk is 100% UNUSABLE. It cannot even WIPE the disk, which is UNPARTITIONED! Anaconda cannot create a disk label over a file system (which in this case is necessary). Selecting MANUAL PARTITIONING for vdb shows the disk as having no partitions (which is correct), but the "click here to create them automatically" fails with "no disks selected" (which is NOT TRUE). Manually creating a /boot (512mb) swap (512mb) and /5gb is not possible, anaconda fails with "KeyError: '/dev/vdb'", i did not use ABRT nor reported this specific case. Also anaconda does not print any error that might help the user to solve the issue. Even an "Please do X, Y, Z and launch anaconda again. Bye!". Version-Release number of selected component (if applicable): F18b TC6 How reproducible: always Steps to Reproduce: 0. create an EXT4 file system on (for example) /dev/vdb. (/dev/vda has free space). 1. Enter STORAGE: INSTALLATION DESTINATION and select /dev/vdb 2. Do as above. (I tried with default boot parameters and with gpt boot parameter, just in case). Actual results: vdb disks ins UNUSABLE by anaconda. The UI behavior does not help the user to diagnose why it is happening. Expected results: Either anaconda let the user wipe the disks or at least an specific error, so the user can perform some actions manually. Additional info: I tried selecting both disks and anaconda installed 'ok' on the first one and did not touch the second one (vdb). But i am not 100% sure what will happen in all cases (for example a whole-device usb drive and/or combined with multiple disks).
Created attachment 633934 [details] Reclaim Space
Created attachment 633935 [details] Reclaim Space, no options
Created attachment 633936 [details] manual partitioning screen, no partitions
Created attachment 633941 [details] storage.log
I tried with F17 and it also could not handle the scenario, but the result was better. Unlike F18, i was able to install at least by 'use all space' and choosing vdb device. I did not experiment with other install methods with F17 yet. So this was not a regression, the problem was present in previous releases.
The proper workaround for F17 is to select 'use all space' and let the option to review the proposed partitions. With that you can delete and create whatever you want. (the bad entry still exists, but you operate on the other entries, and you will have a separate 'free' entry to work). In F18 this is not possible.
This will be fixed in anaconda-18.28-1. You will be able to clear the disk in reclaim (which will create a new disklabel on it) or edit it in custom partitioning. If you select it in custom and hit the '-' button the disk will get a new disklabel. You can alternatively set a mountpoint for the existing filesystem or reformat it with another filesystem. Let me know how it goes.
anaconda-18.28-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2012-17823/anaconda-18.28-1.fc18
Package anaconda-18.28-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.28-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17823/anaconda-18.28-1.fc18 then log in and leave karma (feedback).
This bug looks to have been fixed since 18.28 but missed being closed. If you find you are still experiencing it with Fedora 18 Beta (RC1) or later, please re-open the bug.