I’m presently stress testing core Update 166 Development Build: next/3110d7a9, going though as many checks as I can particularly on the backup/restore side. Obviously, lots I won’t be able to check.
I don’t think a bug report is appropriate because a ‘next/’, being a ‘Work In Progress’, is possible that a number of the quirks I came across have probably already been resolved and we don’t want to sidetrack the deveolpers with unnecessary bug alerts.
Placing them here in a blog topic might have actual outstanding bugs overlooked by the folks working on fixes, and disappear off the radar.
My question is, where is the best place to post such findings ?
I just completed a full install of the recently released stable core 166, and then did a restore from a core 165 backup done using the suggested “cd / && backupctrl include” via console. The restore worked really well except for the logwatch files for the log summary (I will report that bug)
Restore tested items were.
. SSH Keys worked
. All graphs ok except the fwhits graph shows error already existing in 165. bug was reported.
. Connection scheduler, DNS, Web proxy, URL Filter, DHCP configs and fixed leases list, all ok
. Time server settings ok
. IPS rules all loaded. Only thing was service had to be started via the SAVE button.
. User fw rules, blue access devices, service groups and user services, location list, firewall options, iptable CUSTOMINPUT, all ok
. Firewall logs appear intact except the log summary.
( eg: /var/log/logwatch/2022-03-31 could not be opened ).
I have not yet tested a WebUI backup of 166 onto a fresh installed 166.
You lads have done a great job in nailing this one down. Two thumbs up !!!
I suspect that your 136MB backup is one that you did including logs.
The 25MB backup from 11:42, the time you did your CU166 update if I understand correctly, will be the backup that IPFire does automatically before any Core Update. However that backup is carried out excluding logs.
You can easily find out by opening the two files using a GUI based archiver, although you can also do it via the command line using an appropriate tar command to view or extract.
The backup .ipf file is basically a tar archiive.
If the backup has been done excluding logs then if you look in the archive in var/log/ you will find just two directories, rrd and vnstat.
You can confirm that the backup fix was implemented by looking in var/ipfire/ and there should be a minimum of 32 directories. There can be more depending on the addons that you have installed. If the ddns and dhcp directories are present then the fix has been applied and is working.
In the larger backup in the var/log/ directory there will be aadditional directories for pakfire, squid, squidGuard and suricata. Additionally there will be all the gzipped messages logs and the running messages log together with logfiles for pakfire, setup and dhcpcd.
Again looking in the var/ipfire/ directory will tell you if this backup was done before the fix or after. If the directories ddns and dhcp are not present then that backup is affected by the bug and should not be used.