Description of problem: Here's a use case: * I'm either a basic or a slightly advanced user who wants to have a look at Fedora. * I have some other system installed on my PC already. * Because I want to have just a look, and potentially I'm limited on disk space, I want to reserve as little space as possible to Fedora. I know I won't work with the system long term, this is just about getting a bit familiar with Fedora desktop, or perhaps about testing hardware compatibility with Fedora. However, I've found out today that if I reserve only the minimum necessary space to Fedora installation as mandated by anaconda, the installed system does not boot into GNOME properly and can't be used. There's 0% of free disk space for the user (there is just some small disk space reserved for root). The installed system looks like this: # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1.4G 0 rom vda 252:0 0 10G 0 disk ├─vda1 252:1 0 5.2G 0 part ├─vda2 252:2 0 1M 0 part ├─vda3 252:3 0 500M 0 part /boot └─vda4 252:4 0 4.4G 0 part ├─fedora-swap 253:0 0 496M 0 lvm [SWAP] └─fedora-root 253:1 0 3.8G 0 lvm / (vda1 represents my original system, e.g. windows, and it was shrunk as little as possible just to fit Fedora beside it) # df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/fedora-root 3.8G 3.7G 0 100% / devtmpfs 721M 0 721M 0% /dev tmpfs 731M 8.0K 731M 1% /dev/shm tmpfs 731M 1.4M 730M 1% /run tmpfs 731M 0 731M 0% /sys/fs/cgroup tmpfs 731M 8.0K 731M 1% /tmp /dev/vda3 477M 105M 343M 24% /boot tmpfs 147M 4.0K 147M 1% /run/user/1000 tmpfs 147M 0 147M 0% /run/user/0 After first boot, gnome-initial-setup window appears. If you create your user and complete it, the screen refreshes and you see yet another gnome-initial-setup, but this time the reduced version (the user already exists). Mouse cursor becomes invisible. If you complete it again, you see just a black screen and a warning dialog that your root filesystem has 0 bytes of free disk space remaining. Mouse cursor is still invisible. Even if you dismiss the dialog, only black screen remains, there is no desktop background, no top bar, nothing. The only thing you can do is to switch to console and log in as root (provided you set a password for it). In order to fix this, I assume anaconda needs to account for some minimum free space on the root partition, when computing the minimum required partition size (maybe only if /home is not present). Version-Release number of selected component (if applicable): F21 TC2 Workstation x86_64, with these packages updated: anaconda-21.48.15-1.fc21.x86_64 python-blivet-0.61.10-1.fc21.noarch How reproducible: always Steps to Reproduce: 1. on your disk, create a single large partition. There shouldn't be enough free space for a Fedora installation. 2. in the reclaim dialog in guided partitioning, shrink the existing partition, but only as little as possible. However, be aware of bug 1165733 - you'll need to select a value that not only satisfied the reclaim dialog, but also the main hub size check. 3. perform installation. create a root password, don't create a user (in principle you can, but this way you'll reproduce my steps exactly) 4. boot the new system 5. finish gnome-initial-setup(s), see that GNOME doesn't work, just a black screen 6. log in as root to VT, verify that / utilization is 100%. Actual results: A minimal (as in size) installation of Fedora Workstation doesn't boot into working GNOME. Expected results: A minimal (as in size) installation of Fedora Workstation boots into working GNOME.
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.