Description of problem: Hard drive has NTFS on one partition, the other half is free. INSTALL DESTINATION screen says 85.38GB free. When "Done" is selected a dialog pops up saying "0 B Free space available for use." and "0 B Free space available but reclaimable from existing partitions." Clicking on "Reclaim Space" gives a dialog indicating "free space 85.38 GB" but is is in italics and when selected the "Reclaim space" button does not become active. The only option is to "Cancel" out of the reclaim space dialog. Selecting "Custom partitioning" gives the MANUAL PARTITIONING screen. Clicking on "Click here to create them automatically" gives a red "Automatic partitioning failed. Click for details." Clicking on it gives the pop-up "you have not created a bootloader stage1 target device sda3 must have one of the following disklabel types: gpt." That may be a second problem. Version-Release number of selected component (if applicable): FC19-TC5 How reproducible: 100% Steps to Reproduce: 1. Try to install on a system with NTFS on half the hard drive and the other half free. Actual results: Stuck in Anaconda with it complaining about no free space and not allowing it to be reclaimed. Expected results: Install. Additional info: This may be the same as BZ 947129.
Created attachment 765293 [details] anaconda.log
Created attachment 765294 [details] storage.log
Created attachment 765295 [details] syslog
You can't do a UEFI install to an msdos labelled disk. name = sda status = True kids = 0 id = 0 parents = [] uuid = None size = 171705.023438 format = existing msdos disklabel If you want to dual-boot with what appears to be a BIOS Windows install, you will have to do a BIOS Fedora install. If you want a UEFI Windows install, you will lose your BIOS Windows install. I believe this is NOTABUG.
bcl: can we perhaps provide more useful error info in this case?
This is a UEFI Windows install, the same one from BZ 975970. NTFS on half of the hard drive, trying to install linux on the other half. The difference is I used parted (from linux rescue disk) to delete the linux partitions (from the earlier install attempts). The NTFS partition was untouched. The earlier install attempts seemed happy with the hard drive. It was only after using parted to delete the leftover linux partitions that Anaconda got confused. It should be a valid configuration, as far as I can tell.
The disk is very clearly msdos labelled. I don't see any indication that anaconda is 'confused'. Are you sure you didn't do anything else with parted?
Anaconda is confused in that the INSTALL DESTINATION screen says 85.38GB free (the correct size of the non-NTFS part of the hard drive) but the dialog pop up says "0 B Free space available for use." so Anaconda will not install. I am missing the significance of a msdos labelled disk. As far as I can tell that is the way the hard drive came from Corp IS, with Windows & UEFI enabled.
"Anaconda is confused in that the INSTALL DESTINATION screen says 85.38GB free (the correct size of the non-NTFS part of the hard drive) but the dialog pop up says "0 B Free space available for use."" I think that's basically a consequence of this gpt/msdos labelling issue. anaconda at present works on the belief that a UEFI native install (at least the EFI system partition) must be on a GPT-labelled disk. mjg59 has just this morning told us that is not actually the case according to the UEFI spec (though dlehman and myself are extremely sceptical that all UEFI firmwares will actually *work* with an ESP on an msdos-labelled disk)...but for F19 certainly, that's not going to change, it'd be far too big a change to try and do at this point. We'll probably take another look at how to handle this situation for F20. You might want to follow https://bugzilla.redhat.com/show_bug.cgi?id=978430 .
If Anaconda does not support UEFI & msdos hard drive, could a pop up warning be added saying something along the lines of "WARNING: Fedora does not support UEFI & msdos labelled hard drives. Either re-format your entire hard drive or install a different linux disto." That will save everyone a lot of time and frustration. Fortunately SuSE installs, runs, and dual-boots just fine.
Yes, that is what the bug I linked to is about. But we can't change that at this point.
And, er, you missed the obvious third option: do a BIOS-mode install of Fedora. (Frankly, I'm so annoyed with UEFI ATM I'd bloody well recommend everyone use BIOS compatibility for everything...)
oh, wait, no, that probably wouldn't work too well with a UEFI-on-msdos install of Windows. Sigh. I hate firmware.
It's too late for Anaconda to warn users before they waste a bunch of time? Really? If Anaconda only supports GPT-labelled disk on UEFI, that needs to be added to the Fedora documentation. FWIW, the UEFI spec says that GPT must be supported, but does not say it is the only disk type supported. That systems ship with Windows (UEFI + msdos format) means that bios supports it. From the UEFI spec: 5.2.1 Legacy Master Boot Record (MBR) A legacy master boot record may be located at LBA 0 (i.e. the first block) of the hard disk if it is not using the GPT partition scheme.
"It's too late for Anaconda to warn users before they waste a bunch of time? Really?" Yes. We have an RC build which has passed validation testing, and the go/no-go meeting is tomorrow.
"5.2.1 Legacy Master Boot Record (MBR) A legacy master boot record may be located at LBA 0 (i.e. the first block) of the hard disk if it is not using the GPT partition scheme." That's not relevant to this. The presence of an actual Master Boot Record is a different issue from whether a disk is gpt-labelled or msdos-labelled (which is why I prefer those terms to just 'gpt' vs 'mbr').
Yeah, sorry about this. We didn't start seeing these kinds of problems until very recently. I wasn't aware that msdos labeled disks were being used for UEFI systems.
*** This bug has been marked as a duplicate of bug 978430 ***
*** Bug 947129 has been marked as a duplicate of this bug. ***