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 - FC19-TC5 cannot reclaim free space from empty partition
Summary: FC19-TC5 cannot reclaim free space from empty partition
Keywords:
Status: CLOSED DUPLICATE of bug 978430
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 947129 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-25 21:59 UTC by Russ Anderson
Modified: 2013-08-28 17:38 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-27 00:05:31 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
anaconda.log (deleted)
2013-06-25 22:04 UTC, Russ Anderson 		no flags Details
storage.log (deleted)
2013-06-25 22:04 UTC, Russ Anderson 		no flags Details
syslog (deleted)
2013-06-25 22:05 UTC, Russ Anderson 		no flags Details
View All

Description Russ Anderson 2013-06-25 21:59:47 UTC 
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.
Comment 1 Russ Anderson 2013-06-25 22:04:00 UTC 
Created attachment 765293 [details]
anaconda.log
Comment 2 Russ Anderson 2013-06-25 22:04:45 UTC 
Created attachment 765294 [details]
storage.log
Comment 3 Russ Anderson 2013-06-25 22:05:18 UTC 
Created attachment 765295 [details]
syslog
Comment 4 Adam Williamson 2013-06-26 05:20:17 UTC 
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.
Comment 5 Adam Williamson 2013-06-26 05:21:19 UTC 
bcl: can we perhaps provide more useful error info in this case?
Comment 6 Russ Anderson 2013-06-26 15:43:30 UTC 
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.
Comment 7 Adam Williamson 2013-06-26 15:53:13 UTC 
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?
Comment 8 Russ Anderson 2013-06-26 17:09:44 UTC 
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.
Comment 9 Adam Williamson 2013-06-26 18:03:21 UTC 
"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 .
Comment 10 Russ Anderson 2013-06-26 18:36:03 UTC 
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.
Comment 11 Adam Williamson 2013-06-26 19:24:02 UTC 
Yes, that is what the bug I linked to is about. But we can't change that at this point.
Comment 12 Adam Williamson 2013-06-26 19:24:46 UTC 
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...)
Comment 13 Adam Williamson 2013-06-26 19:25:21 UTC 
oh, wait, no, that probably wouldn't work too well with a UEFI-on-msdos install of Windows. Sigh. I hate firmware.
Comment 14 Russ Anderson 2013-06-26 19:43:00 UTC 
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.
Comment 15 Adam Williamson 2013-06-26 19:53:16 UTC 
"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.
Comment 16 Adam Williamson 2013-06-26 19:54:37 UTC 
"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').
Comment 17 Brian Lane 2013-06-27 00:02:38 UTC 
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.
Comment 18 Brian Lane 2013-06-27 00:05:31 UTC 

*** This bug has been marked as a duplicate of bug 978430 ***
Comment 19 David Shea 2013-08-28 17:38:21 UTC 
*** Bug 947129 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.