Bug 12811 - Cu 163, 164, 165 RC: "backupctrl restore" broken
Summary: Cu 163, 164, 165 RC: "backupctrl restore" broken
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: x86_64 Unspecified
: - Unknown - Major Usability
Assignee: Michael Tremer
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-20 20:06 UTC by Manfred Knick
Modified: 2022-04-01 21:06 UTC (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.