Solved /boot/efi does not have sufficient space (Kubuntu 23.10)

[ghosty999]

Hello there,

I'm using a Dell Latitude 7390 with Kubuntu 23.10 x86_64. When trying to run a software update I receive a "Dell firmware update" which displays the following error below.

Any suggestions? I obviously can't extend the partition

 

[atanere]

It's pretty unusual to fill up /boot/efi. What's the output of:

df -h /boot/efi
# and
sudo ls /boot/efi/EFI

 

[ghosty999]

It's pretty unusual to fill up /boot/efi. What's the output of:

df -h /boot/efi
# and
sudo ls /boot/efi/EFI

M thoughts exactly...

Output:
BOOT Dell Microsoft ubuntu

 

[atanere]

Your /boot/efi folder has almost 42 MB of bootloader files, and that seems a lot for only a dual boot setup. The full partition size of 61 MB is pretty undersized to start with... more common is 256 MB to 512 MB. To give you a comparison, my /boot/efi/EFI only has 2 folders, BOOT (2 MB) and ubuntu (4.4 MB)... only 6.4 MB total with only one OS. Linux Mint resides in the ubuntu folder. The BOOT folder is from Dell, I think, but I don't have a Dell folder... I may have removed that myself, but I don't remember doing it.

You may can expand /boot/efi into that Microsoft reserved partition (if it is unallocated space) to gain 16 MB more, but you're probably going to have to go into /boot/efi manually (as root) and identify where and what this excess data is... which folder is the culprit, and why?

Another way is you may can shrink /home to allow for expansion of /boot/efi. If that would work, you could claim the more reasonable 256-512 MB space and not disturb the Microsoft partition. Does Microsoft really need that partition? I don't know!
Scratch that idea. /boot/efi is partition "p1" and /home is "p5"... I think you can only expand into "p2" the Microsoft reserved partition, if that doesn't cause other problems.

Resizing partitions with important data is risky. Anything you do here may cause you more problems, so you really should make good backups before making changes.

And you could let the BIOS update go unless you think you really need it for something.

 

[ghosty999]

Your /boot/efi folder has almost 42 MB of bootloader files. The full size of 61 MB is pretty undersized to start with... more common is 256 MB to 512 MB. To give you a comparison, my /boot/efi/EFI only has 2 folders, BOOT (2 MB) and ubuntu (4.4 MB)... only 6.4 MB total with only one OS. (Linux Mint resides in the ubuntu folder. The BOOT folder is from Dell, I think.)

You may can expand /boot/efi into that Microsoft reserved partition (if it is unallocated space) to gain 16 MB more, but you're probably going to have to go into /boot/efi manually (as root) and identify and delete the folders for operating systems you no longer use. If you delete any folders there, you should run sudo update-grub before rebooting to try to prevent problems booting without them.

Another way is you may can shrink /home to allow for expansion of /boot/efi. If that would work, you could claim the more reasonable 256-512 MB space and not disturb the Microsoft partition. Does Microsoft really need that partition? I don't know!
Scratch that idea. /boot/efi is partition "p1" and /home is "p5"... I think you can only expand into "p2" the Microsoft reserved partition, if that doesn't cause other problems.

Resizing partitions with important data is risky. Anything you do here may cause you more problems, so you really should make good backups before making changes.

And you could let the BIOS update go unless you think you really need it for something.

Sorry the full output in terminal was:

yngwie@yngwie-Latitude-7390:~$ df -h /boot/efi
# and
sudo ls /boot/efi/EFI
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1   61M   42M   19M  70% /boot/efi
[sudo] password for yngwie:
BOOT  Dell  Microsoft  ubuntu

I recently completely wiped the internal SSD and firstly installed Windows 11, then Kubuntu. I use Grub on startup to navigate to which OS I require.
Thanks very much for your help. It looks like I need to do a little reading on accessing and deleting within the boot/efi. Luckily nothing important is stored on this laptop so it's okay for tinkering.

 

[atanere]

Sorry... the forum was down for a few minutes and I was still editing above. Probably nothing drastically important, but you might give it a re-read.

Installing Windows first should have made a bigger /boot/efi... I would have guessed, but maybe not. That is the crux of your problem... it should be 256-512 MB at least for most situations.

 

[wizardfromoz]

Just a heads up on the math

You may can expand /boot/efi into that Microsoft reserved partition (if it is unallocated space) to gain 16 MB more,

... won't be enough. Error says "required 51 MB, got 19.3 MB", so 16 MiB won't be sufficient.

If it were me, I would first abide by my friend's advice

...so you really should make good backups before making changes.

and then try the following:

