Should I worry? (/boot out of space after upgrade)

Ask Fedora
1

I just accepted the upgrade to Fedora 43, and on the first boot I got a warning that /boot had 0 bytes free. It was completely full.

System still booted. “uname -r” clearly shows I’m running a F43 kernel. But I find it difficult to believe that my boot partitition filled up during the upgrade without leaving the system in a somewhat degraded state.

I have since added install only_limit=2 to my dnf config, and ran an update to remove extra kernels and prevent future issues. So disk space is cleared.

Anyone have any suggestions of anything I should do to ensure that /boot is fully populated as it would have been during the upgrade?

Finally… why, with a 1GB boot partition, did I run out of space, and why didn’t the upgrader detect that I didn’t have enough free space before I kicked it off?

2
  1. If you do ls /boot/*fc43* then you should see 5 files corresponding to your kernel version:
config-...
initramfs-...
symvers-...
System.map-...
vmlinuz-...
  1. If you do sudo ls /boot/loader/entries then there should be a .conf file in there corresponding to your new fc43 kernel version

As long as both those look fine, then you should have everything you need in /boot.

Here’s the background:

3

Thanks for the response!

All of the files are there and sizes seem reasonable (compared to the other kernels). Of course I cannot verify that they are complete; something must have been writing right up to the point the disk filled up.

I understand the technical “why”… I don’t understand why it was allowed to happen. I believe the 1GB boot partition was automatic when I did a clean install of Fedora 42 on this 1TB NVME drive (I don’t recall tweaking it). It seems like it would be a fairly easy check to make to prevent out of space conditions… get the max size of existing kernels and ensure that there is that much (+10% or so) free on the disk.

4

It isn’t “fairly easy”, really. “The upgrader” is just dnf (the package tool). An “upgrade” of Fedora at this point is a barely distinguishable operation from an “offline update” of an existing install. We’ve tried fancier upgrade mechanisms in the past and they’ve always turned out to work less well than just doing this, primarily because they’re exercised way less often so nobody notices all the bugs until everybody does.

dnf does check whether there’s sufficient space for the packages in the update to be installed, but because it’s a package manager, it only knows the size of the files that are actually inside the packages. The initramfs files aren’t in the package, they’re dynamically generated during the install process. At the time dnf does its size checks those files don’t exist and there’s no way to know how big they will be.

Sure, theoretically it could guess based on existing files, but that would be a very special-purpose mechanism to somehow jam into what is a very general-purpose tool, and it’s not necessarily accurate - initramfs size can change depending on quite a lot of things, like the behavior of the tool that generates it, and the contents of linux-firmware (both of those are things that actually happened during the F42 cycle).

So…yeah, it’s technically possible to do something about this, but it’s not at all as straightforward as it might seem.

1 Like
5

Correct. This problem began during the life of f42 with one of the 6.16 kernel updates. It was recognized and with f43 a new install creates a 2GB /boot partition but the user has to manage it for upgrades.

I chose on my system to use gparted with a live system boot to resize and relocate the / partition allowing space to expand /boot to a 2GB size.

1 Like