Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 978065
| Summary: | FC19-TC5 cannot reclaim free space from empty partition | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Russ Anderson <rja> | ||||||||
| Component: | anaconda | Assignee: | Brian Lane <bcl> | ||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 19 | CC: | anaconda-maint-list, awilliam, davidwriter, dshea, g.kaviyarasu, jonathan, mkolman, sbueno, vanmeeuwen+fedora | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2013-06-27 00:05:31 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Russ Anderson
2013-06-25 21:59:47 UTC
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. *** |