Intermittent failure with update hook

[eagleflo]

Thanks for writing this script! It's the cleanest way I've found to get small unified kernel images via booster + sbctl to work.

However, a couple of times now the update hook has somehow failed. Here is what I see in the console:

(10/17) Updating linux booster images...
(11/17) Updating UKI files...
error: command failed to execute correctly
(12/17) Removing orphaned EFI entries...
(13/17) Compiling GSettings XML schema files...
(14/17) Updating icon theme caches...
(15/17) Update Nvidia module in initcpio
(16/17) Updating the desktop file MIME type cache...
(17/17) Signing EFI binaries...

This results in a system that doesn't boot unless I catch it before rebooting. In this case both booster-linux.img and vmlinuz-linux are left on /boot. I can "fix" this by just running sudo booster-um -G manually afterwards. Could it be some sort of timing issue or conflict with the booster hook?

The frustrating thing is that the error message doesn't give me any hint towards what has gone wrong. Similarly, /var/log/pacman.log is silent on the matter -- it looks like all three of these hooks ran normally, which is not the case:

[2025-09-12T16:40:08+0300] [ALPM] running '90-booster-install.hook'...
[2025-09-12T16:40:09+0300] [ALPM] running '90-booster-um-install.hook'...
[2025-09-12T16:40:10+0300] [ALPM] running '91-booster-um-efi-remove.hook'...

Here's the entire run from pacman.log:

