Bug 1165781

Created attachment 959074 [details]
desktop screenshot after reaching "GNOME"

Created attachment 959075 [details]
anaconda.log

Created attachment 959076 [details]
packaging.log

Created attachment 959077 [details]
program.log

Created attachment 959078 [details]
storage.log

Created attachment 959079 [details]
system journal from installed system after reaching "GNOME"

Proposing as a Final blocker:
" A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility. "
https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Expected_installed_system_boot_behavior

This is a conditional breakage triggered by setting too small destination size (however, user is not warned about it, and also the guided partitioning approach doesn't even tell him how large the root partition is going to be, so it's not even possible for him to take this into account). As for the criterion wording, gnome-initial-setup is started in this case, but it doesn't finish correctly (it's restarted) and it's also not possible to log in to a working desktop afterwards.

-1 for me, this is just too much of a corner case, and not new. The installer isn't meant to provide 100% foolproof minima and maxima for things like this, it makes a reasonable effort; it knows the amount of disk space needed for the package set specified, plus a fairly arbitrary fuzz (like 500MB or smth).

Trying to decide how much extra space is enough is not really something Anaconda can do reliably. Depending on how the user wants to use the system a tiny bit may be enough, but in other cases they may need more. The user really needs to take this into account when resizing things. This also depends on the filesystem you are using, btrfs and ext4 end up using different amounts of space for the same files and we have no good way to predict the exact amount before installation.

The following comments are not related to the blocker proposal, I'm just commenting on this issue in general.

> Trying to decide how much extra space is enough is not really something Anaconda can do reliably.

I understand there are vast differences between filesystems, like ext4 and btrfs. But it would be nice if anaconda could do a decent job at least for the "guided partitioning + default values" use case.
Let's say I know the installed size is 4 GB, 5% of that space is reserved to root, and the end user should get at least 500 MB of free space (this can be a hard-coded value in anaconda). Therefore (4 + 0.5) / 0.95 = 4.74 GB root partition is required. (Humm, filesystem metadata is not computed into this. I see, it's not that easy). It doesn't need to be totally reliable, just a small protection cushion again "disk space scrooges".

This would not be used be for custom partitioning, people using it probably know what they're doing, even though some warning dialog "possibly low on free space" would be nice even there.

> The user really needs to take this into account when resizing things.

That's the problem, anaconda does not show me any information about the target partition layout when using guided partitioning. So if I know I want to make Fedora partition quite small (but obviously not too small to have it completely broken right away), I have no way of doing that except for trial and error. There is no way to learn the automatically created partition sizes before starting the installation.

So, even if we put this into common bugs, it's tricky to provide a good advice. The root partition size will very much depend on swap partition size, which depends on their RAM size. So even if we tell them "make sure your root partition is at least 5 GB large", they can't check it, unless they use manual partitioning.

To be fair, I tested it a few times and anaconda seems to be pretty intelligent when the destination size is small, even if you have higher amount of RAM. On a machine with 4 GB of RAM and 5 GB of destination size, it allocated just 600 MB for swap and the rest for the root partition, which is a reasonable approach. But I have no idea how it behaves on a machine with 16 GB of RAM and 10 GB of destination size (think SSD). I guess I could look up the algorithm...

Discussed at 2014-11-24 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-24/f21-blocker-review.2014-11-24-17.01.log.txt . Rejected as a blocker: this doesn't clearly meet any criterion, isn't anything new, there isn't a particularly obvious perfect fix for it, doesn't seem to be very commonly encountered based on the info we have available, and it seems inappropriate to start tinkering with it late in a release cycle for no particular reason (given that it's been around for years and this isn't a report from a user who hit it casually, but from a QA person intentionally trying to break stuff).

*** Bug 1168845 has been marked as a duplicate of this bug. ***

While I agree with Brian that we can't (and shouldn't) make assumptions about how much free space to require on the disk, we can probably provide the user with the information needed for them to make better choices.

In order to get to the reclaim dialog, you've first got to go through an installation options dialog that says your software selections require (in my case) 1.1 GB for software and 2.63 GB for swap, and that you've got X amount of free space available.

I click reclaim.

Now in the reclaim dialog, I see that installation requires a total of 1.1 GB for data, and the knowledge about swap requirements has completely disappeared.  That is definitely a problem.

Once you choose to resize that big partition you initially made for testing this out, anaconda updates you on how much space you've selected to reclaim and continues to display the label about how much you need total.

At this point, what extra information would help you make a better decision?

Let's say you add the missing swap size requirement, so that the existing label will say something like this:
"Installation requires a minimum of XXX MB (YYY MB for system data, ZZZ MB for swap)."
(I added the grand total, and also used the word "minimum" to point out that it'd be preferred to make it larger).

When looking at the dialog, I think it would help a lot to display the total amount of free + scheduled to be freed space, so that the user doesn't have to count too many numbers in his head. Let's say I have 1550 MiB of free space, delete a 2.1 GiB partition and shrink a different partition by 1.75 GiB. Currently, I need to compute my final free space in my head, anaconda doesn't tell me. Which is quite inconvenient, I think. I would like to see a label that says:
"Total amount of available free space: 5400 MiB"
and would be updated after every action I perform in the reclaim dialog. I can then easily compare those two labels ("requires" label and "available" label) and see easily if I have exceeded the value and how much.

I'd also find helpful if anaconda visibly warned me if my reclaimed space was below the total required space. For example a label in read could appear before I reclaimed enough space:
"Your currently available free space is below the recommended minimum size."
and disappear once the user reclaimed enough.
Or maybe we could re-use the "requires" label, and color it in red until the available space exceeds that number, then turn it back into black?
Just ideas.

Does that help? I can create some mock-ups if my descriptions weren't clear.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The minimum space requirement check was completely reworked. Unfortunately I wasn't so quick to get this to Fedora 23 release (where is the space check slightly better than in f22 but not ideal) but it's already on master.

It should work properly in current release.

I will create new bug with the swap space warning message.