systemd-boot: Fix kernel.d post files for XBOOTLDR

[ppp7032]

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architectures: x86_64-musl and aarch64-glibc (tested on two machines).

The kernel post-install and post-remove scripts for systemd-boot have been treating it as a given that the kernel resides under $ESP. This is not accurate when the user has an extended boot partition (XBOOTLDR). In this case, the user will change $BOOT in /etc/default/systemd-boot to point to their XBOOTLDR and notice an error due to the post-install script failing to find the kernel.

This PR makes the scripts look under $BOOT. It does not alter the behaviour for anyone with $BOOT == $EFI. It only corrects behaviour for the case where $BOOT != $EFI.

[Duncaen]

This doesn't seem like the right change and would break current users setups.

[ppp7032]

This doesn't seem like the right change and would break current users setups.

I believe current users either A) set SYSTEMD_BOOT_DISABLE=1 because they use UKIs (or otherwise do not want to use the scripts) or B) Have $EFI == $BOOT (which is the default). The first setup is irrelevant for obvious reasons and the second has its behaviour preserved. Current behaviour when $EFI != $BOOT is broken, this PR simply fixes it.

Could you try describing a setup that you believe would be broken by this change?

Regardless, assuming the kernel lives under the $ESP is wrong. It only happens to be correct when your ESP is mounted to /boot. These scripts currently do not support XBOOTLDRs. My aim is to change that.

[ppp7032]

Behaviour when $BOOT != $EFI is broken because the kernel and initramfs obviously live in /boot. There is no sane setup where $BOOT != $EFI (let's say /boot and /efi respectively) and the kernel is found in /efi. To be honest, I'm not sure why $BOOT is even a variable that can be configured. It might make sense to just fix it to /boot.

[Duncaen]

I was thinking about separate ESP, but yes you are right that would only work with UKIs and they are not supported by this hook.

[Duncaen]

CC @Calandracas606

[Calandracas606]

I generally agree with these changes.

It makes more sense to use $BOOT since it is consistent with what is documented in the spec: https://uapi-group.org/specifications/specs/boot_loader_specification/

The logic should probably be:

ESP="${ESP:-/boot}"
if [ -z "${BOOT}" ]; then
  BOOT="${XBOOTLDR:-$ESP}"
fi

Though this could theoretically break existing installs, if $BOOT was not set to something sane, eg:

BOOT=/some/really/dumb/path
ESP=/boot

[ppp7032]

I'm not sure why these variables even exist to be honest. There's nothing to configure here. The only sane value for $BOOT is /boot.

Additionally, under my proposal (which I believe works for both the case with and without an XBOOTLDR), $ESP isn't even used. Without my proposal, $BOOT isn't even used. Either way, one of them should probably be removed.

My only reason for making this PR is because the scripts failed for me when I attempted to set them to set the correct values (for me) of $BOOT=/boot and $ESP=/efi. If I had just left them to their default values $BOOT == $ESP == /boot then I would not have had any problems. I would like it, however, if the variables meant what they said on the tin.

I believe the best course of action would be to modify my proposal with an explicit setting of $BOOT=/boot in the script and to not source it from the config file at all. $ESP should be removed as it is not used and simply not relevant under this proposal.

Alternatively, we could do something like this:

if [ -z "${ESP}" ]; then
        # This branch corresponds to "new" configs, as well as old configs that left this to default value
        BOOT=/boot
        # Could maybe also be `BOOT="${BOOT:-/boot}" if we want this to be user-configurable for "new" configs
else
        # This branch corresponds to old configs that explicitly set $ESP to something exotic
        # It is a good idea to not source `$BOOT` from the user because this variable was previously unused
        # i.e. held no significance to the execution of this script. We don't want to suddenly give it significance
        # By doing this, users with $BOOT=/some/really/dumb/path in the config are not affected.
        BOOT="${ESP}" 
fi
# The rest of the script uses $BOOT to locate the kernel just like my patch currently does

This way, old configs that explicitly set $ESP will continue to work and $BOOT will continue to be unused. The new config file would either not present the user with the ability to set $BOOT or $ESP (so both will be their default values), or only present $BOOT.

Thoughts?

[ppp7032]

I've implemented the "alternative" proposal from my last comment because I believe it's the best approach. It prevents any possible breakage from old configs (i.e. $BOOT=/some/really/dumb/path) while presenting a sensible new default config.