Bug 1143972

Summary: Anaconda doesn't show correct amount of free space when using disk with mbr and three partitions already existings
Product: [Fedora] Fedora Reporter: Petr Schindler <pschindl>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: anaconda-maint-list, awilliam, g.kaviyarasu, jonathan, kparal, pschindl, robatino, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-15 18:52:43 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 Flags
anaconda.log
none
program.log
none
storage.log none

Description Petr Schindler 2014-09-18 10:51:26 UTC
Created attachment 938837 [details]
anaconda.log

Description of problem:
I have disk with mbr on it and with following layout:

/dev/sda1: 500 MB /boot (ext4)
/dev/sda2: 8 GB swap
/dev/sda3: 47 GB / (ext4)
freespace: 25 GB

On the screen with disk selection anaconda shows that there is 25 GB of free space on the disk. But when I try to use this disk for installation anaconda complains about unsufficient space for installations and claims that there are 0 B of free space (and there is 25 GB of free space) so I have to reclaim some space. In Reclaim disk space window there it again shows 25 GB of free space at the end of the disk.

This is probably caused by limited number of partitions on mbr, but anaconda should handle it. It could create extended partitions. 

At least anaconda should show correct warning because it's not true that there isn't sufficent amount of free space (there surely is).

Version-Release number of selected component (if applicable):
anaconda-21.48.6-1
Fedora-Server-DVD-x86_64-RC1

How reproducible:
Always

Steps to Reproduce:
1. Use disk with mbr and 3 existing partitions and sufficent amount of free space on the end of the disk
2. Go to installation destination and choose this disk for installation

Actual results:
anaconda shows that there is 0 B of free space and wants reclaim some space

Expected results:
It should either handle limit of partitions on mbr or show correct message.

Additional info:
I propose this as beta blocker because it violates this criterion: "When using the guided partitioning flow, the installer must be able to:
    Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation"

Comment 1 Petr Schindler 2014-09-18 10:51:49 UTC
Created attachment 938839 [details]
program.log

Comment 2 Petr Schindler 2014-09-18 10:52:20 UTC
Created attachment 938840 [details]
storage.log

Comment 3 Kamil Páral 2014-09-24 18:06:55 UTC
Discussed in 2014-09-24 Blocker Review meeting [1]. Accepted as a blocker. This bug violates the beta guided partitioning criteria: "Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation."

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-09-24/

Comment 4 David Lehman 2014-10-03 16:57:19 UTC
How were you planning on booting from the mbr disk via EFI?

Comment 5 David Lehman 2014-10-03 17:08:39 UTC
If none of the selected disks have a disklabel that the platform can be expected to boot from we do not allow doing automatic partitioning without first clearing a disk.

Comment 6 Adam Williamson 2014-10-08 16:54:15 UTC
Discussed at 2014-10-08 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-08/f21-blocker-review.2014-10-08-15.58.log.txt . We agreed it would be good if anaconda indicated the situation more clearly in this case - I believe there are other UEFI-on-MBR paths which do give a clearer error, I may even have written one of them - but with the new understanding of the bug this no longer qualifies as a 'valid' installation scenario, so its blocker status is withdrawn. (We should maybe tweak the criterion to clarify that UEFI-on-MBR is not required to work).

David, is it possible to provide the user with a better understanding of the problem in this case?