IPFire 202 Test: Restoring a 201 backup after upgrading to 202

Installing & Running IPFire Testing
1

For future users’ information:

Problem on restart after restoration

Setting up firewall
iptables v1.8.13 (legacy): owner: Bad value for "--uid-owner" option: "unbound"
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.8.13 (legacy): owner: Bad value for "--uid-owner" option: "unbound"
Try `iptables -h' or 'iptables --help' for more information.
...
[1778514171] unbound-control[26944:0] error: connect: Connection refused for 127.0.0.1 port 8953
DNS not functioning... 
...

The /etc/passwd and /etc/group files were overwritten by the backup; the new unbound user was deleted.

2

if I read this correctly, unbound was running via “nobody” and now it is run via “unbound”.

https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/rootfiles/core/202/update.sh;hb=9f5a87822cd6d5826935e3caebffbdcb239edfe7#l97

I don’t know the fix…

3

I have put a patch in to backup.pl that will create the unbound user when doing a restore.

It was merged into master two hours ago.

4

you might need to add another line that updates the config file and the zonefiles.

https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/rootfiles/core/202/update.sh;hb=9f5a87822cd6d5826935e3caebffbdcb239edfe7#l129

5

Thanks @bonnietwin,

I just ran the test again

  • Installed the CU 202 ISO released last night
    The /var/ipfire/backup/bin/backup.pl file is indeed the one you corrected

But the restore backup CU201 overwrote the unbound user account again without restoring it

Due to errors in the untar file

I made a trace by cutting (…) portions of the untar log:

[root@ipfire bin]# ./backup.pl restore /var/ipfire/backup/2026-05-12-1154.ipf
[12:24:30 backup.pl:493] main restore /var/ipfire/backup/2026-05-12-1154.ipf
[12:24:30 backup.pl:421] local command=restore
[12:24:30 backup.pl:422] shift
[12:24:30 backup.pl:424] case "${command}" in
[12:24:30 backup.pl:446] local filename=/var/ipfire/backup/2026-05-12-1154.ipf
[12:24:30 backup.pl:448] '[' -z /var/ipfire/backup/2026-05-12-1154.ipf ']'
[12:24:30 backup.pl:452] restore_backup /var/ipfire/backup/2026-05-12-1154.ipf
[12:24:30 backup.pl:78] local filename=/var/ipfire/backup/2026-05-12-1154.ipf
[12:24:30 backup.pl:82] /etc/rc.d/init.d/collectd stop
Stopping Collection daemon...                                                                                                                                       [  OK  ]
[12:24:31 backup.pl:86] rm -f /var/ipfire/ovpn/certs/index.txt /var/ipfire/ovpn/certs/index.txt.attr /var/ipfire/ovpn/certs/index.txt.attr.old /var/ipfire/ovpn/certs/index.txt.old /var/ipfire/ovpn/certs/matebookcert.pem /var/ipfire/ovpn/certs/matebook.p12 /var/ipfire/ovpn/certs/redminote13cert.pem /var/ipfire/ovpn/certs/redminote13.p12 /var/ipfire/ovpn/certs/serial /var/ipfire/ovpn/certs/serial.old /var/ipfire/ovpn/certs/servercert.pem /var/ipfire/ovpn/certs/serverkey.pem /var/ipfire/ovpn/certs/tab16cert.pem /var/ipfire/ovpn/certs/tab16.p12 /var/ipfire/ovpn/certs/ta.key
[12:24:31 backup.pl:89] tar xvzpf /var/ipfire/backup/2026-05-12-1154.ipf -C / --exclude-from=/var/ipfire/backup/exclude --exclude-from=/var/ipfire/backup/exclude.user --force-local
etc/group
etc/hosts
etc/hosts.allow
etc/hosts.deny
etc/httpd/server-ecdsa.crt
etc/httpd/server-ecdsa.csr
etc/httpd/server-ecdsa.key
etc/ipsec.user.conf
etc/ipsec.user.secrets
etc/locale.conf
etc/logrotate.d/
etc/logrotate.d/.empty
etc/passwd
etc/shadow
...
tar: var/ipfire/urlfilter/blacklists/aggressive: Cannot create symlink to ‘agressif’: File exists
var/ipfire/urlfilter/blacklists/jobsearch/
var/ipfire/urlfilter/blacklists/jobsearch/usage
...
tar: var/ipfire/urlfilter/blacklists/proxy: Cannot create symlink to ‘redirector’: File exists
var/ipfire/urlfilter/blacklists/dating/
var/ipfire/urlfilter/blacklists/dating/usage
...
var/ipfire/urlfilter/blacklists/ads
tar: var/ipfire/urlfilter/blacklists/ads: Cannot create symlink to ‘publicite’: File exists
var/ipfire/urlfilter/blacklists/sports/
...
var/ipfire/urlfilter/blacklists/mail
tar: var/ipfire/urlfilter/blacklists/mail: Cannot create symlink to ‘forums’: File exists
var/ipfire/urlfilter/blacklists/fakenews/
var/ipfire/urlfilter/blacklists/fakenews/usage
var/ipfire/urlfilter/blacklists/fakenews/domains
var/ipfire/urlfilter/blacklists/drugs
tar: var/ipfire/urlfilter/blacklists/drugs: Cannot create symlink to ‘drogue’: File exists
var/ipfire/urlfilter/blacklists/dialer/
var/ipfire/urlfilter/blacklists/dialer/usage
...
var/ipfire/urlfilter/blacklists/webhosting/domains
var/ipfire/urlfilter/blacklists/porn
tar: var/ipfire/urlfilter/blacklists/porn: Cannot create symlink to ‘adult’: File exists
var/ipfire/urlfilter/blacklists/violence
tar: var/ipfire/urlfilter/blacklists/violence: Cannot create symlink to ‘agressif’: File exists
var/ipfire/urlfilter/blacklists/forums/
var/ipfire/urlfilter/blacklists/forums/expressions
...
var/ipfire/urlfilter/settings
var/ipfire/urlfilter/squidGuard.conf
...
etc/default/grub
etc/default/grub.console
etc/default/grub.iommu
etc/default/grub.serial
etc/default/grub.serial.silent
etc/httpd/conf/vhosts.d/wpad.conf
srv/web/ipfire/wpad/
srv/web/ipfire/wpad/wpad.dat
srv/web/ipfire/wpad/proxy.pac
srv/web/ipfire/wpad/proxy.pac
srv/web/ipfire/wpad/wpad.dat
usr/local/bin/autoshutdown_off.sh
tar: Exiting with failure status due to previous errors
[12:24:33 backup.pl:93] echo 'Could not extract backup'
Could not extract backup
[12:24:33 backup.pl:94] return 1
[12:24:33 backup.pl:490] return 1
[12:24:33 backup.pl:493] exit 1
[root@ipfire bin]#

Edit : I deleted /var/ipfire/urlfilter/blacklists/*
And the restore went smoothly with the unbound user

6

I forgot to ship the modified backup.pl file so it was not installed as part of the Core Update. The ship commit was merged around an hour ago.

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=9c65846ad50851ee6de91b1ddf47d662a4390183

However a fresh iso install should have had the updated backup.pl and you say it did have so I don’t understand why the unbound user was not re-created unless your restore failed before the addition of the unbound user.

I tried the change by manually adding it to a Core Update system and it worked fine for me both with a restore of a version without the unbound users and then a restore of a version with the unbound user.

The errors you show are nothing to do with the DNS Firewall or unbound.

They are when the University of Toulouse URL Filter lists are restored. If you download the whole list, as url filter does, then some of the entries are symlinks because for example the original advertising list was called publicite and they created a symlink from publicite to ads but if you download the individual lists then they actually have an ads list and a publicite list but the contents are identical.

7

The backup.pl file I installed this morning with te ISO is indeed the one you corrected ( Commit: da1960a8f38d1a1d1ae5855703b8f60432389f1e).

https://nightly.ipfire.org/master/latest/x86_64/ipfire-2.29-core202-x86_64.iso
IPFire 2.29 (x86_64) - Core-Update 202 Development Build: master/da1960a8

If you saw my edit, the user unbound was indeed added on my second attempt.

I agree with you about the source of the errors, but:
1 - They should be taken into account (I can’t be the only user on the Toulouse list.).
2 - They shouldn’t prevent the creation of the unbound user (untar exit 1 line 92).

But again, these are just tests.

If my tests are unnecessary, you can ignore them.

8

Something must have changed somewhere.

I just checked the backup I restored from in my test and it was from CU199 and it had the Toulouse lists in the backup but no symlinks, only actual directories. So there was a directory for ads and another one for publicite.

Maybe Toulouse started providing the symlinks instead of duplicate directories to minimise the downloads on their server of duplicate material. I don’t know.

No but it didn’t for me.

I will try and compare older backups I have with a new one that I create from CU201 with the latest Toulouse lists.

I don’t understand why you feel the need to make remarks like this!

9

It’s nothing personal, sorry, but I took offense to a comment elsewhere about my tests.

10

According to my old backups, the Toulouse list changed the linked directories between March 2nd and 12th, 2026.

11

What I have discovered is that the University of Toulouse decided to change from having duplicate directories for ads/publicite, agressive/agressif, violence/agressif, porn/adult, mail/forums, proxy/redirector and drugs/drogue to having symlinks pointing from the first name to the directory with the second name.

This happened somewhere this year probably sometime after CU199.

So this problem has nothing to do with CU202 but is a bug caused by a change in how the University of Toulouse provide their aggregate list.

12

Our responses crossed paths.

13

The bug also exists on CU201

can be added
rm -rf /var/ipfire/urlfilter/blacklists/*
Before extract

14

While awaiting a possible fix, here’s a workaround for this bug:

  • Update the Toulouse list in URLFilter before restoring.