Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 1738830 [details] Screenshot of reproduction step 7 in a virtual machine Created attachment 1738830 [details] Screenshot of reproduction step 7 in a virtual machine Description of problem: When selecting Custom Partitioning in Anaconda, Fedora warns the user if they select a /boot partition smaller than 200MiB, and suggest to use a partition that's at least 200MiB. Version-Release number of selected component (if applicable): fc33 How reproducible: - In anaconda's custom partitioning screen Steps to Reproduce: 1. Boot up Fedora installation medium 2. Select partitioning 3. Select custom partitioning 4. Create /boot partition with a size smaller than 200MiB 5. Create the rest of your partitions 6. Click "Done" once 7. At the bottom, a bar says there are warnings about the partition scheme. Clicking the warning shows the attached screenshot's dialog box. Actual results: Fedora installs just fine with a 200MiB boot partition but kernel updates can't be applied, so Fedora does not work properly. Expected results: Fedora prevents installation with a /boot partition that's too small.
Created attachment 1738831 [details] Error message when trying to upgrade kernel after install
Is there a workaround for affected users that doesn't involve reinstalling or moving /boot?
Just as a data point: /dev/sda5 976M 300M 609M 34% /boot That's with: -rw-------. 1 root root 88843360 Nov 26 23:31 initramfs-0-rescue-b51b4a725db84fd286dcf4a790a50a1d.img -rw-------. 1 root root 34109245 Nov 23 23:04 initramfs-5.10.0-0.rc5.82.fc34.x86_64+debug.img -rw-------. 1 root root 34114573 Dec 4 19:19 initramfs-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64.img -rw-------. 1 root root 34118541 Dec 9 22:45 initramfs-5.10.0-0.rc7.93.fc34.x86_64+debug.img -rw-------. 1 root root 33930255 Nov 26 23:19 initramfs-5.9.11-200.fc33.x86_64.img drwxr-xr-x. 3 root root 4096 Aug 29 11:49 loader drwx------. 2 root root 16384 Aug 29 11:44 lost+found -rw-------. 1 root root 5888777 Nov 23 10:14 System.map-5.10.0-0.rc5.82.fc34.x86_64+debug -rw-------. 1 root root 5888935 Dec 4 07:11 System.map-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64 -rw-------. 1 root root 5885738 Dec 8 10:23 System.map-5.10.0-0.rc7.93.fc34.x86_64+debug -rw-------. 1 root root 5369812 Nov 24 11:31 System.map-5.9.11-200.fc33.x86_64 -rwxr-xr-x. 1 root root 10164336 Nov 26 23:30 vmlinuz-0-rescue-b51b4a725db84fd286dcf4a790a50a1d -rwxr-xr-x. 1 root root 11235152 Nov 23 10:14 vmlinuz-5.10.0-0.rc5.82.fc34.x86_64+debug -rwxr-xr-x. 1 root root 11406448 Dec 4 07:11 vmlinuz-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64 -rwxr-xr-x. 1 root root 11398480 Dec 8 10:23 vmlinuz-5.10.0-0.rc7.93.fc34.x86_64+debug -rwxr-xr-x. 1 root root 10164336 Nov 24 11:31 vmlinuz-5.9.11-200.fc33.x86_64 Fedora by default will have three nodebug kernels with hostonly initramfs, plus the non-version/machineid "rescue" pair with nohostonly initramfs. But I think it installs a fourth before it deletes the spare? If so, the above represents a minimum 300M needed. I wonder if there is a way to estimate the minimum size based on the install media's vmlinuz and initramfs? That way it wouldn't have to be hard coded and updated periodically.
(In reply to Julian Ospald from comment #2) > Is there a workaround for affected users that doesn't involve reinstalling > or moving /boot? Delete the two files containing "rescue" in their filename. That'll free up enough space to update the kernel. There might be some cosmetic errors when it fails to create new rescue files, due to the lack of space. Or alternatively create a new 1-2G partition and file system for /boot, don't forget to update fstab.
Related RHEL bug 1844423
I wonder what would be correct size these days...
I wonder about making it ratio instead of a fixed size? Some devices have little room to spare, with as little as 64G drives. Whereas 1T drives in a stock configuration are becoming more common at the high end. Also, Boot Loader Spec intends for the $BOOT device to be shared among the installed distributions. We could estimate that the likelihood of using kdump and multiboot is low in the 128G and less drive size, so keep $BOOT 1G for now. And then 1256M once the drive is 256G, 1512M for a 512G drive and 2G for a 1T drive?
There are actually two values for the /boot size to think of: a) The "too small" warning threshold. The original report is for this. This value is stored in config files [1][2] and appears to be everywhere the default 200 MiB, except for RHVH with 1 GiB, which is not too relevant here I think. b) The default size if not specified. I guess that's what you mean in comment 7? That seems to be 1 GiB for most platforms, so no change needed there. [3] I guess bumping the warning threshold to 512 MiB could be the safe choice while providing some buffer space. It's not like the warning must be addressed... [1] https://github.com/rhinstaller/anaconda/blob/master/data/anaconda.conf#L209 [2] https://github.com/rhinstaller/anaconda/tree/master/data/product.d [3] https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/storage/platform.py#L131
https://github.com/rhinstaller/anaconda/pull/3302
>b) The default size if not specified. I guess that's what you mean in comment 7? Yes. >I guess bumping the warning threshold to 512 MiB That seems reasonable.
Thanks! The idea about variable /boot size sounds useful, but it's not a 5 minute thing, unlike the change of warning limit. Feel free to open an RFE for that.
Merged, now 512 MiB. No build yet.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. 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 '33'. 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 33 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.