[2025-09-12T16:39:43+0300] [PACMAN] Running 'pacman -Syu'
[2025-09-12T16:39:43+0300] [PACMAN] synchronizing package lists
[2025-09-12T16:39:43+0300] [PACMAN] starting full system upgrade
[2025-09-12T16:39:55+0300] [ALPM] running '60-booster-remove.hook'...
[2025-09-12T16:39:55+0300] [ALPM] running '60-booster-um-remove.hook'...
[2025-09-12T16:39:57+0300] [ALPM-SCRIPTLET] 1;33m==> Removing UKI for 1;32mlinux (6.16.6-arch1-1)...
[2025-09-12T16:39:57+0300] [ALPM-SCRIPTLET]   1;33m-> Removing 1;32mlinux leftovers from 1;33m/boot...
[2025-09-12T16:39:57+0300] [ALPM-SCRIPTLET]   1;33m-> Removing 1;33m/boot/EFI/Linux/arch-linux.efi file...
[2025-09-12T16:39:57+0300] [ALPM-SCRIPTLET]   Removed /boot/EFI/Linux/arch-linux.efi from the database.
[2025-09-12T16:39:57+0300] [ALPM-SCRIPTLET] 1;32m==> Done
[2025-09-12T16:39:57+0300] [ALPM] running '71-dkms-remove.hook'...
[2025-09-12T16:39:57+0300] [ALPM] transaction started
[2025-09-12T16:39:57+0300] [ALPM] upgraded alsa-card-profiles (1:1.4.7-1 -> 1:1.4.8-1)
[2025-09-12T16:39:57+0300] [ALPM] upgraded apache (2.4.65-1 -> 2.4.65-3)
[2025-09-12T16:39:57+0300] [ALPM] upgraded nss (3.115.1-1 -> 3.116-1)
[2025-09-12T16:39:57+0300] [ALPM] upgraded freetype2 (2.14.0-2 -> 2.14.1-1)
[2025-09-12T16:39:57+0300] [ALPM] upgraded ca-certificates-mozilla (3.115.1-1 -> 3.116-1)
[2025-09-12T16:39:57+0300] [ALPM] upgraded bazel (8.4.0-1 -> 8.4.1-1)
[2025-09-12T16:39:57+0300] [ALPM] upgraded deno (2.4.5-1 -> 2.5.0-1)
[2025-09-12T16:39:58+0300] [ALPM] upgraded electron36 (36.8.1-1 -> 36.9.0-1)
[2025-09-12T16:39:58+0300] [ALPM] upgraded electron37 (37.4.0-1 -> 37.5.0-1)
[2025-09-12T16:39:58+0300] [ALPM] upgraded libpipewire (1:1.4.7-1 -> 1:1.4.8-1)
[2025-09-12T16:39:58+0300] [ALPM] upgraded pipewire (1:1.4.7-1 -> 1:1.4.8-1)
[2025-09-12T16:39:58+0300] [ALPM] upgraded pipewire-audio (1:1.4.7-1 -> 1:1.4.8-1)
[2025-09-12T16:39:58+0300] [ALPM] upgraded gst-plugin-pipewire (1:1.4.7-1 -> 1:1.4.8-1)
[2025-09-12T16:39:58+0300] [ALPM] upgraded lib32-freetype2 (2.14.0-2 -> 2.14.1-1)
[2025-09-12T16:39:58+0300] [ALPM] upgraded lib32-libpipewire (1:1.4.7-1 -> 1:1.4.8-1)
[2025-09-12T16:39:58+0300] [ALPM] upgraded lib32-nss (3.115.1-1 -> 3.116-1)
[2025-09-12T16:39:58+0300] [ALPM] upgraded lib32-pipewire (1:1.4.7-1 -> 1:1.4.8-1)
[2025-09-12T16:39:58+0300] [ALPM] upgraded libphonenumber (1:9.0.13-1 -> 1:9.0.14-1)
[2025-09-12T16:39:59+0300] [ALPM] upgraded linux (6.16.6.arch1-1 -> 6.16.7.arch1-1)
[2025-09-12T16:40:01+0300] [ALPM] upgraded linux-headers (6.16.6.arch1-1 -> 6.16.7.arch1-1)
[2025-09-12T16:40:01+0300] [ALPM] upgraded nvidia-open (580.82.09-1 -> 580.82.09-2)
[2025-09-12T16:40:01+0300] [ALPM] upgraded pipewire-jack (1:1.4.7-1 -> 1:1.4.8-1)
[2025-09-12T16:40:01+0300] [ALPM] upgraded pipewire-pulse (1:1.4.7-1 -> 1:1.4.8-1)
[2025-09-12T16:40:02+0300] [ALPM] upgraded python-scipy (1.16.1-1 -> 1.16.2-1)
[2025-09-12T16:40:04+0300] [ALPM] upgraded signal-desktop (7.69.0-1 -> 7.70.0-1)
[2025-09-12T16:40:04+0300] [ALPM] upgraded zed (0.202.8-2 -> 0.203.5-1)
[2025-09-12T16:40:04+0300] [ALPM] transaction completed
[2025-09-12T16:40:05+0300] [ALPM] running '30-systemd-daemon-reload-system.hook'...
[2025-09-12T16:40:05+0300] [ALPM] running '30-systemd-daemon-reload-user.hook'...
[2025-09-12T16:40:06+0300] [ALPM] running '30-systemd-restart-marked.hook'...
[2025-09-12T16:40:06+0300] [ALPM] running '30-systemd-tmpfiles.hook'...
[2025-09-12T16:40:06+0300] [ALPM] running '30-systemd-udev-reload.hook'...
[2025-09-12T16:40:07+0300] [ALPM] running '30-systemd-update.hook'...
[2025-09-12T16:40:07+0300] [ALPM] running '40-update-ca-trust.hook'...
[2025-09-12T16:40:07+0300] [ALPM] running '60-depmod.hook'...
[2025-09-12T16:40:08+0300] [ALPM] running '70-dkms-install.hook'...
[2025-09-12T16:40:08+0300] [ALPM] running '90-booster-install.hook'...
[2025-09-12T16:40:09+0300] [ALPM] running '90-booster-um-install.hook'...
[2025-09-12T16:40:10+0300] [ALPM] running '91-booster-um-efi-remove.hook'...
[2025-09-12T16:40:10+0300] [ALPM] running 'glib-compile-schemas.hook'...
[2025-09-12T16:40:11+0300] [ALPM] running 'gtk-update-icon-cache.hook'...
[2025-09-12T16:40:12+0300] [ALPM] running 'nvidia.hook'...
[2025-09-12T16:40:12+0300] [ALPM] running 'update-desktop-database.hook'...
[2025-09-12T16:40:12+0300] [ALPM] running 'zz-sbctl.hook'...
[2025-09-12T16:40:12+0300] [ALPM-SCRIPTLET] Generating EFI bundles....
[2025-09-12T16:40:12+0300] [ALPM-SCRIPTLET] File has already been signed /boot/EFI/Boot/bootx64.efi
[2025-09-12T16:40:12+0300] [ALPM-SCRIPTLET] File has already been signed /boot/EFI/systemd/systemd-bootx64.efi
[2025-09-12T16:40:12+0300] [ALPM-SCRIPTLET] File has already been signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed

