You are not logged in.
After upgrade:
[2026-08-13T08:49:36+0300] [ALPM] warning: /etc/tpm2-tss/fapi-profiles/P_ECCP384SHA384.json installed as /etc/tpm2-tss/fapi-profiles/P_ECCP384SHA384.json.pacnew
[2026-08-13T08:49:36+0300] [ALPM] warning: /etc/tpm2-tss/fapi-profiles/P_RSA3072SHA384.json installed as /etc/tpm2-tss/fapi-profiles/P_RSA3072SHA384.json.pacnew
[2026-08-13T08:49:36+0300] [ALPM] upgraded tpm2-tss (4.1.3-1 -> 4.2.0-2)As I can see, some values changed, some entries removed in jsons. I've never changed any defaults in /etc/tpm2-tss/.
Is it safe to simply rename *.json.pacnew to *.json?
Is it necessary to rename *.json.pacnew to *.json? If so, shouldn't "tpm2-tss >= 4.2.0 requires manual intervention" be announced?
Last edited by dimich (2026-08-13 11:14:39)
Offline
Looking at the upstream's changed files (switch tab to Changed files, then re-enter the URL to go to the relevant changes... ugh, GitHub), I agree this should be a news feed entry. The old profiles seem very incompatible to me with the changes listed.
Last edited by kescherArch (2026-08-13 07:21:37)
Offline
Is it necessary to rename *.json.pacnew to *.json? If so, shouldn't "tpm2-tss >= 4.2.0 requires manual intervention" be announced?
Yes, renaming *.json.pacnew to *.json is the solution and it definitely should have been announced that requires manual intervention.
Last edited by athan (2026-08-13 07:53:03)
Offline
I run pacdiff and this was an option, after inspection I realised I never changed anything so I overwrote the files. Is this not the way to do it?
Rlu: 222126
Offline
I run pacdiff and this was an option, after inspection I realised I never changed anything so I overwrote the files. Is this not the way to do it?
Running pacman-contrib's pacdiff here is equivalent to "renaming *.json.pacnew to *.json", so, yes, this is the way to do it.
Offline
I run pacdiff and this was an option, after inspection I realised I never changed anything so I overwrote the files. Is this not the way to do it?
did the same
although i had a play-around with my systems tpm some tine ago i learned it's not suitable for my needs and started to collect several usb tokens
but from a quick look: seems like a re-naming refactoring
so - is it required? if you use these specific algorithms ... i guess: yes - but it depends on whether you use your systems tpm at all - of not just removing tpm related packages shouldn't break any dependencies
Offline
so - is it required? if you use these specific algorithms ... i guess: yes - but it depends on whether you use your systems tpm at all
I don't but who knows what may get broken by invalid configuration..
of not just removing tpm related packages shouldn't break any dependencies
I wouldn't keep it installed at all, but for some reasons it's a dependency for gnupg (pacman, thunderbird) and libsecret (kicad, network-manager-applet). Omitting non-optional dependencies is quite risky.
Offline
cryptearth wrote:so - is it required? if you use these specific algorithms ... i guess: yes - but it depends on whether you use your systems tpm at all
I don't but who knows what may get broken by invalid configuration..
cryptearth wrote:of not just removing tpm related packages shouldn't break any dependencies
I wouldn't keep it installed at all, but for some reasons it's a dependency for gnupg (pacman, thunderbird) and libsecret (kicad, network-manager-applet). Omitting non-optional dependencies is quite risky.
I looked at this and wondered whether to try one of Seth's dummy packages, then I realised I don' t really know what this does so left it alone.
Rlu: 222126
Offline
See https://gitlab.archlinux.org/archlinux/ … 373ca7c55a which added backup entries for etc/tpm2-tss/fapi-profiles/P_ECCP384SHA384.json and etc/tpm2-tss/fapi-profiles/P_RSA3072SHA384.json which were provided by tpm2-tss 4.1.3-1 but not in the backup array so pacman encountered the files as provided by 4.1.3-1 with no default config record for that version triggering the .pacnew creation.
Last edited by loqs (2026-08-13 09:41:50)
Offline
were provided by tpm2-tss 4.1.3-1 but not in the backup array so pacman encountered the files as provided by 4.1.3-1 with no default config record for that version triggering the .pacnew creation.
Interesting. So it would work properly as incremental upgrade 4.1.3-1 -> 4.2.0-1 -> 4.2.0-2 but fails to handle unchanged configs because of direct jump from 4.1.3-1 to 4.2.0-2?
Offline
Interesting. So it would work properly as incremental upgrade 4.1.3-1 -> 4.2.0-1 -> 4.2.0-2 but fails to handle unchanged configs because of direct jump from 4.1.3-1 to 4.2.0-2?
You would get the issue on the first update to 4.2.0-1 or later as that is when the config files appear in the PKGBUILD's backup array so pacman then applies the backup array logic but with no old record so from what pacman can tell those config files must have changed so it creates .pacsaves of them.
Edit:
https://wiki.archlinux.org/title/Pacman … ve#.pacnew
original = X, current = Y, new = Z
All three versions are different, so leave the current version in place, install the new version with a .pacnew extension and warn the user about the new version. The user will be expected to manually merge any changes necessary from the new version into the current version.Rarely, when an upgraded package includes a backup file the previous version did not, the situation is correctly handled as X/Y/Y or X/Y/Z, with X being a non-existant value.
Last edited by loqs (2026-08-13 10:09:58)
Offline
Ok, 4.2.0-1 -> 4.2.0-2 has nothing to do with configs.
All three versions are different, so leave the current version in place, install the new version with a .pacnew extension and warn the user about the new version.
It was unexpected that there is three-way difference in the directory that never being modified. So the cause is that files included into backup list and their contents changed in the same upgrade?
Rarely, when an upgraded package includes a backup file the previous version did not, the situation is correctly handled as X/Y/Y or X/Y/Z, with X being a non-existant value.
It would be correctly handled if new version can successfully parse old file. I'm not sure it can for this particular upgrade.
Anyway, renamed *.json.pacnew to *.json and that's it. Marking as solved.
Offline
It was unexpected that there is three-way difference in the directory that never being modified. So the cause is that files included into backup list and their contents changed in the same upgrade?
Yes very unfortunate coincidence.
It would be correctly handled if new version can successfully parse old file. I'm not sure it can for this particular upgrade.
pacman only works off the hashes. Hopefully tpm-tss can parse both the old and new configs.
Offline
cryptearth wrote:of not just removing tpm related packages shouldn't break any dependencies
I wouldn't keep it installed at all, but for some reasons it's a dependency for gnupg (pacman, thunderbird) and libsecret (kicad, network-manager-applet). Omitting non-optional dependencies is quite risky.
and gnupg is a hard dependency for several other packages
i wasn't aware of it depending hard on tpm as i remember back when i gave up my tests i removed anything tpm and most gnupg related - but i'm not sure if something got stuck as i, too, got this yesterday ... so guess due to this dependency it's on my system, too - although i question why gnupg even does depend hard on anything tpm related as, although quite common, it should not be assumed that every hardware has one or have it enabled
Offline
for name in $(pacman -Qlq gnupg | grep -E '/usr/(bin|lib/gnupg)/.'); do ldd $name | grep tpm; doneI kinda doubt that this is an extremely hard dependency…
Offline
... | grep tpm
... | grep tss2/usr/lib/gnupg/tpm2daemon links it.
Last edited by dimich (2026-08-13 15:00:28)
Offline
well, although this isn't the place for this rant - but such are the things why i decided against getting into pgp - not because the pgp standard itself is bad - in fact it has quite some pros I'd like to have in my projects - but it's gnupg as de-facto implementation and all the issues it comes with
this seemingly random dependency drags in some stuff that should not be a hard requirement - as, as mentioned, it should not be expected that every system has a tpm or that it is enabled (in my case i have a am4 platform with a in-cpu ftmp - yet the bios allows me to disabled it - hence whatever gnupg thinks to achieve with that tpm daemon would just fail - and as tpm are not designed as long term key storage i doubt even gnupg tries something as stupid as to store a key inside a tpm)
but, same as with many other tiny "well, gnupg doesn't follow the pgp standard exactly here" things i guess gnupg devs yet again will find some stupid reason to keep this hard dependency instead of just make it optional as it should
sad to see that few devs of a project which became the de-facto implementation of an otherwise good standard cause so much trouble at each and every corner - hope sequoia-pgp gets some much needed momentum
Offline
https://github.com/gpg/gnupg/blob/1b8de … e.ac#L1608
The tpm2daemon is optional and implicitly disabled if tss2 is missing (also proving it's the only consumer) - you could
NoExtract = usr/lib/gnupg/tpm2daemonand dummy tpm2-tss, BUT the latter is also dependency for eg. libsecret (and fwupd) which itself is dependency for A LOT of stuff!
/usr/lib/libsecret-1.so links it, so FOR MOST USERS TPM2-TSS IS A HARD DEPENDENCY!
Also grrr: calling the package tpm2-tss but the libs are libtss2 is probably some long term PsyOp just to trick me!![]()
Last edited by seth (2026-08-14 06:14:00)
Offline
The tpm2daemon is optional and implicitly disabled if tss2 is missing
At build time, i.e. depends on build environment. Btw there is stack autodetection, it can be either ibm or intel.
It seems the right solution would be to split the package into gnupg and gnupg-tpm2 (or gnupg-tpm2-intel, gnupg-tpm2-ibm, if needed).
you could NoExtract = usr/lib/gnupg/tpm2daemon and dummy tpm2-tss
Yes, for gnupg it seems pretty safe to omit the dependency.
BUT the latter is also dependency for eg. libsecret
And it is enabled explicitly. That's the bigger problem.
Offline