The time difference is not enough to be causing a problem with pakfire working.
The most likely issue is that the DNS is not working as required.
On your WUI DNS page is your DNS showing a green Working at the top left hand side and if you press the Check DNS Servers button do all your DNS servers show up as a green OK?
Here is my directory after core 192 installed from scratch and restore frorm backup 190, both on rpi 4b.
Installed from scratch because update 190 → 192 walked through but crashed at reboot & fsck.
[root@ipfire .gnupg]# ls -la
total 16
drwx------ 2 root root 4096 Mar 16 21:15 .
drwxr-xr-x 3 root root 4096 Feb 20 03:34 …
-rw------- 1 root root 3444 Mar 15 11:02 pubring.gpg
-rw------- 1 root root 1161 Feb 20 03:34 pubring.gpg~
-rw------- 1 root root 0 Feb 20 03:34 secring.gpg
-rw------- 1 root root 0 Feb 20 03:34 trustdb.gpg
[root@ipfire .gnupg]#
These files cannot be found on github or did I miss something?
I’m going to have a look in older backups tomorrow in the evening…
I did a fresh install of CU192 yesterday and it has the trustdb.gpg with a date and time from when the install was done.
What I struggle with in your quoted list
is that the date is from Feb 20 2025, except for the pubring.gpg which has a date of Mar 15.
On my main production IPFire system, which was installed back in 2023, when my hardware died, then all the files have the same date of Jun 26 2023. So the pubring.gpg has not been altered in any way despite having every CU implemented between then and now.
I am struggling to figure out what has happened on your system and have been totally unable to reproduce it.
Restoring from previous versions will also not change these files as they are not in the backup.
I believe they are created as part of the pakfire updating lists etc process but I am not sure of that but they are present after the installation and don’t get changed again in any upgrade or restore process.
The pubring.gpg contains the two public keys that are in the git repo.
the .gpg dir seems not present inside img.gz, it seems be created atter update during boot. My older versions have a timstamp from 9th feb, but the content seems similar…
The only time anything has changed with what is created in the .gnupg directory was back in CU167 when the old 2007 IPFire key was deleted and the 2022 IPFire key was introduced.
This change was managed as part of the update.sh script for CU167.
No, the trustdb from 9th feb was from 190 and has content. Maybe it was recreated during the update to 190. The update to 191 had crashed my system so I did a new setup with 192 and a new stick and I was able to copy the file.
Reading up about the trustdb.gpg file it looks like it is initially created as part of the first importing of the keys that IPFire uses. It doesn’t get updated again until something changes, like an old key gets deleted and/or a new one gets created and imported.
The import of the 2018 and 2022 IPFire keys is done via the pakfire initscript that is run when IPFire is first installed and then at every reboot.
That’s the bit I don’t understand, as you are saying that you do a fresh install of CU192 and the trustdb.gpg file has a size of 0, after you have finished installation.
I have not been able to reproduce that.
The only other difference I see in our installations is that you are doing an aarch64 installation, whereas mine is a x86_64 one.
Someone else who has arm systems needs to try and do a fresh install of aarch64 and see if they end up with an empty trustdb.gpg file or not.
EDIT:
I had found out that since version 7.1.0 VirtualBox can run arm and macos virtual systems so I thought I would be able to test this out but the IPFire aarch64 iso is not seen as bootable by VirtualBox. I suspect this might be due to IPFire’s arm using uboot.
So still need someone else with an arm system that they can test out with a fresh install of CU192 to see what they find with the trustdb.gpg file.