[Zile995]

Hi, thanks for using the script.

This is an interesting problem, people had a similar one with mkinicpio. Maybe you don't have enough space on the /boot partition? Is ESP mounted on /boot? I recommend it to be /efi, it takes up less space on the ESP because the initramfs and kernel are generated on the root partition.

Installation seems to fail after the 90-booster-um-install.hook. This hook calls the /usr/share/libalpm/scripts/booster-um-install script. You can debug that script with -x option. Start it with bash:

sudo bash -x /usr/share/libalpm/scripts/booster-um-install

After this command, just press the enter. The script will run the booster-um -G command, which you can see in this debug mode

+ set -x
+ declare -g SIGN_ALL=1
+ declare -g ALL=1
+ declare -A kernels
+ sorted_pkgbases=()
+ declare -a sorted_pkgbases
+ read -r line

+ case "$line" in
+ ALL=0
+ break
+ [[ 1 -eq 0 ]]
+ export ALWAYS_SIGN=1
+ ALWAYS_SIGN=1
+ [[ 0 -eq 0 ]]
+ booster-um -G

Maybe your problem only exists when only one kernel is updated? In that case, booster-um -u is called.

If you want to debug booster-um script, edit the /usr/bin/booster-um and change the set -e to set -x

[eagleflo]

Yeah, my background is that I dualboot and the original Windows installation media only created a 100MB EFI System Partition way back when. ESP is mounted as /boot.

For a long while mkinitcpio worked fine as long as I didn't keep a fallback image around and compressed the image heavily, but a while ago something happened and mkinitcpio started generating images over 80MB in size -- hence why I searched for and found booster and booster-um in turn.

In comparison,

~ % du -h /boot/EFI/Linux/arch-linux.efi
20M     /boot/EFI/Linux/arch-linux.efi

---

Happened to catch this again, ran the command suggested:

:: Running post-transaction hooks...
(1/9) Reloading user manager configuration...
(2/9) Arming ConditionNeedsUpdate...
(3/9) Updating module dependencies...
(4/9) Install DKMS modules
(5/9) Updating linux booster images...
(6/9) Updating UKI files...
error: command failed to execute correctly
(7/9) Removing orphaned EFI entries...
(8/9) Update Nvidia module in initcpio
(9/9) Signing EFI binaries...
Generating EFI bundles....
File has already been signed /boot/EFI/Boot/bootx64.efi
File has already been signed /boot/EFI/systemd/systemd-bootx64.efi
File has already been signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed

~ % sudo bash -x /usr/share/libalpm/scripts/booster-um-install
+ set -e
+ declare -g SIGN_ALL=1
+ declare -g ALL=1
+ declare -A kernels
+ sorted_pkgbases=()
+ declare -a sorted_pkgbases
+ read -r line

+ case "$line" in
+ ALL=0
+ break
+ [[ 1 -eq 0 ]]
+ export ALWAYS_SIGN=1
+ ALWAYS_SIGN=1
+ [[ 0 -eq 0 ]]
+ booster-um -G
:: Generating UKI files for all installed kernels...
==> Generating initramfs for linux...
--------------------------------------------------
==> Generating UKI for linux (6.16.8-arch1-1)...
  -> Using the cmdline from /etc/kernel/cmdline...
Splash image /usr/share/systemd/bootctl/splash-arch.bmp is 566×167 pixels
Wrote unsigned /boot/EFI/Linux/arch-linux.efi
  ✓ Signed /boot/EFI/Linux/arch-linux.efi
  -> Removing linux leftovers from /boot...
==> Done
+ exit

Seems like everything worked correctly on this second invocation?

I've now manually changed booster-um from set -e to set -x, hopefully next time I catch what's going wrong.

[eagleflo]

I recommend it to be /efi, it takes up less space on the ESP because the initramfs and kernel are generated on the root partition.