1. From within Windows, use its disk partitioning tool to shrink the main NTFS partition by 1 GiB.
2. From within Windows, use its disk partitioning tool to move the Microsoft Reserved 16.00 MiB to rest above the NTFS partition. That should leave most of a Gig of Unallocated Space between /boot/efi and Reserved.
3. Boot into Kubuntu (if it allows booting), open GParted and unmount /boot/efi (yes, you can do that from a running session, it is only the / partition you can not manipulate in session), then
4. Resize /boot/efi to, say 300+ MiB and complete.
5. Exit GParted
6. Reboot and run your updates again.

If the first part of Step 3. fails, it will be because some Distros will not allow booting with less than 100 MiB /boot/efi.

If that occurs, perform Steps 3. to 6. from a GParted Live stick or disk, or from a Kubuntu Live /CD/DVD/USB.

Cheers

Wizard

 

[wizardfromoz]

BTW, as an alternative, you could run the above-described principle "from the top down".

That is, reduce the size of your /home partition by 1 GiB, and then allocate the Unallocated Space to /boot/efi.

For that option, you would perform all steps from a Kubuntu Live /CD/DVD/USB.

EDIT - BE SURE TO USE GPARTED, not KDE Partition Editor, it fails to deliver the goods. But also read below, where the OP had a mishap under his Kubuntu 23.10

I don't use a separate Home so I tend to forget that.

Wiz

 

[ghosty999]

1. From within Windows, use its disk partitioning tool to shrink the main NTFS partition by 1 GiB.
2. From within Windows, use its disk partitioning tool to move the Microsoft Reserved 16.00 MiB to rest above the NTFS partition. That should leave most of a Gig of Unallocated Space between /boot/efi and Reserved.
3. Boot into Kubuntu (if it allows booting), open GParted and unmount /boot/efi (yes, you can do that from a running session, it is only the / partition you can not manipulate in session), then
4. Resize /boot/efi to, say 300+ MiB and complete.
5. Exit GParted
6. Reboot and run your updates again.

If the first part of Step 3. fails, it will be because some Distros will not allow booting with less than 100 MiB /boot/efi.

If that occurs, perform Steps 3. to 6. from a GParted Live stick or disk, or from a Kubuntu Live /CD/DVD/USB.

Cheers

Wizard

Thankyou for this. Last night I created 8gig unallocated space from a partition and tried to allocate it to the EFI using MiniTool at boot. Obviously that didn't work as I was missing the step above of doing it Kubuntu.

One thing that did happen was the GRUB boot menu stopped showing up and the laptop would instantly boot to Windows. This was fixed by adding the grub as a boot option in the BIOS and attaching it to the correct partition.

I will try again with the extra steps above and report back.

 

[atanere]

That is, reduce the size of your /home partition by 1 GiB, and then allocate the Unallocated Space to /boot/efi.

I thought the freed up space from /home (p5) needed to be adjacent to /boot/efi (p1) for that to work... for p1 to expand into the new space? No?

Shrinking the NTFS partition seems a great way to go, but I think the new space will then be automatically joined to the smaller 16 MB "p2" partition (if unallocated, as I suspect). But then /boot/efi could be expanded... recreating the Microsoft Reserved partition or not. I'm not sure of the importance of that partition.

I'm also not sure of the importance of the BOOT and Dell folders found in /boot/efi/EFI. I have a /boot/efi/EFI/BOOT folder on my Dell desktop, but I don't have the Dell folder, so it may can be safely deleted, which may provide the space needed to retrieve the BIOS update, especially if the 16 MB partition was also claimed and used to expand /boot/efi. The math may work, if all the excess space is being taken up by the /boot/efi/EFI/Dell folder, and if it can be deleted without causing harm. Maybe the BOOT folder could be deleted too? I don't know if it was put there by Linux Mint on mine (Kubuntu for the OP), or by Dell/Microsoft? Deleting these folders may be risky.

I recently completely wiped the internal SSD and firstly installed Windows 11, then Kubuntu.

Luckily nothing important is stored on this laptop so it's okay for tinkering.

If not worried about data loss and you have time to play, it's a good problem to tinker with... resizing partitions, or deleting folders in /boot/efi/EFI, without killing the system. Or you may kill the system. It's probably far quicker and less stressful to simply reinstall everything all over again, and find/fix where it went wrong in sizing /boot/efi.

While tinkering, if you reinstall, you might try installing Linux first instead of Windows. Although "Windows first" is the common wisdom, I find my Dell XPS doesn't care, and I can use the BIOS boot order to make Linux boot first after Windows takes over. Then after going back to Linux first, running sudo update-grub will bring Windows back to the GRUB boot menu. I haven't set it up in awhile, so I hope I'm not forgetting something... but it was really quite easy. Dell seems very friendly to multi-booting.

 

[wizardfromoz]

G'day, Stan

I thought the freed up space from /home (p5) needed to be adjacent to /boot/efi (p1) for that to work... for p1 to expand into the new space? No?

It is, and yes.

