With the kernel getting bigger and quite a few of us running into issues with lack of space in the EFI partition I'd like to suggest an addition to updates. Can we have the update process check the partition size before it tries to install and fail? Have it then put up an error that the update cannot continue until the partition is expanded or older kernels are removed. That way users who are not updating via terminal can see what is wrong and either fix it or call someone that can. My personal concern is that my elderly parents will brick their machine one of these days and I'll have to drive 4 hours to go delete old kernels.
Suggestion for updates
- Edited
zmaint Not sure why the EFI partition gets so bloated on some systems, I checked mine and it was at 201mb used space before the week 11 update. It had reduced to 200mb used space after the update.
As a sanity check for you maybe your parents could be coaxed into running Disks or KDE Partition Manager to check on the current size of the EFI partition. Easier still how about getting them to type inxi -p into the terminal and then report back, no password to worry about and all the information is entirely relevant.
Going slightly off road it would be nice to be able to use the installer to prepare a separate \Home partition which would then allow users to overwrite an existing install without needing to back up all of their existing data first.
Future iterations of Solus have intentions of being even more robust than it is now. Hopefully in time all these concerns will no longer be applicable.
Edit: Strange as it may seem prior to running the week 11 update inxi -p displayed the size of the EFI partition and available space. Post update it no longer does this. Tested on three pre and post-update PCs running Solus Plasma.
As a compromise you could run lsblk in terminal which will show the size of the EFI partition but not how full it is. If the size it 1Gb then you probably don't need to worry about overfilling.
BuzzPCSOS Not sure why the EFI partition gets so bloated on some systems,
If we can answer that, we can maybe plot some uniformity, at least the kind @zmaint is talking about. I am holding steady at 183-ishMB. It's almost as if the 'last 2 kernels plus LTS' boot commands don't execute uniformly?
BuzzPCSOS Edit: Strange as it may seem prior to running the week 11 update inxi -p displayed the size of the EFI partition and available space. Post update it no longer does this. Tested on three pre and post-update PCs running Solus Plasma.
Good catch.
brent uh, could be me. Tried to duplicate the fault on another non-updated laptop and I could not get details of the EFI partition to show using inxi -p , the best I could get was to use inxi -o to show unmounted partition details for EFI and SWAP in a more friendly format than lsblk shows it. Putting this down to a PEBKAC issue.
Rather than being exclusively a NVIDIA issue could the overflowing EFI partition also be caused where Solus is added to a PC already running an OS that provides an EFI partition smaller than 1GB?
zmaint Well here is one answer I suppose. Here is a screenshot from a junk box laptop that I installed Solus on last year. I'm guessing that I set \root as the boot partition by mistake. Certainly no chance of the EFI partition getting too full
Looked at my main laptop and tablet and both have about 200MB EFI used space in a 1GB partition. Both have intel embedded graphics so it looks like NVIDIA is your problem and the link supplied by @Sebastian is the the one you need to watch for answers.
BuzzPCSOS That's what I'm thinking. Looks like for whatever reason that clr-boot-manager is failing to always delete those older kernels on nvidia systems. Unsure why, but there's a ticket already open so hoping it gets fixed sooner than later. Doesn't seem like just increasing partition size is a long term fix if it just continues to stockpile old kernels.
I have one older Solus system with 512 MB EFI partition (now default should be 1GB) and I have 2 kernels installed - current and LTS. Few months ago I got an error during update. I managed to solve it by removing older kernel.
I would just reinstalled Solus with bigger EFI partition but I am lazy. I think next time I install Solus I will set 2GB EFI partition just in case 
zmaint My PC has had Solus Plasma on it for 4+ years, Nvidia the entire time, and this is the first time I've ever had an issue or more than 2 kernels installed. Something is different.
Solarmass has Budgie. @Sebastian noted this was a known bug (I think its DE-exclusive personally but I have no proof but anecdotal; or Nvidia) where the mechanism to remove the last kernels after an update stopped working in certain cases, leading to accumulation.
I think Solus will have this fixed soon -Serebit is on it, with Tracy, probably more.
That said @Solarmass , 512MB should house the kernels if that failed "mechanism" I am calling it is working. (That's why I said DE-specific maybe). But you still have to make it bigger sometime! I have to think back a couple years when Solus Officially Announced their endorsement of a 1GB boot partition. I don't remember a Forum "how the hell do I do that?"-thread. I remember searching for it and doing it myself in a live environment with gparted. And not worrying since.
- Edited
Just checked, and my EFI is still 512 MB, but so far no issues. Running Solus Budgie.
Happened only one time to me. Solus Budgie and AMD GPU
I'm quite worried as I'm a Budgie Nvidia user.
Can someone kindly advise me what is the definitive way to check if I'm affected by this bug?
How do I check the current status of my EFI partition, to what extent has it already been filled up, percentage-wise?
How can I safely remove all the old unused kernels and their correspondings nvidia files?
Thank you.
- Edited
snowee
Check partition size.
sudo clr-boot-manager mount-boot
sudo du -d1 -h /boot
See installed kernels.
sudo clr-boot-manager list-kernels
And/or
ls /boot/EFI/com.solus-project/
If needed you can then delete the old kernels, typically you should have 2 currently installed, or maybe 3 if you also keep LTS around.
sudo clr-boot-manager remove-kernel <kernel-name>
Be careful to not try and delete the kernel you are currently using. Might want to confirm what you're booted with before removing stuff.
uname -r
I don't know how to see if the bug impacts you other than checking to see if you have an excessive amount of kernels. The older ones should be getting deleted by clr-boot-manager. They're working on figuring that out and getting it corrected.