Wait, so these images don't have to be on the ESP? I guess I've completely misunderstood something then. I followed Arch Linux wiki back when I set this system up. I'm using systemd-boot if it makes any difference.

If I understood you correctly, I should change my environment so that the kernel image and initramfs are created on the root filesystem?

[Zile995]

Wait, so these images don't have to be on the ESP? I guess I've completely misunderstood something then. I followed Arch Linux wiki back when I set this system up. I'm using systemd-boot if it makes any difference.

Yes, they don't have to be on the ESP, they are always generated inside the /boot, but since you mounted the ESP to /boot, they will always be created on the ESP. The system will fill your ESP less if it is mounted to /efi. Although the files are generated individually, at one moment you can have 3 files on the ESP partition (a new vmlinuz, initramfs and old UKI)

• Typical mount points

  • It says the following for the /efi mount:

    • It avoids increasing the size requirement of the ESP by not placing the files installed to /boot in it: only the EFI binaries (the boot loader (and optionally drivers) and/or the unified kernel image) will be stored on the ESP, which saves storage space.

  • In case the ESP is not mounted to /boot, then the /boot is an ordinary directory on the / partition. The kernel and initramfs are only generated inside the /boot directory. In case of the booster-um, if you mount an EFI System partition to /efi, only the UKI files will be created on the ESP and the vmlinuz and initramfs images will be generated inside the /boot directory, and later they will be deleted because they are unnecessary.

• About systemd-boot installation path

  • It says the following:

    • --esp-path=
      Path to the EFI System Partition (ESP). If not specified, /efi/, /boot/, and /boot/efi/ are checked in turn. It is recommended to mount the ESP to /efi/, if possible.

  • So, the systemd-boot can be installed to /efi and is the recommended mount point for the ESP.

If I understood you correctly, I should change my environment so that the kernel image and initramfs are created on the root filesystem?

This is just my suggestion if you have a problem with the ESP size.

You can also try installing a new XBOOTLDR partition, you will have more free space. The systemd-boot can even detect the XBOOTLDR. The XBOOTLDR partition has to be mounted to /boot and the booster-um can also detect it.

Maybe the free space on the ESP is not the cause of your problem, but since this kind of problem has not happened on my system yet, it is really hard to fix it without debugging the script.

[Zile995]

Seems like everything worked correctly on this second invocation?

I've now manually changed booster-um from set -e to set -x, hopefully next time I catch what's going wrong.

Yes, it worked correctly. Did this happen on kernel update, or firmware/dkms update?
You can also try to debug the /usr/share/libalpm/scripts/booster-um-install script, just set the set -x inside it.

[eagleflo]

After setting set -x the script worked automatically for more than a month without issues, just printing a bit more output on each update.

This week my NVMe drive broke and I had to do a reinstall (which lost the earlier manual set -x changes). Today I got the first kernel update.

( 9/14) Updating UKI files...
error: command failed to execute correctly
(10/14) Removing orphaned EFI entries...
(11/14) Reloading system bus configuration...
(12/14) Compiling GSettings XML schema files...
(13/14) Updating the info directory file...
(14/14) Signing EFI binaries...
Generating EFI bundles....

Once again, manually running sudo booster-um -G immediately afterwards completes without any issue and creates the expected UKI file.

Does this imply there is a timing component to this; maybe with set -x the script runs just slow enough that everything happens to work?

I'll manually do the set -x change again to both booster-um and booster-um-install, but I fear that will again mask whatever is the root of this (slow operations on ESP with VFAT or something).

(This is not an urgent issue for me as the set -x seems to make it go away, but I want to help figuring out which part exactly is failing here and how to take that into account in the script.)

[eagleflo]

Maybe there is some more detailed logging I could add manually to get a better sense of which operation is failing?

[Zile995]

Does this imply there is a timing component to this; maybe with set -x the script runs just slow enough that everything happens to work?

Really strange that set -x shows no errors. I mean, you can run pacman -Syu update with the --verbose option, but I doubt it will print more debug errors.

How do you mount an EFI partition and what are your mount options? Did you mount it in /etc/fstab or does systemd mount it automatically?

I am preparing a new stable release with new options and fixes. I might add an option for verbose output when the booster generates the initramfs.

