Bug 2214329 - Size of 'growable' partitions not reconsidered when software selection changes or root account is enabled(?)
Summary: Size of 'growable' partitions not reconsidered when software selection change...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 42
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks: 2208181
TreeView+ depends on / blocked
 
Reported: 2023-06-12 16:19 UTC by Adam Williamson
Modified: 2025-02-26 12:53 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)
syslog log (3.88 MB, text/plain)
2023-06-12 16:21 UTC, Adam Williamson
no flags Details
storage.log (92.91 KB, text/plain)
2023-06-12 16:22 UTC, Adam Williamson
no flags Details
program.log (4.45 KB, text/plain)
2023-06-12 16:23 UTC, Adam Williamson
no flags Details
packaging.log (32.98 KB, text/plain)
2023-06-12 16:24 UTC, Adam Williamson
no flags Details
df.log (375 bytes, text/plain)
2023-06-12 16:25 UTC, Adam Williamson
no flags Details
dbus.log (3.69 KB, text/plain)
2023-06-12 16:25 UTC, Adam Williamson
no flags Details
anaconda.log (21.07 KB, text/plain)
2023-06-12 16:25 UTC, Adam Williamson
no flags Details

Description Adam Williamson 2023-06-12 16:19:31 UTC
This is fallout from the EFI system partition size change - https://bugzilla.redhat.com/show_bug.cgi?id=2208181 - in a sense, but I think the problem is actually more generic than that, and you could hit it with the old EFI system partition size definition if you were really careful/unlucky.

Since that Change came in, an openQA test is consistently failing:
https://openqa.fedoraproject.org/tests/1973152

That test boots the Everything netinst image (which defaults to the "Fedora custom OS" package set, i.e. minimal), then changes the package set to Workstation, then runs through the Installation Destination (partitioning) spoke selecting automatic partitioning, then enables the root account and creates a user account.

Somewhere during that process, the install gets blocked because anaconda decides there isn't enough space available. The test uses a 13GB disk image. I can resolve the issue for openQA by just using a bigger disk image, of course, but it feels to me like there's a bug here.

It seems like the error isn't visible on the hub when we leave the Software Selection or Installation Destination spokes, and there's no warning or error shown on the Installation Destination spoke at any time when we're on it. But after we leave the Root Account spoke, *then* the error shows up.

From the logs it seems like anaconda sets the EFI system partition size to 2GiB - the largest possible size from the 600MiB to 2GiB range that it can be. It doesn't seem to consider reducing its size to solve the space deficit at any point.

To me, it seems like there's a couple of issues here: the lack of an error/warning when we are on the Installation Destination spoke (unless, somehow, enabling the root account makes the expected install size over 600MiB bigger or the projected available space over 600MiB smaller?), and the apparent failure of anaconda to consider reducing the size of the ESP to 'solve' the space shortage.

Reproducible: Always

Comment 1 Adam Williamson 2023-06-12 16:21:41 UTC
Created attachment 1970447 [details]
syslog log

Comment 2 Adam Williamson 2023-06-12 16:22:58 UTC
Created attachment 1970448 [details]
storage.log

Comment 3 Adam Williamson 2023-06-12 16:23:20 UTC
Created attachment 1970449 [details]
program.log

Comment 4 Adam Williamson 2023-06-12 16:24:41 UTC
Created attachment 1970450 [details]
packaging.log

Comment 5 Adam Williamson 2023-06-12 16:25:11 UTC
Created attachment 1970451 [details]
df.log

Comment 6 Adam Williamson 2023-06-12 16:25:34 UTC
Created attachment 1970452 [details]
dbus.log

Comment 7 Adam Williamson 2023-06-12 16:25:57 UTC
Created attachment 1970453 [details]
anaconda.log

Comment 8 Fedora Release Engineering 2023-08-16 08:10:58 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

Comment 9 Aoife Moloney 2024-11-08 10:53:43 UTC
This message is a reminder that Fedora Linux 39 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26.
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
'version' of '39'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 39 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 Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 10 Adam Williamson 2024-11-08 16:52:44 UTC
I worked around this in openQA by bumping the test's disk size to 14G. There's no indication anyone worked on the issues here, so bumping the bug to Rawhide.

Comment 11 Aoife Moloney 2025-02-26 12:53:46 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.


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