Dracut can't write to /boot/efi (no space)

Ask Fedora
1

Some background:

I got my ~/.config/ deleted by a mishap at some point, and after that my plymouth theme has been looking real weird.

I decided today to try to fix it with sudo plymouth-set-default-theme --reset --rebuild-initrd

However, this ends up with following error:

cp: error writing '/boot/efi/0c67dd39127b4971bcfe4e144ab3b617/6.15.9-201.fc42.x86_64/initrd.tmp': No space left on device
dracut[F]: Creation of /boot/efi/0c67dd39127b4971bcfe4e144ab3b617/6.15.9-201.fc42.x86_64/initrd.tmp failed

Now I was told to try to just run dracut -f, but that ended up with similar message.

Then, I was told to try to rename the /boot/efi/0c67dd39127b4971bcfe4e144ab3b617 to /boot/efi/0c67dd39127b4971bcfe4e144ab3b617.tmp and run dracut -f again, which ends with this:

dracut[F]: Can't write to /boot/efi/0c67dd39127b4971bcfe4e144ab3b617/6.15.9-201.fc42.x86_64: Directory /boot/efi/0c67dd39127b4971bcfe4e144ab3b617/6.15.9-201.fc42.x86_64 does not exist or is not accessible

I was also told to check /etc/kernel/install.conf but I have no such file.

I tried to delete one of the older kernels to make more space, sudo dnf remove kernel-6.15.7-200.fc42.x86_64. It did delete the kernel but the files in /boot/efi still linger.

Here’s a whole /boot device tree in case it can be helpful.

❯ sudo tree /boot
[sudo] password for akseli:
/boot
├── efi
│   ├── 0c67dd39127b4971bcfe4e144ab3b617
│   │   ├── 0-rescue
│   │   │   ├── initrd
│   │   │   └── linux
│   │   ├── 6.15.7-200.fc42.x86_64
│   │   │   ├── initrd
│   │   │   └── linux
│   │   ├── 6.15.8-200.fc42.x86_64
│   │   │   ├── initrd
│   │   │   └── linux
│   │   └── 6.15.9-201.fc42.x86_64
│   │       ├── initrd
│   │       └── linux
│   ├── amd-ucode.img
│   ├── EFI
│   │   ├── BOOT
│   │   │   ├── BOOTIA32.EFI
│   │   │   ├── BOOTX64.EFI
│   │   │   ├── fbia32.efi
│   │   │   └── fbx64.efi
│   │   ├── fedora
│   │   │   ├── BOOTIA32.CSV
│   │   │   ├── BOOTX64.CSV
│   │   │   ├── gcdia32.efi
│   │   │   ├── gcdx64.efi
│   │   │   ├── grub.cfg
│   │   │   ├── grubia32.efi
│   │   │   ├── grubx64.efi
│   │   │   ├── mmia32.efi
│   │   │   ├── mmx64.efi
│   │   │   ├── shim.efi
│   │   │   ├── shimia32.efi
│   │   │   └── shimx64.efi
│   │   ├── Linux
│   │   └── systemd
│   │       └── systemd-bootx64.efi
│   ├── initramfs-linux-fallback.img
│   ├── initramfs-linux.img
│   ├── loader
│   │   ├── entries
│   │   │   ├── 0c67dd39127b4971bcfe4e144ab3b617-0-rescue.conf
│   │   │   ├── 0c67dd39127b4971bcfe4e144ab3b617-6.15.7-200.fc42.x86_64.conf
│   │   │   ├── 0c67dd39127b4971bcfe4e144ab3b617-6.15.8-200.fc42.x86_64.conf
│   │   │   └── 0c67dd39127b4971bcfe4e144ab3b617-6.15.9-201.fc42.x86_64.conf
│   │   ├── entries.srel
│   │   ├── loader.conf
│   │   └── random-seed
│   ├── mach_kernel
│   ├── System
│   │   └── Library
│   │       └── CoreServices
│   │           └── SystemVersion.plist
│   └── vmlinuz-linux
├── grub2
│   ├── fonts
│   │   └── unicode.pf2
│   ├── grub.cfg
│   └── grubenv
├── initramfs-0-rescue-0c67dd39127b4971bcfe4e144ab3b617.img
├── loader
│   └── entries
│       └── 0c67dd39127b4971bcfe4e144ab3b617-0-rescue.conf
├── lost+found
├── symvers-6.15.7-200.fc42.x86_64.xz
├── symvers-6.15.8-200.fc42.x86_64.xz
├── symvers-6.15.9-201.fc42.x86_64.xz
└── vmlinuz-0-rescue-0c67dd39127b4971bcfe4e144ab3b617

