Package Details: systemd-boot-pacman-hook 3-1

Git Clone URL: https://aur.archlinux.org/systemd-boot-pacman-hook.git (read-only, click to copy)
Package Base: systemd-boot-pacman-hook
Description: Pacman hook to upgrade systemd-boot after systemd upgrade.
Upstream URL: None
Licenses: GPL
Submitter: Nierro
Maintainer: Nierro (Scrumplex)
Last Packager: Scrumplex
Votes: 151
Popularity: 2.38
First Submitted: 2016-06-18 15:25 (UTC)
Last Updated: 2021-12-27 16:36 (UTC)

Required by (0)

Sources (1)

Pinned Comments

Scrumplex commented on 2021-12-27 16:37 (UTC) (edited on 2021-12-27 16:38 (UTC) by Scrumplex)

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.

Latest Comments

Scrumplex commented on 2021-12-28 18:58 (UTC) (edited on 2021-12-28 18:59 (UTC) by Scrumplex)

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

thiagowfx commented on 2021-12-28 18:45 (UTC)

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.

whynothugo commented on 2021-12-27 16:50 (UTC) (edited on 2021-12-27 16:53 (UTC) by whynothugo)

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.

Scrumplex commented on 2021-12-27 16:37 (UTC) (edited on 2021-12-27 16:38 (UTC) by Scrumplex)

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.

Scrumplex commented on 2021-12-27 16:20 (UTC)

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?

Scrumplex commented on 2021-12-27 15:13 (UTC)

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.

Corubba commented on 2021-12-27 15:02 (UTC) (edited on 2021-12-27 15:04 (UTC) by Corubba)

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?

5long commented on 2021-12-27 14:40 (UTC)

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.

Scrumplex commented on 2021-12-24 23:19 (UTC)

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.

whynothugo commented on 2021-12-24 23:07 (UTC) (edited on 2021-12-24 23:08 (UTC) by whynothugo)

if someone is using secure-boot it would be safer if the bootloader is updated and signed

You should sign the loader AND THEN install it. See https://github.com/systemd/systemd/pull/21566

Scrumplex commented on 2021-12-24 19:14 (UTC)

Thanks! Also merry xmas from me!

Nierro commented on 2021-12-24 18:49 (UTC) (edited on 2021-12-24 18:49 (UTC) by Nierro)

Here we go :) Thanks! I might drop the package entirely in the future; at least i will leave it in good hands!
Oh, also, merry xmas!

Scrumplex commented on 2021-12-24 18:48 (UTC)

@Nierro: Thanks for the offer! If you feel like you don't need this package anymore, feel free to add me as a co-maintainer :D I will certainly still use it on my securely booted notebook :D

Nierro commented on 2021-12-24 18:44 (UTC)

Uh i see, that makes sense.
Btw for my use case (and most use cases i think), the new service is quite enough.
Would you like to step up and maintain this package?

Scrumplex commented on 2021-12-24 18:42 (UTC) (edited on 2021-12-24 18:42 (UTC) by Scrumplex)

@Nierro not quite! I edited to Wiki today documenting this feature. The systemd unit only runs on every boot when enabled. So the updated bootloader will be active on the second reboot after upgrading systemd. Also: if someone is using secure-boot it would be safer if the bootloader is updated and signed after the package upgrade, as the user wouldn't necessarily notice a failed service unit. So there is still a use-case.

Nierro commented on 2021-12-24 18:39 (UTC)

@Scrumplex from what i read, it seems like this package is now useless:

A new unit systemd-boot-update.service has been added. If enabled (the default) and the sd-boot loader is detected to be installed, it is automatically updated to the newest version when out of date. This is useful to ensure the boot loader remains up-to-date, and updates automatically propagate from the OS tree in /usr/.

Nierro commented on 2021-12-24 17:01 (UTC)

@Scrumplex i will git this a look, thanks!

Scrumplex commented on 2021-12-24 10:08 (UTC)

With systemd 250 (currently in testing). You could start the new systemd-boot-update.service oneshot service, instead of running bootctl update inside your hook.

Nierro commented on 2021-05-16 19:39 (UTC)

Done, sorry for the late response!

whynothugo commented on 2021-05-16 17:30 (UTC)

It would be nice if this hook had an ordering number such as 95-systemd-boot.hook.

Could we have this change please?

thiagowfx commented on 2021-05-14 15:19 (UTC)

What is the point of this package? systemd provides pacman-hooks.

It's documented here: https://wiki.archlinux.org/title/Systemd-boot#Automatic_update

codicodi commented on 2021-04-14 10:13 (UTC)

It would be nice if this hook had an ordering number such as 95-systemd-boot.hook. This way it could be easily ordered before other hooks that sign the bootloader .

eimis commented on 2019-06-21 23:05 (UTC)

thank you for this ⭐⭐⭐⭐⭐

wookietreiber commented on 2018-12-21 10:09 (UTC)

@haawda: It's a hook that is not provided in the official packages to update systemd-boot when systemd is updated.

I suppose, that it is not included in either pacman or systemd because not everyone is using systemd-boot.

wookietreiber commented on 2018-12-21 09:56 (UTC)

@haawda: Have you read the package description?

haawda commented on 2018-12-21 09:53 (UTC)

What is the point of this package? systemd provides pacman-hooks.