Bug 1132849

Summary:	Fedora 20 installer unable to use free space
Product:	[Fedora] Fedora	Reporter:	Sean A. Fulop <sfulop>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	20	CC:	anaconda-maint-list, g.kaviyarasu, jonathan, 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:	2014-09-08 18:45:13 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:

Description Sean A. Fulop 2014-08-22 07:48:48 UTC

Description of problem: On Dell Latitude E7440 with 256 GB SSD, partition table clearly shows sda1 and sda2 for Windows 7, leaving 40 GB unallocated. Running Anaconda from Fedora 20 Live media (on USB stick) shows the SSD, stating 40 GB of free space available.  When click "Done" for automatic partitioning, the next box states that there is 0 B either free or reclaimable.  Attempt to go through the manual partition process does not help, Anaconda still says that there is no space available for any Fedora partitions.


Version-Release number of selected component (if applicable): Fedora 20 Live


How reproducible:
See above description.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:
I would expect Anaconda to install Fedora 20 on the 40 GB of unallocated space and automatically create a dual-boot setup with Windows 7.

Additional info: The SSD has about 98000 empty blocks at the start, prior to the first partition.  I have no idea why.

Comment 1 Sean A. Fulop 2014-08-23 07:27:46 UTC

Some folks on Fedoraforum said more info is needed.  

Here is output of fdisk -l:

Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3756ab6d

Device Boot Start End Blocks Id System
/dev/sda1 * 98304 1634303 768000 7 HPFS/NTFS/exFAT
/dev/sda2 1634304 417857535 208111616 7 HPFS/NTFS/exFAT


And here is a more detailed account of Anaconda behavior:
when I click "Full disk summary and bootloader" it states the disk as sda and says Capacity 244 GB, 40.21 GB free.

when I clck "done" it then says there are 0 B free and 0 B reclaimable. If I click "Reclaim" then I get a sort of partition table that shows the sda1 and sda2 partitions as 'ntfs' and then 40 PB of free space that is grayed out. What does '40 PB' mean? Is this where the bug is located? It now also says that I could reclaim 36 GB from my main Windows partition if I want to shrink it -- this is exactly how much space is left there. But Anaconda just got through telling me there were 0 B reclaimable. It's starting to seem like there are a number of bugs here.

I tried using the Fedora 19 live media as well, got the same result.

Comment 2 David Shea 2014-08-28 18:01:15 UTC

Please post the log files from /tmp during the install to this bug, in particular storage.log. You can hit Ctrl+Alt+F2 in the installer to get to a console.

Comment 3 Sean A. Fulop 2014-08-28 19:18:02 UTC

I believe I know the solution now.  The Anaconda behavior results from booting the Live system on a USB stick in EFI mode, and then attempting to install on an MBR drive in "legacy" mode. I found out, by using the openSUSE installer, that this machine sets some kind of flag after UEFI boot-up which then forces Anaconda (and the openSUSE installer as well) to use only GPT partition tables thereafter. I successfully installed Fedora 20 by booting the Live USB in "Legacy" mode.
It would be helpful if Anaconda would report this type of situation, like with an error stating "unable to install on MBR disk because. . ."

Comment 4 David Shea 2014-09-08 18:45:13 UTC


*** This bug has been marked as a duplicate of bug 978430 ***