Bug 1143972 - Anaconda doesn't show correct amount of free space when using disk with mbr and three partitions already existings
Summary: Anaconda doesn't show correct amount of free space when using disk with mbr a...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-18 10:51 UTC by Petr Schindler
Modified: 2015-11-04 09:34 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-04-15 18:52:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
anaconda.log (13.22 KB, text/plain)
2014-09-18 10:51 UTC, Petr Schindler
no flags Details
program.log (42.14 KB, text/plain)
2014-09-18 10:51 UTC, Petr Schindler
no flags Details
storage.log (233.88 KB, text/plain)
2014-09-18 10:52 UTC, Petr Schindler
no flags Details

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?


Note You need to log in before you can comment on or make changes to this bug.