gpt-generator, bootctl, nspawn: EFI mount point handling updates - #3757
Conversation
There was a problem hiding this comment.
Hm, do we really want to skip mounting the ESP in this case? It seems reasonable to mount it, even if we boot from BIOS. Not related to this PR of course.
There was a problem hiding this comment.
ah, indeed. you are right, we should just mount it always, if it is there. Will add another patch to this PR to drop this check.
Let's make the EFI generator a bit smarter: if /efi exists it is used as mount point for the ESP, otherwise /boot is used. This should increase compatibility with distros which use legacy boot loaders that insist on having /boot as something that isn't the ESP.
…o /efi or /boot Matching the behaviour of gpt-auto-generator, if we find an ESP while dissecting a container image, mount it to /efi or /boot if those dirs exist and are empty. This should enable us to run "bootctl" inside a container and do the right thing.
… path This rearranges bootctl a bit, so that it uses the usual verbs parsing routines, and automatically searches the ESP in /boot, /efi or /boot/efi, thus increasing compatibility with mainstream distros that insist on /boot/efi. This also adds minimal support for running bootctl in a container environment: when run inside a container verification of the ESP via raw block device access, trusting the container manager to mount the ESP correctly. Moreover, EFI variables are not accessed when running in the container.
We already have tolower() calls there, hence let's unify this at one place. Also, update the code to only use ASCII operations, so that we don't end up being locale dependant.
After all, the field is kinda borked.
Make sure that we always initialize the return parameter on success, and that all errors result in an error message, not just some.
let's the proper APIs to read the machine ID, and properly check for all errors.
…/efi With this change kernel-install will now first look for an existing kernel installation in /efi, /boot and /boot/efi. If none is found, /efi is used if it is a mount point, otherwise /boot/efi if it is one. If nothing of that worked /boot is used without further checking. This means /boot should be the default unless something was installed before or something else was explicitly mounted.
Previously, we'd not mount the ESP except on EFI boots, and only when the ESP used for booting matches the ESP we found. With this change on non-EFI boots we'll mount a discovered ESP anyway, and on EFI boots we'll only mount it if it matches the ESP we booted from.
|
OK, I force pushed a new version that adds a commit that relaxes the EFI check in the generator a bit. I also rebased it on current git, and fixed the doc issue you pointed out. Please have a look and merge! |
But the gpt-generator does not use /boot/efi. Is this intentional? |
Yes. Because /boot/efi is just stupid, as it implies that an ESP partition implies a separate /boot partition, but that's nonsense. Also, a generator is run with nothing but the root dir plus /run mounted. That means even if we wanted we couldn't check if /boot/efi is a usable mount point as that as likely itself on a mount point that isn't mounted yet. Which is another reason why /boot/efi is stupid. |
No, it doesn't, why would it? The EFI partition must be separate of course, but distro installers don't configure a separate |
well, but /boot would effectively be empty then, only having a subdir? Why have it then? |
Debian kernel packages ship the kernels in /boot: Which is IMO nice to have on non-efi systems, otherwise you get to duplicate every kernel you have installed. |
|
But /boot is a weird place for the kernels if they aren't needed there... On Fedora, kernels are shiped next to the kmods in /usr/lib/modules/$KERNEL_VERSION and simply copied into the ESP or /boot as necessary. That way the boot partition (regardless if ESP or legacy) is entirely redundant, and the system partition is fully self-sufficient, so that the ESP or /boot can be reconstructed at any time. |
|
Looks good to merge. Not merging because of the v232 milestone. |
|
Doesn't this contradict the Linux FHS? http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s05.html |
|
FHS is mostly dead, it hasn't been updated to include most of the developments in the Linux ecosystem in the last decade. We don't want to deviate from FHS without reason, but for stuff that it simply doesn't cover because it wasn't around when it was written, we don't have much choice. |
Recent Arch Linux installs use `/efi` as the EFI boot directory - https://wiki.archlinux.org/index.php/EFI_system_partition#Typical_mount_points - systemd/systemd#3757 (comment)
This is recursive logic. What's the reason that we deviated from the standard in this particular instance? |
|
@nero-dv There is no standard for modern (U)EFI-Boot in the FSH. That's something that is around for 11years on every new PC at this point (longer for specific cases). The FSH needs an update. |
|
This change is a pain and way too opinionated. It's making assumptions where things should be and hard coding them. This forced use of paths without checking preset values or any way to modify result in issues like #26644. And, several other work around and fixes since implementation. As was stated before, it does violate FHS3.0.03.05./boot . And, no.. that FHS is not outdated, it simply states all boot required files go under root/boot folder. One should be able to mount any subdir in there ("/boot/efi", "/boot/esp", "/boot/esp(n)", etc..) Which is preferable to having multiple root directories filled with all sorts of boot only related files. There may be a use case requiring 5 partitions during boot. Should we then create 5 different directories in root? Not only that, but it could possibly end up ignoring other (U)EFI spec's additional device path protocol sub type file definitions. Of which there can be multiple. This change may also not be as distribution agnostic, since it doesn't seem to account for registered subdirectories like "/EFI/Debian" during install. I know this is old. And, I'm late to the comment. The damage is done and there have been lots of changes as a result. But, I don't re-install linux from scratch that often. Yet, this is the first time I've been stuck for days trying to get details on a new boot directory/partition "standard". There is just no discussion on this decision, nor reasoned argument for it. And:
Is not a good argument. Since ESP partition implication would then mean that its proper mount point would be something like /tmp/esp/. As it needs to be access by programs and install scripts. Therefore should not be mounted to /mnt as separate partitions usually are. Nor is it:
It is an overthought. Since it could be true of "/efi" path. As technically we could have a separate esp trying to mount to the same location. Same as multiple partitions trying to mount to "/boot" for some reason. But, chances are that most are going to mount and mkdir the parent before the child. And, will deal with consequences of mistakes outside the tool's scope. The same way we setup up and mount root before "/efi" or fail. Much simpler to attempt default or return an error when boot path structures are not defined by conf or other parameters. |
|
A single $BOOT partition is the way to go. https://github.com/lnussel/lnussel.github.io/blob/fs/_posts/2020-12-16-fslayout.md#boot-files |
…f ESP: systemd/systemd#3757 @ modules/boot.nix
This updates bootctl quite a bit and makes it search for the EFI mount point at /boot, /efi and /boot/efi.
This updates nspawn to mount the ESP to /boot or /efi automatically if there's one in a disk image passed to --image=. This way "bootctl" can be used inside of nspawn containers.
This also updates the gpt generator to optionally use /efi as mount point if /boot is not available as mount point because something else is located there.
Finally, this updates kernel-install to install the kernel to /efi if /boot is blocked by something else.