What I have described above is accurate. The screenshot provided by the OP at #3, which I reproduce below, is from his KDE Partition Manager

Adjacent to his /boot/efi are -

(above) p5 /home, and
(below) p2 unknown, MS reserved, likely his Dell Recovery.

I will detail more from my own Kubuntu 22.04 'Jammy' with an example which may benefit The Viewers.

Cheers

Wiz

 

[wizardfromoz]

This will be a long post, regrets.

I am using my Western Digital My Book for the example, it housed 48 partitions, numbered sequentially, except for /dev/sdb2 *

SCREENSHOT 1 - About to delete /dev/sdc19

I've checked the content of /dev/sdc19 and I don't need it so for now I will delete it, and create a new partition elsewhere.

SCREENSHOT 2 - Deletion done

With KDE Partition Manager, as with GParted, at the bottom of your open window, you get Pending Operations listed, when you are ready, with KDE you go to top left and click the Apply button.

SCREENSHOT 3 - Creating new partition

I have decided not to replace the deleted partition on the spot and in the same place. If I did so, it would become a new /dev/sdc19.

Instead I have gone to near the end of my drive, and am creating a 10 GiB partition labelled 4Linux-dot-org.

SCREENSHOT 4 - Changes Applied, new partition created and numbered automatically

Here, I have chosen to Apply all changes, and the result below /dev/sdc48, shows the new partition has been created. Because I did nothing to replace the earlier /dev/sdc19 that I deleted, Linux has allocated /dev/sdc19 to the partition labelled 4Linux-dot-org.

This now resembles, a little, what the OP has in #3. Numbers are out of order.

You can also note that

* I keep my /boot/efi's at the end of my drives, , here /dev/sdc2, makes for easy resizing by redeeming some space from Unallocated Space above it.

But wait! I then decide that my /dev/sdc48 Photorec partition does not need 20 GiB, I will give 10 GiB of that to the new partition.

SCREENSHOT 5 - /dev/sdc48 shrunk, /dev/sdc19 expanded

I have resized /dev/sdc48 down by 10 GiB (temporarily results in 10 GiB Unallocated Spaced), followed by resizing the new /dev/sdc19 up by 10 GiB. I have then Applied all changes, and the above is the result.

Note that while the numbering varies (/dev/sdc48 to /dev/sdc19) that does not matter, as the partitions are aligned by each other.

HTH

Wizard

 

[ghosty999]

A little update...

BTW, as an alternative, you could run the above-described principle "from the top down".

That is, reduce the size of your /home partition by 1 GiB, and then allocate the Unallocated Space to /boot/efi.

For that option, you would perform all steps from a Kubuntu Live /CD/DVD/USB.

I don't use a separate Home so I tend to forget that.

Wiz

I tried this by reducing the /home partition by 500mb, then booted into a live environment. Expanding the efi error-ed and I was then unable to boot to Kubuntu. It would still boot to windows so I went to adjust the boot priority to Grub. It still skipped it and booted to windows.

I decided to "go nuclear" and buy a second 7390 for $200 just to run Windows, so I can do away with dual booting on my daily driver.

 

[wizardfromoz]

That is most unusual, and most unfortunate for you.

I have just performed the same operation on my Kubuntu 22.04 and it worked fine. I now have a 1.5 GiB /boot/efi , as shown in part from saved details from GParted.

grow partition from 1.00 GiB to 1.50 GiB 00:00:17 ( SUCCESS )
	old start: 7809839104 old end: 7811936255 old size: 2097152 (1.00 GiB) new start: 7809839104 new end: 7812984831 new size: 3145728 (1.50 GiB)

grow file system to fill the partition 00:01:25 ( SUCCESS )
	using libparted

I can only guess that it is some vagary between Kubuntu 22.04 and 23.10, but that seems unusual.

I hope

I decided to "go nuclear" and buy a second 7390 for $200 just to run Windows, so I can do away with dual booting on my daily driver.

works out for you.

If you feel this Thread is over with, you can edit your first Post and choose to mark as Solved.

I will go back and edit one of my posts to ensure it is clear to use GParted, I tried the same option with KDE Partition Editor and it did not work.

Wizard

 

[ghosty999]

That is most unusual, and most unfortunate for you.

I have just performed the same operation on my Kubuntu 22.04 and it worked fine. I now have a 1.5 GiB /boot/efi , as shown in part from saved details from GParted.



I can only guess that it is some vagary between Kubuntu 22.04 and 23.10, but that seems unusual.

I hope



works out for you.

If you feel this Thread is over with, you can edit your first Post and choose to mark as Solved.

I will go back and edit one of my posts to ensure it is clear to use GParted, I tried the same option with KDE Partition Editor and it did not work.

Wizard

Thankyou. I only received your detailed instructions after I had started. Maybe following them would of yielded better results.

Either way I'll mark the thread solved as your solution will likely help others.