Note that I have not changed any defaults. Things should be just as they are from the Fedora install I did around 2023.

Any help to get either enough room in there to get dracut -f working or fixing the config that places initramfs images in ESP rather than in /boot would be appreciated.

PS. I have no idea what I’m doing. Any guides should be pretty much step-by-step if possible :smiley:

Could this be related? New kernels not being installed in /boot anymore - #11 by vekruse

Error regenerating kernel via `dracut`
2

Your tree of /boot is considerably different than mine and shows a lot of stuff in /boot/efi that seems not fedora grub related.

$ sudo tree /boot
/boot
├── config-6.15.7-200.fc42.x86_64
├── config-6.15.8-200.fc42.x86_64
├── config-6.15.9-201.fc42.x86_64
├── efi
│   ├── EFI
│   │   ├── BOOT
│   │   │   ├── BOOTIA32.EFI
│   │   │   ├── BOOTX64.EFI
│   │   │   ├── fbia32.efi
│   │   │   └── fbx64.efi
│   │   └── fedora
│   │       ├── BOOTIA32.CSV
│   │       ├── BOOTX64.CSV
│   │       ├── gcdia32.efi
│   │       ├── gcdx64.efi
│   │       ├── grub.cfg
│   │       ├── grubia32.efi
│   │       ├── grubx64.efi
│   │       ├── mmia32.efi
│   │       ├── mmx64.efi
│   │       ├── shim.efi
│   │       ├── shimia32.efi
│   │       └── shimx64.efi
│   ├── mach_kernel
│   └── System
│       └── Library
│           └── CoreServices
│               └── SystemVersion.plist
├── grub2
│   ├── fonts
│   │   └── unicode.pf2
│   ├── grub.cfg
│   └── grubenv
├── initramfs-0-rescue-594ece762a4b48678f35f7be2ddf7410.img
├── initramfs-6.15.7-200.fc42.x86_64.img
├── initramfs-6.15.8-200.fc42.x86_64.img
├── initramfs-6.15.9-201.fc42.x86_64.img
├── loader
│   └── entries
│       ├── 594ece762a4b48678f35f7be2ddf7410-0-rescue.conf
│       ├── 594ece762a4b48678f35f7be2ddf7410-6.15.7-200.fc42.x86_64.conf
│       ├── 594ece762a4b48678f35f7be2ddf7410-6.15.8-200.fc42.x86_64.conf
│       └── 594ece762a4b48678f35f7be2ddf7410-6.15.9-201.fc42.x86_64.conf
├── lost+found
├── symvers-6.15.7-200.fc42.x86_64.xz -> /lib/modules/6.15.7-200.fc42.x86_64/symvers.xz
├── symvers-6.15.8-200.fc42.x86_64.xz -> /lib/modules/6.15.8-200.fc42.x86_64/symvers.xz
├── symvers-6.15.9-201.fc42.x86_64.xz -> /lib/modules/6.15.9-201.fc42.x86_64/symvers.xz
├── System.map-6.15.7-200.fc42.x86_64
├── System.map-6.15.8-200.fc42.x86_64
├── System.map-6.15.9-201.fc42.x86_64
├── vmlinuz-0-rescue-594ece762a4b48678f35f7be2ddf7410
├── vmlinuz-6.15.7-200.fc42.x86_64
├── vmlinuz-6.15.8-200.fc42.x86_64
└── vmlinuz-6.15.9-201.fc42.x86_64

