Arch Linux User Repository

I have updated the hook now, to use the systemd unit instead of doing the update ourselves. If you are still running systemd 249 or older, don't use this, as it relies on systemd 250.

FWIW, one problem with using the service from within the hook is that the caller might be in a chroot building an image without the service manager running.

If I opt to enable systemd-boot-update.service, does this hook still make sense?

In 99% of the cases you can probably just use the service instead of this hook. Some people have use-cases (for ex. secure boot) where they probably want to run bootloader updates in an interactive manner (you will probably notice a failed pacman hook, while a failed service can be more hidden), which is why some will still opt to use this hook instead. This task is so mundane, there aren't really any big problems that could arise other than issues with secure boot.

For me personally the hook feels more robust, but it technically does the exact same thing as the service, just with different timing.

but the advantage is that we stay closer to upstream.

I think upstream doesn't have a preference here. On Arch it's disabled by default. So I guess everyone can decide for themselves. I wouldn't be surprised if the service will be enabled by default in the future, as it only touches systemd-boot installations anyway and doesn't even modify any EFI variables. It's basically just a glorified cp.

Edit: Btw. sorry to everyone who turned notifications on. Again. This task is so mundane, most people probably don't care :D

Oh wow @Scrumplex, that was a fast reaction, thanks for the quick package update!

Related question: If I opt to enable systemd-boot-update.service, does this hook still make sense? I suppose we would be deferring the update to the next boot instead of doing it at package upgrade time, but the advantage is that we stay closer to upstream.

Using the oneshot service is an interesting change, since it means that one can set another service to run before it -- particularly, one that signs /usr/lib/systemd/boot/efi/systemd-bootx64.efi into /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed.

If the latter is present, sd-boot will install that instead.

Edit: that might be unnecessary complexity though; using a separate hook suffices.

I have updated the hook now, to use the systemd unit instead of doing the update ourselves. If you are still running systemd 249 or older, don't use this, as it relies on systemd 250.

Okay. I just tried out a few things. Apparently if you restart a oneshot service that has RemainAfterExit=yes systemctl waits until the process exited and also handles a failed unit. The user will certainly notice that, as pacman will report that the hook returned with a non-zero exit code. So I am in-fact confident that this is viable. Any other thoughts?

Why not have the hook simply use systemd to (re-)start the existing systemd-boot-update.service then, instead of copying/rebuilding the service's functionality/behaviour?

I was actually looking into this. But I am not comfortable just running /usr/bin/systemctl restart systemd-boot-update.service, as that would hide the output from the user.

I tried experimenting with a transient service using systemd-run, but couldn't get anything nice to work.

It might be a good idea for this hook to just "do the same thing, but the timing is different".

Why not have the hook simply use systemd to (re-)start the existing systemd-boot-update.service then, instead of copying/rebuilding the service's functionality/behaviour?

I suggest adding --no-variables option to bootctl update. The upstream systemd-boot-update.service does this. It might be a good idea for this hook to just "do the same thing, but the timing is different".

There's also --graceful but I'm not sure about that one.

whynothugo: oh interesting! I need to find out if that's easily possible using Foxboron's excellent sbctl. In my workflow it probably won't make much of a difference, as sbctl is triggered if anything on my /boot or /efi is touched during a pacman transaction.