How to get rid of the /boot directory when using systemd-boot?

I followed steps described at Systemd-boot install on Fedora 32 (Updated for Fedora 40) article and moved the ESP partition from /boot/efi to /efi and deleted boot partition.
However /boot directory still seems to be used as a place to install files by some packages:

$ ls /boot
extlinux  symvers-6.10.4-200.fc40.x86_64.xz  symvers-6.10.7-200.fc40.x86_64.xz  symvers-6.9.12-200.fc40.x86_64.xz

These seems to be kernel-core package:

$ dnf5 provides /boot/symvers-6.10.7-200.fc40.x86_64.xz
Updating and loading repositories:
Repositories loaded.
kernel-core-6.10.7-200.fc40.x86_64 : The Linux kernel
Repo         : @System
Matched From :
Filename     : /boot/symvers-6.10.7-200.fc40.x86_64.xz

and syslinux-extlinux-nonlinux package:

$ dnf5 provides /boot/extlinux
Updating and loading repositories:
Repositories loaded.
syslinux-extlinux-nonlinux-6.04-0.27.fc40.noarch : The parts of the EXTLINUX bootloader which aren't run from linux.
Repo         : @System
Matched From :
Filename     : /boot/extlinux

How to configure system so that above files would be installed in the /efi directory instead of the /boot one allowing to delete the latter one?

1 Like

Added boot, f40, grub, syslinux, systemd

No idea why this is showing up again, but sounds interesting, I added a few more tags to push it to the top :slight_smile:

Where are the kernels stored in your setup?

It looks like all the files on the /boot filesystem are now regular files (no more symlinks) and could be stored in the ESP.

Some files in /boot are owned by packages rather than just generated

dnf rq -al | grep ^/boot/

Maybe make /boot on the root filesystem a symlink (or bind mount) pointing into /efi so all the current tooling will still work.

1 Like

Kernels are stored in /efi/$(cat /etc/machine-id):

# ls /efi/df12a9d4f2ad4c67b6df5303027ce003/
0-rescue  6.10.4-200.fc40.x86_64  6.10.7-200.fc40.x86_64  6.10.9-200.fc40.x86_64
# ls /efi/df12a9d4f2ad4c67b6df5303027ce003/6.10.9-200.fc40.x86_64/
initrd  linux

I guess in accordance with the following:

Recommended Directory Layout for Additional Files #

It is recommended to place the kernel and other other files comprising a single boot loader entry in a separate directory: /<entry-token-or-machine-id>/<version>/. This naming scheme uses the same elements as the boot loader menu entry snippet, providing the same level of uniqueness.

Example: $BOOT/6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux $BOOT/6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd

from Boot Loader Specification | UAPI Group Specifications

Some files in /boot are owned by packages rather than just generated
dnf rq -al | grep ^/boot/

This list is big. I have no idea what do most of these packages have to do with /boot.

Making /boot a symlink or bind mount is some option but I was hoping to entirely get rid of it :wink:

If you want to get rid of the duplication, it would be easier (and it would actually comply with the spec) to use /boot as the one single mount point for all boot loader content. /boot has been where that content has been stored for decades. Why try to move it to a new place now?

Makes sense. Somehow the idea of unhiding :wink: the ESP partition by moving the mount point from /boot/efi to /efi seems attractive and then having kernels there makes impression there’s nothing interesting left in the /boot so why not remove it? :wink:

Nah, “/efi” is a bit cryptic. “/boot” is a more intuitive name for the top-level directory. I would argue that the content is less hidden (easier to find) by having it stored under /boot. Also, having a path named /efi/efi just looks like something has gone wrong (and it can be confusing to scripts that are trying to parse $PWD to figure out where they are). /boot/efi/fedora is better, IMHO, than /efi/efi/fedora.

Edit: In case I wasn’t clear, I am saying you should mount the whole ESP at /boot instead of at /efi (or /boot/efi). All the existing scripts are already coded to handle having the ESP mounted at /boot.

2 Likes

In an sdboot anaconda install of a quite minimal f41 from the latest compose, the only regular file that ends up on the /boot filesystem is the symvers file from kernel-core. That symvers file is also placed in /lib/modules so it does not need to be in /boot at all.

Currently doing an installation through anaconda has the ESP mount point of /boot/efi hardcoded. I am getting into bootc installations and will see how far I get mounting the ESP at /boot as that seems workable while also answering the objections to /boot/efi stated in the BLS document. Nice progress. The BLS doc wants the ESP at /boot unless both an ESP and XBOOTLDR are used where the XBOOTLDR would be at /boot and the esp at /efi.

A quote from Pid Eins if that interests you.

Use XBOOTLDR only if you have to, i.e., when dealing with systems that lack UEFI (and where the ESP hence has no value) or to address the mentioned size issues with the ESP.

1 Like

This package is a relic from older times when the iso images used syslinux as boot loader on legacy bios systems. For most parts, you can ignore its existence. If it is installed on your system, you can remove it.

The /boot/sysmve-xxx files you can leave where they are. As far as I know, nothing needs these files. Perhaps they are needed on RHEL systems, and because of shared source code between Fedora and RHEL you still get them.

The sdubby package provides a /usr/sbin/grubby which requires the ESP to be mounted at /boot/efi. A few packages call /usr/sbin/grubby as part of their install scripts, so it may be ill advised to modify the mount point of the ESP.

The systemd developers prefer to mount the ESP at /efi, but this is not the way Fedora prefer to do things. In any case, when installing a new system which would be using sd-boot, you can just tell anaconda to not create the /boot file system.

1 Like

@vekruse,

There are probably other packages beside sdubby and syslinux-extlinux-nonlinux that will need to be updated to support mounting the ESP at /boot. But a lot of progress has been made in the last couple years towards that end. With GPT partitioning the storage device to use for things that belong on the ESP can be determined programmatically. It gets a little complicated with or without the use of XBOOTLDR and the cases where there are more than 1 ESP but it should all be possible without any hardcoded paths;-)

As I test things out I find that anaconda refuses to perform an installation without a /boot when / is ie: btrfs.

1 Like