13 directories, 42 files

Also we need to know the size of /boot/efi and how much is occupied. This would be shown with df -h

$ df -h
Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/fedora_root-root   393G   96G  278G  26% /
efivarfs                       128K   43K   81K  35% /sys/firmware/efi/efivars
/dev/nvme0n1p2                 825M  540M  227M  71% /boot
/dev/nvme0n1p1                 335M   20M  316M   6% /boot/efi
/dev/mapper/fedora_raid1-home  7.3T  6.0T  951G  87% /home

Are you by chance using systemd boot?
Management of that is much different than grub and requires a lot more space in the efi partition than when booting with grub.

It certainly may be related to the link you provided.

As I recall the fix has been to remove the extraneous directory and all its content under /boot/efi (in your case /boot/efi/0c67dd39127b4971bcfe4e144ab3b617) then perform a reinstall of the newest kernel sudo dnf reinstall kernel\*. This should relocate the kernel files (initramfs*.img, vmlinuz* and others) back to /boot instead of under /boot/efi

3

Ah sorry, I forgot to mention.

This computer used to have archlinux, which used systemd-boot. I then installed fedora instead. I do recall formatting the drives, but maybe something stood behind?

4

Possibly, especially if the /boot/efi partition was not specifically formatted. But also may be related to the bug noted in the linked topic.
In any case the fix seems the same.

5

Partly. But it doesn’t look like leftovers from a previous installation. All the entries are Fedora entries and the directory 0c67dd39127b4971bcfe4e144ab3b617 matches your current machine id. I would guess that someone ran the command bootctl install which enabled systemd-boot to be used as boot loader. This would work fine if secure boot is disabled.

6

Correct, but it does not account for the apparent full file system which is the original complaint.

7

It might be the file amd-ucode.img caused the extra space usage. And that is how it could work fine for a couple of years, and now suddenly not anymore.

But the question is: Was instalking systemd-boot in the ESP intentional? And how big is the ESP?

8

Exactly.
This is why I asked about the results of df -h and the OP has not responded.

10

You should have directed this to the OP since he is the one with the problem.

11

Just of interest: type “uname -r” to get the actually running kernel version.

The directory with the long name is a sign for the kernel installation to store the kernel and the initrd in the ESP, which runs out of space.
To fix:
Archive important data and have a live system at hand plus knowledge how to rescue an unbootable system via “chroot” from livesys.

Be sure all grub packages for EFI are installed. I’ve

grubby-8.40-82.fc42.x86_64
grub2-common-2.12-32.fc42.noarch
grub2-tools-minimal-2.12-32.fc42.x86_64
grub2-tools-2.12-32.fc42.x86_64
grub2-tools-extra-2.12-32.fc42.x86_64
grub2-efi-x64-2.12-32.fc42.x86_64

All as superuser:
Use “bootctl” and if systemd-boot is active, “bootctl remove”
Completely remove the folder with the long name from /boot/efi, renaming does not really help in case of space problems.
Type: “kernel-install add-all” to reinstall all kernels and check that they land in /boot
Check /boot/efi/EFI/fedora/grub.cfg, if the 4th and last line is not “configfile $prefix/grub.cfg”, delete it and reinstall grub2-tools.
Type “grub2-mkconfig -o /boot/grub2/grub.cfg”

At some stages the system could be unbootable, if you’re not comfortable with this, consider archival of important files and reinstall.

1 Like
12

Sorry I ghosted this thread, forgot to mention that I have solved the issue, but I had to reinstall Fedora completely :frowning: I think i just broke something really badly and the old Arch install was still stuck in my UEFI boot menu, and other fun things.

1 Like