This is saying to me that the time being checked by pakfire from an external time source has an offset to the time on your IPFire system. You need to check your time server settings and operation because it looks like your IPfire time server has the wrong time and if the delta is too large then pakfire cannot do the decryption check of the downloaded packages.
The decrypting process is a bit complex. There are some conditions for a fail.
Because mostly the reason is a wrong time, the error message is logged.
But a difference of -0.194280 should be negligible. There must be another reason for the failing.
Yes, based on your comment and the fact the progress seemed to always stall just over 90%… it gave me a theory.
For background, the IPFire instance is working in a VM as a firewall between internal LAN and a ‘secured’ LAN segment.
Due to the thin amount of firewall rules and no additional pakfire apps installed, it runs / ran with under 1GB RAM allocated.
After changing the allocation to 1GB the update completed…
So it would seem not enough RAM to complete an update action was the issue - I don’t want to say ‘low RAM’ as IPFire can work as a firewall and routing traffic quite easily with just 500MB RAM.
So… my fault I guess - not that the error messages helped out much.
You remembered me at times, when I saw these message very often.
The lifetime of my ALIX based IPFire.
I think to remember, that IPFire tries to put the decrypted file in RAM, maybe even an array in the pakfire program. This can function if you stop all memory consuming processes.
For a smooth update 1GB is recommended.
