Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug when restoring full system from snapshot (NOT from live ISO) #9

Open
ShaunTheSalvo opened this issue Sep 6, 2022 · 7 comments
Open
Labels
bug Something isn't working

Comments

@ShaunTheSalvo
Copy link

ShaunTheSalvo commented Sep 6, 2022

Hi again,

Sorry for delay in getting this to you. I have found a bug when attempting to restore the full system from a snapshot. The restore will run through until completion, but then fails with this error message:

Error restoring full system from snapshot

Terminal log output:

[shaun@shaun ~]$ sudo systemback
[sudo] password for shaun: 
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
x86_64

 An error occurred while opening the following file:

 

 /media/shaun/backup/Systemback/H01_2022-09-01-BASE/etc/systemback/systemback.excludes

After clicking OK on the error message, the main Systemback screen returns, but the directory where the snapshot is stored is marked as unavailable (red), as per below:
SB main screen after error

This would be the same as if the directory path were not mounted, however the directory path is still mounted and accessible elsewhere in the system (eg from Dolphin or a terminal). Closing Systemback and reopening it restores SB's access to the

WORKAROUND: Restoring the system in two stages, ie. selecting "System files restore", running the restore function. Then immediately (without rebooting) closing and reopening Systemback, selecting the snapshot and clicking "System Restore" again, this time selecting "User(s) configuration files restore" and running the restore function, then rebooting - seems to work with no errors.

@shadichy
Copy link
Owner

shadichy commented Sep 7, 2022

did you try running on anther machine? or use /home instead of external drive?

@ShaunTheSalvo
Copy link
Author

did you try running on anther machine? or use /home instead of external drive?

Sorry for delay in getting back to you - last couple of days have been very busy.

The error does not occur when restoring from /home. Have not yet had a chance to try on another machine, but will try to do so tonight.

@shadichy
Copy link
Owner

shadichy commented Sep 8, 2022

did you try running on anther machine? or use /home instead of external drive?

Sorry for delay in getting back to you - last couple of days have been very busy.

The error does not occur when restoring from /home. Have not yet had a chance to try on another machine, but will try to do so tonight.

So I guess the problem only happens if only you create and restore from backup which path is not in the rootfs or system mountpoints

@ShaunTheSalvo
Copy link
Author

ShaunTheSalvo commented Sep 8, 2022

So I guess the problem only happens if only you create and restore from backup which path is not in the rootfs or system mountpoints

Yes, that seems to be the case. I'll have access to another PC tomorrow (belonging to a friend of mine named Gene, who is also helping me to test/debug, and says to say hello, and appreciates your efforts :) ).

I also have another bug I've been trying to zero in on (user has no sudo access after installing from an ISO). I see you've updated the source code, so I'll build fresh from source tomorrow and test again before raising a new issue.

@shadichy
Copy link
Owner

shadichy commented Sep 8, 2022

I also have another bug I've been trying to zero in on (user has no sudo access after installing from an ISO). I see you've updated the source code, so I'll build fresh from source tomorrow and test again before raising a new issue.

About that, I thinks it's caused by:

  1. /etc/sudoers has problem(s)
  2. Newly created user is not in wheel or sudo group (will workaround to fix this)

@ShaunTheSalvo
Copy link
Author

About that, I thinks it's caused by:

  1. /etc/sudoers has problem(s)
  2. Newly created user is not in wheel or sudo group (will workaround to fix this)

I rebuilt SB from source this morning, and created an ISO. Installed from that ISO, however still unable to gain root access.

However, I figured out a simple workaround...

I made a clean install of Arch, and a fresh build of SB from source onto that. I found that modifying /etc/sudoers slightly (as described below) does the trick, and allows sudo access. Making the change on an installed system, and then making an ISO, solves the problem. Installed from the ISO and could gain sudo access.

The change is as follows. This section of /etc/sudoers :

## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL:ALL) ALL

## Same thing without a password
# %wheel ALL=(ALL:ALL) NOPASSWD: ALL

All I have to do is uncomment (remove the #) from either line, as required, eg:

## Uncomment to allow members of group wheel to execute any command
%wheel ALL=(ALL:ALL) ALL

## Same thing without a password
# %wheel ALL=(ALL:ALL) NOPASSWD: ALL

This works, providing sudo access for my user account. If I then create an ISO of this system using SB, I can install the ISO and my user account has sudo access. Have also tried installing under different user names - no problem.

Haven't had a chance to test making/restoring snapshots today, however I can confirm the issue with snapshots only occurs when snapshot is on an external drive. If snapshot is stored in /home, it can be restored with no problem.

Hope this helps. Will be able to do more testing tomorrow.

Cheers.

@shadichy
Copy link
Owner

I think you should submit this issue to upstream source

@shadichy shadichy added the bug Something isn't working label May 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants