When booting (after installing latest updates) I was told I have no space left on /boot. Disk usage analyser shows me that the largest proportion of space is taken by an initramfs-0-rescue-…img file which seems to be from two years ago, then the initramfs and vmlinuz-virt files for the currently installed kernels.
When looking into the /boot directory, the largest contribution is from efi/EFI/fedora, in which there are four large files, all of them from 6 February (gcdia32.efi, gcdx64.efi, grubia32.efi, grubx64.efi).
Not sure how to free space on /boot (or even if I need to bother - perhaps this will sort itself out as unnecessarily files are deleted automatically)?
The third to last kernel I installed caused problems - the computer wouldn’t boot (said iniramfs not available), so I removed and reinstalled it. Not sure if this is relevant.
The simplest work around would probably be to reduce the number of kernels that are kept on /boot by changing the value of installonly_limit= in /etc/dnf/dnf.conf.
A better solution would be to increase the size of your /boot partition. Unfortunately, that process is quite involved.
Edit: Another option might be to uninstall the dracut-config-rescue package which (I think) will prevent that “rescue” kernel from being readded to your /boot partiton the next time you update.
It is risky attempting to use a system with low disk space as you risk damaging the filesystem. It is best to make space (e.g., by deleting the rescue image and, as suggested, preventing the system from creating a new one).
There are other threads dealing with this – if you have time to read them you may get a better idea of the options available to you.
Terminal output can help us better understand the issue. lost+found Searchable text may help others with similar problems find this thread.
The rescue image contains drivers that the normal kernels load as modules.
Systems that have been upgraded over many Fedora vesions often have a boot partition that is too small for current kernels. It would help to mention the history of the system and the size of /boot/, Here, with a fresh install of F39:
% df -lH /boot
Filesystem Size Used Avail Use% Mounted on
/dev/sdc2 1.1G 391M 560M 42% /boot
If your partition is this size, check that sudo ls -l /boot/lost+found isn’t full of files.
I can delete config-6.7.10-100.fc38.x86_64+debug and config-6.7.11-100.fc38.x86_64+debug, but they seem small, not sure how much difference this will make.
Thanks to everyone who answered - I still hope to learn which files I can delete safely (but will look at other threads too).
You should avoid just deleting files – use something like sudo dnf remove <unwanted_package>. You will get a chance to quit after reviewing the proposed action. To get package names, use, e.g., sudo dnf whatprovides /boot/initramfs-6.8.4-100.fc38.x86_64+debug.img.
You’re right, the timeshift files shouldn’t be there, but these are small files. The problem was with having debug kernels installed (after version 6.7.10 did not work, I installed all kernels with this version, then they kept installing).
Thank you to everyone for feedback.
Gill had posted on another thread he used and closed in January. That led me to moving that post to another thread where we solved this issue. I am moving the duplicate thread to merge it here.
I believe that is a file created by dell for recovery of the bios and should not be removed.
The real issue seem to be the size of the /boot or the /boot/efi partition.
Please show the result of df -h, lsblk -f and sudo fdisk -l so we can see what the drive has for space and possibly make suggestions to fix this problem so it does not recur. (use the </> button on the toolbar to retain on-screen formatting of that data.)
NOTE
You should not reopen threads that already have a solution noted.
I am opening a new thread for you to continue this discussion.
Looking at that it seems /boot is full (as expected)
Please now post the output of sudo du -h /boot so we can get a summary and see what is using all the space there. This will give us the subdirectories and their usage. It would appear that /boot/efi is not a concern.
My system which has been in use for quite some time only is using ~470M for everything under /boot. Yours shows a full 1G usage and a full partition there.
The issue, and the real reason that I opened this thread is that you posted on a closed thread. It is always best to continue all discussion on one thread. I did not notice that you were also managing the other thread as well or I would have joined this to that one.
In any case, we need to find out why /boot is full and fix that problem – clear space as well as determining the cause and stopping that problem.
I see two problems with what you just posted…
First is the timeshift snapshots. They should NEVER go into /boot since that is a relatively small partition and is dedicated to boot files. Turn off timeshift and reconfigure it to store data somewhere else before restarting it. You also need to remove all those snapshots from /boot.
We need to see what is actually taking space in /boot. Nothing in that list is obvious as to what is using the space. Everything under /boot/efi is another partition so is not of concern. This leaves the only visible suspects as the /boot/timeshift tree.
Lets look at exactly what is in /boot with ls -l /boot