Unable to install new kernels due to lack of space in /boot/efi

Hello,
I have a Fedora Media PC which my family relies on. I’m nervous about touching it as they tolerate outages less than my customers at work!

I built the PC years ago and have upgraded it every 6 months (I love that about Linux and Fedora!). Unfortunately when it was first setup it seems that the default partition sizing for /boot/efi was much smaller than what is needed today.

The system currently fails to install any new Kernels because /boot/efi only has 33 MiB free (it is only 200 MiB in total!).

EDIT: Confusingly my Fedora 39 WorkStation only has a 100 MiB /boot and is dual booting with Windows without problem. It appears to be using UEFI boot also but isn’t struggling at all for space. What is going on?

Given my partition layout (below) what would you recommend as the lowest risk way of resolving this please?

I was hoping I might be able to resize partitions with parted from a bootable USB stick, but I’m nervous about doing it and about whatever needs to happen to fix the boot sector (etc?). I can back up to some attached Hard Disks, but do not wish to boot from them.

$ lsblk /dev/sda
NAME                   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda                      8:0    0 111.8G  0 disk 
├─sda1                   8:1    0   200M  0 part /boot/efi
├─sda2                   8:2    0     1G  0 part /boot
└─sda3                   8:3    0 110.6G  0 part 
  ├─ssd-root           253:0    0    14G  0 lvm  /
  ├─ssd-... (various logical volumes here, with 15 G free in the 'ssd' volume group)

$ sudo fdisk -l /dev/sda
Disk /dev/sda: 111.79 GiB, 120034123776 bytes, 234441648 sectors
Disk model: Samsung SSD 850 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5865C9F7-87C2-46EB-BD14-97D499C64A3E

Device       Start       End   Sectors   Size Type
/dev/sda1     2048    411647    409600   200M EFI System
/dev/sda2   411648   2508799   2097152     1G Linux filesystem
/dev/sda3  2508800 234440703 231931904 110.6G Linux LVM

The OS is installed on a fairly old SSD so I’d prefer not to shift all the data afterward in case it reduces durability. I was thinking it might be safe to boot to some kind of external Linux image, shrink /boot (currently 1GiB) down to 250 MiB and expand /boot/efi to use all the freed space. However I’m not sure what I need to do to ensure the system is bootable after resizing patitions.

Thank very much you in advance!

I’ve just been looking for the recommened disk layout and partition sizes and find that as of Fedora 36 (at least) /boot at 1GiB and /boot/efi at 200 MiB were recommended.
I’ve since read this post which suggests the defaults in a more recent Fedora version would be 1 GiB /boot and a 600 MiB /boot/efibut why does /boot need to be so big if doing UEFI boot? My /boot volume is using around 100 MiB total, while my /boot/efi volume is using 160 MiB and hasn’t installed two kernels properly!

# du -mx . | sort -n
1	./EFI/BOOT
1	./grub2
1	./System
1	./System/Library
1	./System/Library/CoreServices
7	./EFI/fedora
8	./EFI
16	./e379971670d2470683309bc19d8d0140/0-rescue
73	./e379971670d2470683309bc19d8d0140/6.8.7-100.fc38.x86_64
73	./e379971670d2470683309bc19d8d0140/6.9.4-100.fc39.x86_64
160	./e379971670d2470683309bc19d8d0140
168	.

# df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       200M  168M   33M  84% /boot/efi

There’s only one fully working Kernel installed here, 6.8.7-100. I removed two other versions in order to try to get 6.9.4-100 to succeed, but there’s not enough space left.

Woah, just realised the system is running a Fedora 38 Kernel version on Fedora 39. I need to fix this sooner rather than later.

You probably ran into the common problem that you have a directory named /boot/efi/e379971670d2470683309bc19d8d0140.

If you are booting using grub2, you should remove this directory and its contents and re-install the latest kernel-core.

You can check if you are booting with grub2 by running the bootctl command.

After that, the kernel should be installed into the /boot file system and not into the /boot/efi file system, and then the lack of space problem should be solved.

2 Likes

Thanks very much @vekruse ! If I can avoid resizing the filesystems for a few more years that would be great.

Do you know how I’d find details of the bug you talk about please? I’d like to safely clean this up.

bootctl returns:

systemd-boot not installed in ESP.
System:
      Firmware: n/a (n/a)
 Firmware Arch: x64
   Secure Boot: disabled (setup)
  TPM2 Support: no
  Boot into FW: supported

Current Boot Loader:
      Product: n/a

<...>

Available Boot Loaders on ESP:
          ESP: /boot/efi (/dev/disk/by-partuuid/6a411f0b-4b13-4189-a10b-cfec1d126b44)
         File: └─/EFI/BOOT/BOOTX64.EFI

Boot Loaders Listed in EFI Variables:
        Title: Fedora
           ID: 0x0001
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/6a411f0b-4b13-4189-a10b-cfec1d126b44
         File: └─/EFI/FEDORA/SHIM.EFI

Boot Loader Entries:
        $BOOT: /boot/efi (/dev/disk/by-partuuid/6a411f0b-4b13-4189-a10b-cfec1d126b44)
        token: fedora

0 entries, no entry could be determined as default.

What were you looking for there please?

EDIT: A /boot/grub2/ directory exists and only grub2 packages seem to be installed.

Edit: Thankfully a suggested forum post below linked me to:

https://bugzilla.redhat.com/show_bug.cgi?id=2071034

The red "x"s.

Apologies:

Current Boot Loader:
      Product: n/a
     Features: ✗ Boot counting
               ✗ Menu timeout control
               ✗ One-shot menu timeout control
               ✗ Default entry control
               ✗ One-shot entry control
               ✗ Support for XBOOTLDR partition
               ✗ Support for passing random seed to OS
               ✗ Load drop-in drivers
               ✗ Support Type #1 sort-key field
               ✗ Support @saved pseudo-entry
               ✗ Support Type #1 devicetree field
               ✗ Enroll SecureBoot keys
               ✗ Retain SHIM protocols
               ✗ Boot loader sets ESP information
          ESP: n/a
         File: └─n/a

but thank you very much, you have already helped me solve the problem. I moved the random number directory to /var/tmp, reinstalled kernel-core and rebooted and it’s working! Whew!

As I understand it there is a plan to eventually convert from grub to systemd-boot. Doing so requires more space in the efi partition since the kernels will eventually be placed there for systemd boot. The increased size of /boot/efi on new installs is likely part of the preparation for that switch. Users of systemd-boot at this time also benefit from the change in size of the efi partition.

2 Likes

Don’t wait, If you can buy “Dumpster Dive” HDD’s, do so !

Thanks, but I’m afraid that you’re making some big presumptions there.

  1. I want HDDs in a quiet media PC
  2. I’m low on storage
  3. I don’t care how much power an always on PC in my home uses

… but I’m afraid all these presumptions are untrue.

The main issue for me is my time. Especially with the risk and effort needed to repartition the boot SSD without losing a unique system I built many years ago.

While I have data backups, trying to get the configuration back to where it is (in the event of an OS rebuild) would be very tedious and time consuming.