Bug 978065 - FC19-TC5 cannot reclaim free space from empty partition
FC19-TC5 cannot reclaim free space from empty partition
Status: CLOSED DUPLICATE of bug 978430
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
:
: 947129 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-25 17:59 EDT by Russ Anderson
Modified: 2013-08-28 13:38 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-26 20:05:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda.log (58.01 KB, text/plain)
2013-06-25 18:04 EDT, Russ Anderson
no flags Details
storage.log (174.03 KB, text/plain)
2013-06-25 18:04 EDT, Russ Anderson
no flags Details
syslog (132.79 KB, text/plain)
2013-06-25 18:05 EDT, Russ Anderson
no flags Details

  None (edit)
Description Russ Anderson 2013-06-25 17:59:47 EDT
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 18:04:00 EDT
Created attachment 765293 [details]
anaconda.log
Comment 2 Russ Anderson 2013-06-25 18:04:45 EDT
Created attachment 765294 [details]
storage.log
Comment 3 Russ Anderson 2013-06-25 18:05:18 EDT
Created attachment 765295 [details]
syslog
Comment 4 Adam Williamson 2013-06-26 01:20:17 EDT
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 01:21:19 EDT
bcl: can we perhaps provide more useful error info in this case?
Comment 6 Russ Anderson 2013-06-26 11:43:30 EDT
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 11:53:13 EDT
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 13:09:44 EDT
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 14:03:21 EDT
"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 14:36:03 EDT
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 15:24:02 EDT
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 15:24:46 EDT
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 15:25:21 EDT
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 15:43:00 EDT
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 15:53:16 EDT
"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 15:54:37 EDT
"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-26 20:02:38 EDT
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-26 20:05:31 EDT

*** This bug has been marked as a duplicate of bug 978430 ***
Comment 19 David Shea 2013-08-28 13:38:21 EDT
*** 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.