[SOLVED] Some ALPM hooks fail - run manually?

schard · 2020-02-20 09:18:49

I just upgraded a couple of old systems.
Mostly the upgrade process went without any complications, except for these messages during the post-upgrade hooks:

Fehler: hook /usr/share/libalpm/hooks/30-systemd-update.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/30-systemd-udev-reload.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/30-systemd-tmpfiles.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/xorg-mkfontscale.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/20-systemd-sysusers.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/gio-querymodules-32.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/30-systemd-binfmt.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/30-systemd-hwdb.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/30-systemd-daemon-reload.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/update-mime-database.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/fontconfig.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/30-systemd-sysctl.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/fontconfig-32.hook line 2: invalid value Path
Fehler: hook /usr/share/libalpm/hooks/30-systemd-catalog.hook line 2: invalid value Path

I suspect, that the upgrade was performed with an older version of pacman / libalpm, that does not recognize some newly introduced hook settings.
Btw, here's the entire pacman.log: http://ix.io/2ccN

My questions are:
1) Is this a problem or can I ignore it?
2) If I cannot ignore it, can I run these hooks manually after the upgrade?

Last edited by schard (2020-02-20 14:56:56)

eschwartz · 2020-02-20 14:38:00

Unless the hook uses a NeedsTargets directive, you can simply run the Exec line by hand, so it's very easy to re-do the failing hooks. If it does use NeedsTargets then the Exec line will expect to receive the list of files or package names which triggered the hook, on stdin.

As for the errors: that would happen if you tried updating with an old version of pacman pre-5.2.0, but we did already have a news item about that for zstd support, so I was rather expecting people to have upgraded by now.

(The mentioned pacman-static recovery binary is likewise capable of handling Path directives.)

Last edited by eschwartz (2020-02-20 14:39:08)

schard · 2020-02-20 14:56:46

Thank you for your reply. I should have clarified, that I was looking for an easy way to re-run the hooks of the last transaction.
But if the only way is to look into any hook file and copy-paste-run the commands listed there, I'll rather wait until something comes up.
So far, after a reboot, the respective systems are running just fine.
Regarding the zst upgrade, I read that. But the system was up-to-date for that already, since the main issue, iirc, was some crypto-library which was already installed in a zst-compatible version back then.
I had another look into the pacman log, and the same transaction upgraded 5.1.3-1 -> 5.2.1-4. So yeah, you're right.

eschwartz · 2020-02-20 15:19:48

Most of those are 30-systemd* hooks that will run on a reboot anyway. Also:

update-mime-database
fc-cache -s
fc-cache-32 -s
gio-querymodules-32 /usr/lib32/gio/modules

And the xorg-mkfontscale hook, which does in fact need the targets, so some applications using x11 font manipulation directly instead of via fontconfig, will have an outdated view of fonts unless you manually reinstall the fonts from that transaction (manually reinstalling all packages from that transaction will definitely re-trigger the relevant hooks).

schard · 2020-02-20 15:27:26

Thanks for the heads up. But the respective systems actually do not run any X11 programs, that rely on system fonts.
So I think that I'll be fine leaving it as it is or wait for the next update that runs the respective hook again.

eschwartz · 2020-02-20 15:29:39

Sure, makes sense.

Still, go ahead and rerun the simple commands I mentioned anyway (if you haven't already).

schard · 2020-02-20 15:41:15

Aye aye! Did that. Turns out that

gio-querymodules-32 /usr/lib32/gio/modules

does not need to be run any longer, since the directory does not exist anymore.
Probably belonged to a package that was removed or updated to no longer contain these files.

Arch Linux

#1 2020-02-20 09:18:49

[SOLVED] Some ALPM hooks fail - run manually?

#2 2020-02-20 14:38:00

Re: [SOLVED] Some ALPM hooks fail - run manually?

#3 2020-02-20 14:56:46

Re: [SOLVED] Some ALPM hooks fail - run manually?

#4 2020-02-20 15:19:48

Re: [SOLVED] Some ALPM hooks fail - run manually?

#5 2020-02-20 15:27:26

Re: [SOLVED] Some ALPM hooks fail - run manually?

#6 2020-02-20 15:29:39

Re: [SOLVED] Some ALPM hooks fail - run manually?

#7 2020-02-20 15:41:15

Re: [SOLVED] Some ALPM hooks fail - run manually?

Board footer