Bug 12811

Summary: Cu 163, 164, 165 RC: "backupctrl restore" broken
Product: IPFire Reporter: Manfred Knick <Manfred.Knick>
Component: ---Assignee: Michael Tremer <michael.tremer>
Status: CLOSED FIXED QA Contact:
Severity: Major Usability    
Priority: - Unknown - CC: adolf.belka, michael.tremer, peter.mueller
Version: 2   
Hardware: x86_64   
OS: Unspecified   

Description Manfred Knick 2022-03-20 20:06:49 UTC
Using the “Backup Console”, running “backupctrl restore” fails because 
{ convert-to-location | firewallctrl | convert-ovpn | convert-dns-settings }
“not found” - although existing in /user/local/bin.

Temporarily replacing the calls with full path of the files circumvented these four errors.

C.f. details @ 
[ https://community.ipfire.org/t/cu-163-164-165-rc-backupctrl-broken/7467 ] .
Comment 1 Manfred Knick 2022-03-20 20:08:26 UTC
My profile ID: 	ebc1539924251781ecb8481a7c9d2691eae5258f
Comment 2 Michael Tremer 2022-03-21 11:42:48 UTC
How are you running this command? From a regular console after logging in?

What is the value of your PATH variable?
Comment 3 Manfred Knick 2022-03-21 11:51:56 UTC
- New fresh install onto empty disk
- Login as "root"
- from console / command line
- same after reboot
Comment 4 Michael Tremer 2022-03-21 15:56:04 UTC
(In reply to Michael Tremer from comment #2)
> What is the value of your PATH variable?

Thank you. Could you please post this, too?
Comment 5 Manfred Knick 2022-03-21 16:49:50 UTC
(In reply to Michael Tremer from comment #4)

> > ... PATH variable?
> 
> Thank you. Could you please post this, too?
You're welcome.

I fear, digging into this would imply 
even another "erase", "fresh install" and afterwards "configure" cycle -
because now, at least via ssh:

# echo $PATH
/usr/local/bin:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/root/bin

! . . NOTE: As descibed in my referenced forum post:
! . . 
! . . . . . “which …” locates them at /user/local/bin

indicating that "/user/local/bin" seems to have been member of $PATH
as far as seen from the console environment.

The question remains:

? Why were they not found *from* *inside* /var/ipfire/backup/bin/backup.pl
? directly after fresh install

which was confirmed by Jon as well

and can still be re-produced with
. . . ipfire-2.27.x86_64-full-core165.iso
. . . nightly.ipfire.org > master > x86_64 > 2022-03-17_03-43

Hth.
Comment 6 Michael Tremer 2022-03-21 19:07:53 UTC
Thank you. This patch fixes this problem:

> https://patchwork.ipfire.org/project/ipfire/patch/20220321190706.2969988-1-michael.tremer@ipfire.org/
Comment 8 Manfred Knick 2022-03-23 16:12:11 UTC
AFAICS in ipfire-2.x.git, it has been committed to "next" = core166.
Thank you!

@Peter:
Could this very helpful "one-liner" be included into "master" = core165 as well?
Comment 9 Peter Müller 2022-03-24 09:02:44 UTC
Hi,

> Could this very helpful "one-liner" be included into "master" = core165 as well?

I have no authority to commit into the "master" branch.

Therefore, I would like to pass this decision on to Michael or Arne.

Thanks, and best regards,
Peter Müller
Comment 10 Michael Tremer 2022-03-24 09:07:04 UTC
This change is going to be left in c166.

If we would merge this into c165 last minute, it would be effectively released untested which is not what we want.
Comment 11 Adolf Belka 2022-04-01 21:06:10 UTC
Core Update 166 containing the fix for this bug has been released.

https://blog.ipfire.org/post/ipfire-2-27-core-update-166-released

Fix confirmed in a CU166 vm setup.