Created attachment 1685952 [details] example kickstart file Description of problem: Partitioning with `autopart --nohome` leaves most of a (large) disk unallocated Version-Release number of selected component (if applicable): as shipped with Fedora-Everything-netinst-x86_64-32-1.6.iso How reproducible: Install using `autopart --nohome` on machine with large (e.g., 600GB) hard drive Steps to Reproduce: 1. create VM (e.g., in virt-manager) - use Fedora-Everything-netinst-x86_64-32-1.6.iso for ISO install media - choose 600GB for the size of the disk image 2. use attached kickstart file (which uses `autopart --nohome`) to install 3. when prompted to hit enter for reboot, send ctl-alt-f2 key combo for a shell 4. type `df -h` to view partition sizes Actual results: /dev/mapper/fedora-root 69G 2.4G 63G 4% /mnt/sysimage (root partition only uses 69G of the total 586G available) Expected results: /dev/mapper/fedora-root 586G 2.4G 554G 1% /mnt/sysimage (root partition utilizes the entire available disk space) Additional info: Expected results were obtained by manual partitioning: part /boot --fstype=ext4 --recommended part pv.0 --fstype=lvmpv --size=1 --grow volgroup fedora --pesize=4096 pv.0 logvol swap --fstype=swap --name=swap --vgname=fedora --recommended logvol / --fstype=ext4 --name=root --vgname=fedora --size=1 --grow However, this isn't always straightforward, as sometimes the hardware expects a `biosboot` partition, and sometimes adding it results in an error (or at least in the installer interactively soliciting a re-do of the partitioning). It would be best for `autopart` to do the intuitive thing and fill the disk with the root partition if `--nohome` is selected :)
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. 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 '32'. 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 32 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.
Still a problem in F34. Using "autopart --type=lvm --nohome" on a 120GB virtual disk, getting a root filesystem of size 69G, and lots of unused space.
IIRC the autopart behavior you describe seems similar to the partitioning that should be used for Fedora Server - some basic rootfs size and the remaining space left unassigned at installation time so that it can be allocated later (for additional LVs, container storage backing space, etc.). Maybe the Fedora Everything installation image defaults to the Fedora Server ? That would explain this behavior.
Are you saying that "--nohome" means "leave everything that *would* have been otherwise assigned to /home (i.e., the entire rest of the disk) simply unallocated" ? Feels a bit counterintuitive (but maybe that's just me). However, *definitely* feels like there should at least be an option (similar to "--grow" in a related context) to tell it to allocate the entire available disk to the root partition...
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. 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 '34'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 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.
NOTE: at the time I reported this bug, the default autopart scheme was "lvm". This changed to "btrfs" at some point before f36. With btrfs, it doesn't seem to be all that important as both "/" and "/home" share the same physical disk space, so if the latter goes unused, "/" could utilize the whole disk space if needed. What this bug is about in *today's* context is "autopart --type=lvm --nohome". But I haven't tested its behavior lately, and since I realized the new (btrfs) default "elastically" shares space between "/" and "/home", it's no longer all that important to me, personally. Thanks!
The default partitioning (used by autopart) is defined in the Anaconda configuration files, for example like this: default_partitioning = / (min 1 GiB, max 70 GiB) /home (min 500 MiB, free 50 GiB) It means that the size of the / partition can be at most 70 GiB, but the size of /home is unlimited. The --nohome option just skips the request for the /home partition without any other changes. It is the same as running autopart with the following definition: default_partitioning = / (min 1 GiB, max 70 GiB) Since the / partition has a limited size, it cannot grow more than that. Suggested fix: If we remove a request for a growable partition and there are no more growable partitions, set the max size of the / partition to unlimited. See the AutomaticPartitioningTask._get_partitioning method: https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/storage/partitioning/automatic/automatic_partitioning.py#L125
Hi, it looks like we cannot fix the issue without breaking backward compatibility: https://github.com/rhinstaller/anaconda/pull/4472#pullrequestreview-1218155437 This issue will be documented in our documentation: https://github.com/rhinstaller/anaconda/pull/4650 Closing as not a bug.