By the way, I read your blog. Thank you very much for mentioning this script.
You mentioned the following in your blog:

The only little snag I hit was that I had created a custom pacman hook for running mkinitcpio -P whenever kernel or Nvidia drivers updated. Of course, I needed to switch that invocation to booster-um -G after removing mkinitcpio entirely

Well, you don't have to create a new hook. The booster-um takes care of that, if any dkms modules or nvidia modules are updated, booster-um will regenerate UKI for all kernels. Please, delete all redundant hooks if there are any.

[eagleflo]

Thank you for reading the blog! I realized that the hook was redundant with this reinstall. I updated the post. No redundant hooks were present with this most recent update.

I mount the ESP via /etc/fstab, originally generated via genfstab -U /mnt.

UUID=F2E3-A474  /boot  vfat  rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro  0 2

The relevant bits of fdisk -l:

Disk /dev/nvme2n1: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 980 PRO 1TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1FFA4540-45EE-11EB-9D57-50EB7110FAF3

Device           Start        End    Sectors   Size Type
/dev/nvme2n1p1    2048    1085447    1083400   529M Windows recovery environment
/dev/nvme2n1p2 1085448    1290255     204808   100M EFI System
/dev/nvme2n1p3 1290256    1323031      32776    16M Microsoft reserved
/dev/nvme2n1p4 1323032 1953525063 1952202032 930,9G Microsoft basic data


Disk /dev/nvme0n1: 1,82 TiB, 2000398934016 bytes, 488378646 sectors
Disk model: WD_BLACK SN850X 2000GB
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: C7D65508-1886-411A-B082-910BF2F469AC

Device         Start       End   Sectors  Size Type
/dev/nvme0n1p1   256 488378640 488378385  1,8T Linux filesystem

at one moment you can have 3 files on the ESP partition (a new vmlinuz, initramfs and old UKI)

I think these three just barely fit that 100M all at once until the cleanup step runs, or I would have seen write errors related to ESP getting full, which was the signal for me to look for alternatives to mkinitcpio.

One stray thought:

% ls /usr/share/libalpm/hooks | rg booster
60-booster-remove.hook
60-booster-um-remove.hook
90-booster-install.hook
90-booster-um-install.hook
91-booster-um-efi-remove.hook

Could it be that these hooks are competing with each other? The booster hooks should obviously run before booster-um hooks based on alphabetical ordering, but somehow the set -x modification made this problem disappear for a whole month -- maybe giving more time for /usr/share/libalpm/scripts/booster-install to complete booster build --force --kernel-version ${kernel##/usr/lib/modules/} /boot/booster-${pkgbase}.img & or something.

Doesn't that & make it run in the background, so that 90-booster-install.hook "finishes" early and 90-booster-um-install.hook starts running right away?

Sorry, I'm grasping at straws here.

---

You can also try installing a new XBOOTLDR partition, you will have more free space. The systemd-boot can even detect the XBOOTLDR. The XBOOTLDR partition has to be mounted to /boot and the booster-um can also detect it.

This sounds like an interesting avenue to explore, thanks!

[Zile995]

Thank you for reading the blog! I realized that the hook was redundant with this reinstall. I updated the post. No redundant hooks were present with this most recent update.

You're welcome and thanks for the quick update.

I mount the ESP via /etc/fstab, originally generated via genfstab -U /mnt.

UUID=F2E3-A474  /boot  vfat  rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro  0 2

It seems ok. This is how I mounted it in the fstab file, it should enforce better ESP permissions and suppress/fix all systemd-boot warnings.

# /dev/nvme0n1p1
LABEL=EFI    /efi    vfat    rw,nosuid,nodev,noexec,relatime,nosymfollow,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro    0 2

---

...maybe giving more time for /usr/share/libalpm/scripts/booster-install to complete booster build --force --kernel-version ${kernel##/usr/lib/modules/} /boot/booster-${pkgbase}.img & or something.

Doesn't that & make it run in the background, so that 90-booster-install.hook "finishes" early and 90-booster-um-install.hook starts running right away?

No, there is a wait command inside the function, so only the booster command runs in the background while the main bash script, or to be precise a function, waits for it's completion.