Bug 1137579

Summary:	Anaconda's custom partitioning GUI size parsing logic makes it impossible to easily set a partition size to the maximum available space
Product:	[Fedora] Fedora	Reporter:	Jean-François Fortin Tam <nekohayo>
Component:	anaconda	Assignee:	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:	20	CC:	anaconda-maint-list, dshea, g.kaviyarasu, jonathan, nekohayo, 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-15 20:57:36 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 Jean-François Fortin Tam 2014-09-04 03:11:46 UTC

My #1 beef with Anaconda is that I never manage to get it to "do what I mean" when it comes to partition sizes.

Depending on the order in which I delete/create partition, I pretty much always end up with the situation where I have one "/" partition with a set size (let's say 15 GB), and 200+ GB of free unpartitioned space; then I click "+" to create a new partition. A dialog appears: I set "/home" as the mountpoint, and for "Desired capacity:" I set it to either:
- "9999 GB" (or whatever amount bigger than the total available space)
- "" (leaving the text entry blank)
- the exact amount of free space (in this case: "223.47 GB")
- "*"
- "max"
- "3459385723958743534207534535"

...in all those cases it totally ignores whatever I tell it. My latest round of testing has been in RHEL/Centos 7's installer, but AFAIK it's been doing that in every iteration of the new Anaconda installer in Fedora (including F20) that I know of.

If I input "224" as the desired capacity string, it interprets it as 224 MB instead of 224 GB. But if I type in "200000" (200 000 MB; the disk has supposedly "223.47 GB of free unpartitioned space"), I get "58.38 GB". WAT...

For some reason, It always sets the partition size to exactly 58.38 GB whenever it fails to understand what I meant, which somehow happens every time.

This not only affects the partition creation modal dialog, it also affects trying to edit an existing partition.

Please make the parsing logic work in all the usecases above, or give me a slider widget, or give me a freakin' size units combobox. I'm really sad of having to concede defeat everytime and to have to use gparted to pre-partition the whole disk before using Anaconda. Anaconda can do better, I know it.

Comment 1 David Shea 2014-09-04 13:47:31 UTC

Please attach the log files from /tmp in the the installation environment to this bug, in particular storage.log

Comment 2 Jean-François Fortin Tam 2014-09-04 14:22:40 UTC

Can you not reproduce this issue on your end? I thought it was very common.

The Centos7 system I have been installing on yesterday has been installed.
Asking me to redo it would imply me getting another system just for the sake of messing up its partitioning and redoing the process, which is an expensive operation. You folks are probably better equipped to do this?

Comment 3 David Shea 2014-09-04 14:43:49 UTC

(In reply to Jean-François Fortin Tam from comment #2)
> Can you not reproduce this issue on your end?

We are not going to do that.

The default behavior when no size is specified or a too-large size is specified is to allocate the largest amount of space possible. If this is happening, the something else is in the way. Maybe you are create a logical volume in a volume group that only has ~58GB free? Maybe your partitioning table is fragmented and 58G is the size of the first free block? Maybe there is a bug in anaconda in the way that we are interpreting your particular storage situation? I do not know. I can't read your mind. That's why I asked for logs.

The log files are copied to the installed system in /var/log/anaconda.

Comment 4 Jean-François Fortin Tam 2014-09-04 15:00:22 UTC

Well, the system's drive originally had partitions roughly like this (if I'd known, I should've taken a screenshot): 2 NTFS partitions (Windows 7 + recovery), and an extended logical partition for Fedora (/, /home, swap).

In Anaconda's custom partitioner, what I attempted was to delete all partitions - there was nothing left in the list - and then create two new ext4 partitions, / and /home. /home is the one I was never able to set the size for. If that changes anything, I specifically told Anaconda to not use LVM, only standard partitions.

The problem is that since then, I rebooted, nuked the partitions using the gnome disk utility, created the two / and /home partitions, and *then* reran anaconda to install by mapping to those partitions. So the logs on the installed system are not going to be helpful, I'm afraid.

I can maybe try recreating all that crazy "NTFS + ext4 partitioning" in a virtual machine, and then try to reproduce the issue, but this is going to require inordinate amounts of time and energy. I'm not on anyone's payroll to do that, it might take quite a long while before I get to that.

Comment 5 David Lehman 2014-09-16 15:19:11 UTC

All of the methods you listed except for "max" and "*" are known to work well. Thousands of people are using this functionality. Something specific to your disk layout caused the unexpected behavior but, since you didn't provide logs, we'll probably never know what it was.