My EFI Partition is 537MB and my system dual boots between Linux Mint 22.3 and Fedora.
I just upgraded from version 42 to version 44 on Fedora and now I am being told that my EFI partition only has 24 MB of disk space left. I got on the Fedora forums and used some instructions to clean up some of the EFI space used from the previous kernels from 42. But it’s not enough to stop getting the message about EFI space and I’m unsure what I can and can’t remove beyond that.
I booted into Linux Mint and removed old kernels as well so I am down to three over there too.
I didn’t think the EFI partition would ever have issues at 537MB. But upon reviewing the specs for 44 , I see it want’s more just for one OS, let alone two.
So is my best option to backup my installs and change the partition sizes using Gparted? If so, what size should I make it?
Please post the output of df -h , lsblk -f , and sudo ls -lR /boot as preformatted text so we may see what the issue actually may be. That should show us the relevant information about file system space available and used so we may effectively troubleshoot the issue.
It’s just a system notification that pops up instantly when I log in. It offers me the opportunity to examine the disk but of course the disk utility it launches can’t mount the volume, I suspect because it’s not launched using sudo privileges.
/boot does not appear to contain anything related to fedora.
There should be the kernel files (vmlinuz, initramfs, system.map, config, and symvers) for each installed fedora kernel.
There should also be subdirectories (grub2 and loader) that are specific for fedora.
The only thing I see in /boot is related to ubuntu.
The content of /boot/efi looks normal for ubuntu and only has the one subdirectory (/boot/efi/efi/fedora) that is normal for fedora.
As you can see from the output of df, /boot/efi is 500M with only 28M actually used at this time.
Since this appears to be an issue in sharing the efi partition with ubuntu, I would suggest expanding /dev/sdd1 to at least 1G then you will have to perform repairs to install fedora kernels so it is able to boot.
In the efi partition for a pure fedora installation I see this.
$ sudo ls -lR /boot/efi
/boot/efi:
total 20
drwx------. 4 root root 8192 Jan 15 18:00 EFI
-rwx------. 1 root root 34 Jan 15 18:00 mach_kernel
drwx------. 3 root root 8192 Jan 15 18:00 System
/boot/efi/EFI:
total 16
drwx------. 2 root root 8192 May 10 14:48 BOOT
drwx------. 2 root root 8192 May 15 09:00 fedora
/boot/efi/EFI/BOOT:
total 2004
-rwx------. 1 root root 806195 Nov 2 2025 BOOTIA32.EFI
-rwx------. 1 root root 1026520 Nov 2 2025 BOOTX64.EFI
-rwx------. 1 root root 91576 Nov 2 2025 fbia32.efi
-rwx------. 1 root root 119280 Nov 2 2025 fbx64.efi
/boot/efi/EFI/fedora:
total 18472
-rwx------. 1 root root 112 Nov 2 2025 BOOTIA32.CSV
-rwx------. 1 root root 110 Nov 2 2025 BOOTX64.CSV
-rwx------. 1 root root 3080616 May 6 19:00 gcdia32.efi
-rwx------. 1 root root 4145576 May 6 19:00 gcdx64.efi
-rwx------. 1 root root 159 May 15 09:00 grub.cfg
-rwx------. 1 root root 3080616 May 6 19:00 grubia32.efi
-rwx------. 1 root root 4145576 May 6 19:00 grubx64.efi
-rwx------. 1 root root 695016 Nov 2 2025 mmia32.efi
-rwx------. 1 root root 874352 Nov 2 2025 mmx64.efi
-rwx------. 1 root root 1026520 Nov 2 2025 shim.efi
-rwx------. 1 root root 806195 Nov 2 2025 shimia32.efi
-rwx------. 1 root root 1026520 Nov 2 2025 shimx64.efi
/boot/efi/System:
total 8
drwx------. 3 root root 8192 Jan 15 18:00 Library
/boot/efi/System/Library:
total 8
drwx------. 2 root root 8192 May 10 14:48 CoreServices
/boot/efi/System/Library/CoreServices:
total 4
-rwx------. 1 root root 384 Jan 15 18:00 SystemVersion.plist
It appears that almost everything you have under /boot/efi/efi/fedora is the same as mine, but you appear to have removed everything (except the efi files) that should be under /boot that is fedora related.
Your / file system (which contains /boot) is currently at 70% (with 34G available) so that should be large enough to recover the fedora installation and restore the files and subdirectories that I noted above.
The exact message you see is still way more useful than a vague rephrasing of the message. If for any privacy or reasons you don’t want to show that, that is fine. But then the answers you may get may then also be vague guesses.
On a normal Fedora installation, kernels don’t occupy any space at all in the EFI partition, only in /boot. So if you had Fedora kernel files in the EFI partition, there was likely a configuration issue that needs to be fixed.
I can’t find the thread any longer, but it basically told me where to look for Fedora 42 kernels and delete the files associated with them .
I also used a tool in Linux Mint to delete older kernels that were not being used. The partition now has more room. But see the error below when trying to boot Fedora.
Well I would have, but Fedora 44 stopped booting shortly after cleaning up older kernels from 42. I’m getting the error below during boot.
Yes. That’s because I’m now getting this error below. But Mint is booting fine.
So to recap, I “tried” to clean up old Fedora Kernels and I cleaned up old Mint kernels. There is now more space on /boot/efi. Gparted is now showing only 28 MB used on my /boot/efi partition.
But Fedora is hanging during boot (see above). I am not sure if that message is related to something I did, but it looks like I am having a problem with Nvidia card drivers.
Recovery
I am thinking of increasing the EFI System partition size and reinstalling Fedora 44 from scratch. If I do that, should I delete the /boot/efi/efi/fedora and let the installer set everything up again?
Is there a way to avoid having Fedora’s version of Grub from being installed as well so I can just have one version of Grub?
What partition is /dev/sde3? It looks like the boot is getting stuck on that.
The logs show that nouveau (i.e. the default open source driver for Nvidia cards) is being loaded. If that’s happening even though you tried to install the proprietary Nvidia drivers, then something isn’t right - but it’s not a problem that is preventing you from booting.
I don’t think you would need to manually delete in that case, the installer should take care of it.
No straightforward way of doing this, but that per se isn’t really a problem. (If you were able to make everything work from Mint’s GRUB, you could just set your boot priorities so that you always booted into Mint GRUB by default, and Fedora’s GRUB would just be hanging around unused, doing no harm.)
The challenging part is getting Fedora included in Mint’s GRUB (and in a way that works seamlessly whenever there is a kernel update and so on). There’s a topic here where a user tried booting Fedora from Mint’s GRUB, and vice versa. In the end it sounds like neither of those things worked great, and it was easier just to use the BIOS boot menu to select Fedora or Mint GRUB.
First of all, thanks. I can sort of understand the boot log dialogue.
That’s a western digital external usb drive that’s formatted NTFS for backups in Windows. The problem is that Fedora hangs there whether the drive is plugged into the computer or not. For example, on the error message I attached it was not hooked up to the computer. It was one of the first things I tried when it started hanging during the boot process.
There are occasions when Mint’s GRUB is does not detect Fedora updates but running “update-grub” as sudo on the Mint side always updates grub for me.
For me, at least, it seems that I have trouble getting Fedora to keep using the Nvidia drivers. This is not the first time it’s switched back to Nouveau. It got to the point that I was thinking it needed to load these first before switching over to proprietary drivers.
When the Nvidia drivers are installed, does that change the Kernel? Is it possible the upgrade from 42 to 44 dropped the Nvidia drivers? Or maybe I deleted the kernel when trying to clean up space on /boot/efi/?
I think I will still try a fresh install of 44 at least.
I wonder whether each time you perform this in Mint, you’re removing the blacklisted modules from all command lists for all kernels and the next time you boot Fedora you’re loading nouveau rather than your preferred Nvidia drivers, because they are no longer blacklisted.
Once they are added to the command list as a parameter to the kernel, they don’t vanish or stop being blacklisted on a whim; only when something actively removes them…
Ah, you have a GM206 card (i.e. a GeForce 900 series aka Maxwell). The latest Nvidia drivers for Fedora 44 don’t support that - you can install a different package which is locked to a driver version that does support your hardware. (Process for doing so described here.)
So that would explain the Nvidia driver failing to initialise, and falling back to nouveau.
Do you have it mapped in /etc/fstab? If so, I wonder if removing it (and just mounting it in Linux when you need it) would improve things.
No
It does not directly impact the kernel at all, but does build a new kernel module (driver) that gets loaded during boot in place of the nouveau driver.
Possible, yes depending upon how the upgrade was performed; But not likely except as noted by @pg-tips above.
The kernel does not reside under /boot/efi for fedora. It resides in /boot.
However, if something you did altered the content of /boot/efi/EFI/fedora it may have impacted the /boot/efi/EFI/fedora/grub.cfg file which is normally a pointer file that should actually tell grub to use the file /boot/grub2/grub.cfg for booting.
Having any usb device in /etc/fstab should be managed by adding the option nofail to that fstab entry to prevent hangs during boot.
As far as the nvidia drivers go, installing the driver, upgrading the driver, upgrading a kernel, are all events that cause the system to build and install a new kernel module. It takes a short time after any of these events for the build & install process to complete so the user needs to be aware of the necessity to wait a reasonable time for the module to be created and installed before rebooting. Sometimes an early boot causes the new module to fail to install properly which then requires recovery.
The simplest recovery command to use is sudo akmods --rebuild --force which will remove any defective module and build and install that module new. A reboot after that should load the new driver properly.
The suggestion above by @pg-tips concerning the change in driver version in f44 that does not support the older nvidia gpu currently installed seems very critical. F44 coincided with the release of the nvidia 595 driver which dropped support for GPUs with both the maxwell and pascal chipsets so the instructions that he linked are important. Those steps will revert the installed driver back to the 580 version that will support your card for quite some time.
Thank you. Good catch. I will follow those instructions. The video card is still adequate for my needs so there’s no need to run out and update hardware.
