I thought once the files are equal they should have the same PGP’s signatures shouldn’t they? Wonder if this PGP’s signatures difference is preventing me from pakfire update my system.
Are they supposed to be different?
Regards
G70P
Depending on various things the server-list.db can change over time. So it could depend on which mirror system you have compared it to and what time they last updated and also the last time that the filke was updated on your IPFire system.
I just looked on my system and the file was last updated at 04:00 today. I then pressed the update files button on pakfire and after that the files on my IPFire had a time of 13:31 from today.
The signature in the two files was different, and the latest version I downloaded had an extra server listed compared to the list from 04:00
I then updated again so the file time changed to 13:34 and now the signature in the file was the same as the one from 13:31
So update the files first then look at the file to see, but also check what the last time that the update of the mirror you are comparing it with was done.
Also if you look at the two lists that you show the first that you got from a mirror server has 22 mirror servers listed and the second list which you got from your IPFire system has 19 mirror servers listed. So the signatures will be different as the content of the file is different.
Thks Adolf,
The issue, of different, messages is resolved, if they aren’t equal of course the SHA512 must be diffrent. I Would like to understand how pakfire checks file integrity and signatures of files (PGP --verify), I can’t understand why pakfire is pushing me core 162
and that is the one was was provided when I did my last update at 13:34
ls -hal /opt/pakfire/db/lists/
total 24K
drwxr-xr-x 2 root root 4.0K Feb 5 13:34 .
drwxr-xr-x 7 root root 4.0K Jun 26 2023 ..
-rw-r--r-- 1 root root 903 Feb 5 13:34 core-list.db
-rw-r--r-- 1 root root 5.2K Feb 5 13:34 packages_list.db
-rw-r--r-- 1 root root 2.0K Feb 5 13:34 server-list.db
I would suggest pressing the Refresh list button again on the Pakfire WUI page.
From your listing it looks like somehow you only updated the core-list.db file because the packages_list.db and server-list .db files are much older - from 22:27 and 22:37 on 4th Feb.
Using the pakfire Refresh list button updates all the files at the same time.
I notice that your url has ipfire/pakfire2/2.27/lists/
while the correct location is ipfire/pakfire2/2.27-x86_64/lists
for x86_64 or
ipfire/pakfire2/2.27-aarch64/lists
for aarch64 (arm systems).
Can you please show the pakfire logs for the download of the core-list.db, packages_list.db and server-list.db files. I would like to see if there are any messages that can give a clue why pakfire tried to download from the wrong directory location and then failed to download and update the packages and server lists.
has 184 listed so it looks like the .1 and .2 versions are for the testing and unstable, although that is a guess on my part. You would have to go through the code to figure out how it does this.
Either way, that is why pakfire is used for this as it knows which directories in the mirrors to go to to get the required lists etc.
@g70p are you trying to download the files using pakfire or are you attempting to manually download the files from the mirror directories?
I thought that at first but there are earlier major versions such as 2.25 and 2.23 that also have the directories split by architecture so there must be a different reason for the split.
I also wondered about the change in the download file naming but that occurred around CU170 so would not have had the splits in earlier major versions.
If someone is really interested in that then they need to go and read the code for pakfire.cgi and the pakfire application to figure out what is being done.
Pakfire is doing its job well for me.
We just need to understand if the problem of accessing the incorrect mirror directory is a bug in pakfire or not.
After 182 official release I changed to 182 stable.
Last week I tweaked some firewall rules and also started using internal DNS servers with portforward as described in optimization.
I also added libvirt and qemu (for learning and future use) and turned on webproxy.
The logs weren’t catching ipadresses neither locationblock
Afterthen pakfire stoped working (I thought it would be because of webproxy because wget was showing SSL errors)
I looked for pakfire config and tested the only use one mirror.
Once only one mirror was not working too I got back to lists.db. I thought that 2.27 without dash (/) would contact 2.27-x86_64. Ok my mistake
just shutdown PC with firewall and doesn’t turn on
From here I m unable to go further.
So might be in the process and changes I did something … no bugs.
Thank you for your help.
.
Is it that nothing happens at all when you turn it on. No characters at all on the screen, absolutely nothing.
If that is the case then that sounds more like a hardware problem that the PC has died.
If IPFire starts and gets to the grub menu but then stops then that could be that your change to 182 stable did not actually update to the latest changes in 182, such as the reversion of the grub change. However that grub issue would not have had any relationship to the problems you had with logs not catching anything or pakfire not working.
When you did the change to 182 stable, did you just change the branch from Testing to Stable on the Pakfire WUI page.
If so then pakfire will not have updated anything as it will have considered that the system was already at 182.
There is a way to force the update by decrementing the value in /opt/pakfire/db/core/mine but this requires you to be able to actually start your system.
If it is not starting at all then I would suggest your best bet might be to do a fresh install of 182 and then do a restore of your backup.
One thing I forgot is that you would only be affected by the original grub bug in Core Update 182 if you have installed your IPFire using an xfs file system rather than an ext4 file system.
Which file system did you use when you originally installed IPFire on your system?
@bonnietwin
Actually it was a hardware problem. I changed the Power Suply and it turned on.
Perfect.
Actually by mistake I was blocking ICMP from Red to Green in firewall.
As well the DNS server was pointing to LAN and Gateway but was missing some public IP as 8.8.8.8. This together was preventing pakfire from http connection to servers.
Meanhile I added -x86_64 to the lists. Update the 3 files in db directory as well is performing info and addons with 200 OK
Is working now like a charm.
I appreciate and I’m thankfull for helping and ackowledge it was a human error - mine.
