systemd-boot updater


Shouldn’t you be leaving those quotes to @petsam, why don’t you stick to quoting “The Art of War by Sun Tzu”. :slight_smile:


Preferably gitlab, but if you have any trouble in creating a repo, you can make it github and and I can migrate it to gitlab.


Getting the script to create boot entries for other systems makes it significantly more complicated and less reliable. I suggest that we start by supporting only the system it is run from. Then add support for launching other efi files, and maybe later detect other installations.


He that will not learn from others will be unable to learn from himself.
~ - ~ - ~ Chinese saying (that’s me, of course :grinning:)


I can confirm this.
After a fresh achitect vb installation (4.19), i added additional kernels 4.20 / 4.18.
Created only loader entries with copy & paste and it worked out of box.
That was pretty impressive.


Right, we have to change entries in loader directory (not loader.conf)
Still have to that?
Thought the script will generate entries for us?


I’m sure dalto creates entries in the future for us.
My reply was about bootloader updates.
I guess executing bootctl updateis only necessary if systemd has been updated.


I think we are talking about different things.

Presently, whenever there’s any kernel change (4.19 to 4.20, not 4.19 version xx to 4.19 version xy) we will need to change manually the entries to change the kernels.
Presently, ‘bootctl update’ and ‘bootctl install’ (after setting up systemd-boot) does nothing.

dalto’s script and if incorporated into ‘bootctl update’ which I requested is supposed to

Therefore shouldn’t ‘bootctl update’ be done whenever there’s a new kernel change if the script is incorporated into ‘bootctl update’? How then can the new kernel be booted if it is not done? Do it manually like presently? Or wait for a new systemd version update?

Is there something I miss so obviously?


I think the confusion is around how the script works. The script isn’t incorporated into bootctl update, it calls bootctl update.

bootctl is a binary so in order to get in the middle of that I would either have to patch systemd, somehow have a script called bootctl in higher priority path than the real bootctl or have something watching the files to see when the efi files were changed. None of those seem like the right thing to do.

So, if you wanted to manually update you would call the script instead of bootctl update. However, you normally wouldn’t have to do that since the script will get called automatically whenever kernels are changed.


Correct. I know.
I requested @Chrysostomus to include your script into “bootctl update” (usr/bin/bootctl update).
And included into pacman hooks (for bootctl install too). {Currently it isn’t}

Please note that whenever we install a new kernel, for grub, there is ‘update-grub’ so this new kernel will be in our boot menu automatically; we do not need to do this ‘update-grub’ by ourselves.
And correctly so.

Is this not wanted by you or by anybody using systemd-boot?
Do we still want to change the entries manually?

On a side note regarding my systemd-boot booting other non-systemd-boot OS on other $esp, this may not be suitable for me after all. It may cause my entries to try to boot the systemd OS with other (non-systemd-boot) kernels causing kernel panics. If @Chrysostomus proceeds successfully, I may have to find a way to disable it.


Yes, it works the exact same way. What happens is there is an alpm hook that watches for the kernel files to be installed/updated/removed. When that happens, it calls the script. It is fully transparent to the user. All the entry management is automatic unless you disable parts of it via config.

It just doesn’t have any relationship to “bootctl update”. I think this is where we have a communication disconnect.


I’ll answer you this way then.
Check out the script (it is a script, after all) at /usr/bin/update-grub.
It is

#! /bin/sh
grub-mkconfig -o /boot/grub/grub.cfg

So your script can be put into /usr/bin/bootctl install
And (together with bootctl install) be included into pacman hooks.



Let me put process in context here.

For grub:
An alpm hook calls the script update-grub which calls grub-mkconfig

For systemd-boot:
An alpm hook calls the script sdboot-update which calls bootctl update
An alpm hook calls the script sdboot-update which creates entries

For reference, sdboot-update is the script in question.

The difficultly I am having is with the statement:

I don’t understand what “can be put into” bootctl means.

It can be called before or called after but I am not sure I understand, ‘into’ in this context.


@dalto It’s very late here. I need to sleep soon.
Whatever, if you get it done, how that’s done, what’s the method or the theory, … it all doesn’t matter.
I just wish you all the best and thank you for it.

And… Cheers!!


If I understand you correctly we get two new pacman hooks and a configurable script for the entries.

Something likes this:


Type = Package
Operation = Upgrade
Target = systemd

Description = Updating systemd-boot
When = PostTransaction
Exec = /usr/bin/bootctl update

and something likes this:


Operation = Install
Operation = Upgrade
Operation = Remove
Type = File
Target = boot/vmlinuz*

Description = Update Bootloader Entries
When = PreTransaction
Exec = /usr/bin/?




I probably should just finish and upload it so everyone can see it. It isn’t nearly as complicated as it sounds talking about it in the abstract.


I will not mess with /usr/bin/bootctl, because then I would need to package systemd-boot, and that is too much work and responsibility for my current schedule. Instead, there would be a separate script, say, /usr/bin/update-bootctl. This script would then be automatically called by pacman hooks, just like update-grub.

So, the exact effect you are suggesting, but different file and different package.

This is exactly why I think think that the script should only handle the kernels of one installation, at least in the beginning. Reliably generating entries for other installations requires much more complicated logic and is much more prone to errors.


Yes, that makes much sense and thanks again for your input and contribution.

ps: in my case, where I do not wish to have this ‘interfering’ with my systemd-boot (multiple OS’s and non-systemd-boot OS’s), is it sufficient for me to just remove the hooks from /etc/pacman.d ? You can let us know after you’ve done the process. Thanks.
Note: when the OS ‘reuse’ the names of their kernel like vmlinuz-linux and initramfs-linux.img, there’s no need to amend the entries conf.

ps: I don’t use any OS grub either (I use my own) and therefore there’s no ‘interference’.


The process will be to uninstall the package. We could also add a configuration file to disable the automatics.


I finished the first pass of the luks support. I spent about 3 hours investigating luks and trying to figure out how to do this and it turned out to be about 6 lines of code. :slightly_frowning_face:

It will take a little bit of time to setup and test. There are a ton of scenarios with luks but I will probably limit my testing to:

  • luks->fs
  • lvm->luks->fs
  • luks->lvm->fs

I think it will work as long as you don’t have a multi-layered luks system like luks->lvm->luks->fs. Hopefully that isn’t super common.

I should be able get everything tested and uploaded by the weekend. I was hoping to get it done sooner but we hit some issues at work that have kept me tied up unexpectedly this week.

Already done. The configuration file accounts for this scenario and a few others. :smile: