Please, c.f. PM:
. . . ls -h -AlgR 2022-03-24_12-17__cu-165-Testing
. . . 2022-03-24_12-17__cu-165-Testing.txt.gz
Hth!
Feel free to request for more 
I think you were right about the backupctrl issue being related.
I think it was caused by a change issued in CU164 which changed the backup include and exclude files to have their entries as relative paths and not absolute paths. I think that may have then caused the backupctrl issue.
Either way, changing the include file paths back to absolute (ie prepending a / at the start of every line) has made my backup now include all the required directories.
I will have a look at testing out the path change that @Michael implemented to fix the backupctrl issue to confirm if that also fixes this problem - ie they are driven by the same root cause. However I will over to my vm testbed for that because I will have to copy in the modified backupctrl file from the git repository and the path change was made to one of the c files for backupctrl.
Anyway a simple temp fix for your running system is to add a / at the start of each line in
/var/ipfire/backup/include
2 Likes
The fix for the backupctrl issue is in next which means it will be seen in CU166
1 Like
I fear there are more $PATH-related issues - e.g.:
Adding aliases into .bashrc like
cat .bashrc
…
[[ -f ~/.bash_aliases ]] && . ~/.bash_aliases
yields the following failure at ssh-login:
. . . Last login: Thu Mar 24 13:25:43 2022 from 10.31.101.51
-bash: /root/.bash_aliases: Permission denied
Directly afterwards, commanding
. . . source ~/.bash_aliases
works instantaneously …
CONFIRMATION: Re-do :
…/2022-03-24_13-37__cu-165-Testing____slash $ ll var/ipfire/ddns/
-rw-r–r-- 1 manfred manfred 49 22. Mär 16:35 config
-rw-r–r-- 1 manfred manfred 101 24. Mär 11:14 ddns.conf
-rw-r–r-- 1 manfred manfred 0 9. Feb 2018 settings
So I just ran CU166 (next) which has the backupctrl path fix and the fix looks to work in that the previous issue did not occur but there was another failure but that is due to an uninitialised variable in something that is still being worked on.
However, key thing is that with the backupctrl path fix in place the missing directories in the backup were still missing so it looks like this is a different bug so I will raise it in the IPFire Bugzilla.
1 Like
If backupctrl call backup.pl ( a bash script ) the problem is the missing expansion of entries like ‘var/ipfire//.conf’.
Except that I had the same problem if I ran backup.pl directly from the command line. The directories were still missing.
@Adolf , I had submitted bug 12816 earlier which I think may be related.
Hi Rejjy,
Yes I only saw it after I had submitted mine.
Reading through it i think it is the same.
The fix for that backupctrl issue is in next (CU166) and I installed it onto a vm on my vm testbed and it did not fix this problem of the missing directories in the backup. It may still be related to paths because of the change from absolute to relative paths in the include file but the paths change in suid.c for backupctrl is not enough on its own.
1 Like
I’ve added a comment ( and solution ) about this to bug #12817
Core Update 165 Development Build: master/c55f5c8e: still the same.
It will be. I haven’t yet submitted the patch. I will do that later today. Then it will likely go into CU166.
When done I will put a link to the patch and you can apply it to your system removing the temporary fix I mentioned earlier in this thread.
1 Like
Hint @ Adolf: My last post was aiming at the “spdyn” specialities -
c.f. above: “concerning spdns.org, there is a sepciality” …
confirming the observed “Instant Update” problem.
Sorry, my mistake.
Then you need to raise a separate bug for that and one of the devs that has knowledge of the DDNS code in IPFire will have to have a look at that.
1 Like
Please, c.f. WORKAROUND and CONFIRMATION in
. . . Cu 163 - backup restore: Addon hostapd: Devices can not connect: "Waiting for IP Address"