[Solved] Restoring backup issue

[sinistergfx]

I did a backup and restore with dietpi-backup on a day or so old headless DietPi 136 installation to test out some software installation options and ended up getting this error after restore when trying to do any sudo commands (I don't normally login as root).

Code: Select all

sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

I was also then unable to to use su to switch to root.
Then, pretty much stuck, I powercycled the Pi (unable to sudo shutdown).

It seems it didn't start back up properly as the LED array I have hooked up for monitoring system stats didn't light up anymore and I was unable to connect over SSH.
I ended up just redoing the install from scratch.

Has anyone encountered an issue like this or could test out backup/restore to see if they run into the same issue? (on a cloned SD card of course)
I may try to reproduce the issue this weekend on another SD card.

[Fourdee]

Has anyone encountered an issue like this or could test out backup/restore to see if they run into the same issue? (on a cloned SD card of course)
I may try to reproduce the issue this weekend on another SD card.

Hi,

Did you run dietpi-backup without user root, or sudo before the command? Doing this would cause a world of issues.

The script doesn't check for this currently, so thats on us, and I can only apologise. I'll add a exit clause to prevent the program running if underprivileged.

[sinistergfx]

That's definitely a possibility.
That's why I'm going to double check and do some testing.

I'll try doing a backup + restore to clone my current installation onto another card; if that one ends up with the problem then I'll also do a backup + restore on another new installation with minimal changes too see if the issue was something unique to my configuration.

[keithellis]

Has anyone encountered an issue like this or could test out backup/restore to see if they run into the same issue? (on a cloned SD card of course)
I may try to reproduce the issue this weekend on another SD card.

Hi,

Did you run dietpi-backup without user root, or sudo before the command? Doing this would cause a world of issues.

The script doesn't check for this currently, so thats on us, and I can only apologise. I'll add a exit clause to prevent the program running if underprivileged.

Yep I've had exactly the same issue, using backup as root user.

Keith.

[sinistergfx]

EDIT: SOLVED in my post below, leaving this up for documentation of the troubleshooting process

I just tried to 'clone' my existing installation onto a new installation on another MicroSD by using backup and restore.
First, I made it not headless, so I can do some more troubleshooting.
I made sure to do both backup and restore as root.

I ended up with the same problem as before.

Since it's not headless I was able to login and check some things out.
- definitely some errors/warnings on boot, seeing a lot of these in /var/log/syslog:

Code: Select all

...is marked executable. Please remove executable permission bits. Proceeding anyway.

Code: Select all

...INSECURE MODE (group/other writable)

Code: Select all

...INSECURE MODE (mode 0600 expected)

It seems dietpi-backup is getting and/or setting permissions improperly
- smbd and nmbd are failing to start on boot
- my LED monitoring script is failing to start on boot (it's supposed to start @reboot from cron), though I can manually start it
- Pi-Hole/Tonido/Transmission all seem to be working fine, but i'm having to use the Pi's ip address rather than the host name to connect to their web interfaces.
- I'm able to login through SSH after making Dropbear not require keys to login, but it's odd that it's rejecting keys as my authorized_keys file is still in place.
- if i log in with my user account rather than root i get the same sudo error as before

Code: Select all

sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

- can't use su to switch to root from my account

Code: Select all

setgid: Operation not permitted

I was able to get sudo kind of working again by following the advice of the 2nd answer here: http://askubuntu.com/questions/452860/u ... id-bit-set
But, every time I use sudo I get this prompt, rather than just the first time:

Code: Select all

sudo: /var/lib/sudo/ts is group writable

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

I'll keep this cloned microSD around if there's any additional troubleshooting anyone can think of.

[sinistergfx]

SOLVED!

I edited RSYNC_RUN_OPTIONS in dietpi-backup to include the -p option to preserve permissions.

from:

Code: Select all

RSYNC_RUN_OPTIONS="-alHvP --delete --log-file=$LOGFILE --exclude-from=$FP_EXCLUDE_GLOBAL --include-from=$FP_INCLUDE_GLOBAL"

to:

Code: Select all

RSYNC_RUN_OPTIONS="-alHpvP --delete --log-file=$LOGFILE --exclude-from=$FP_EXCLUDE_GLOBAL --include-from=$FP_INCLUDE_GLOBAL"

I did a backup from my 'working' microSD and a restore over my 'broken' microSD and now everything seems to work perfectly.

Added a pull request for the change.

[Fourdee]

SOLVED!

I edited RSYNC_RUN_OPTIONS in dietpi-backup to include the -p option to preserve permissions.

from:

Code: Select all

RSYNC_RUN_OPTIONS="-alHvP --delete --log-file=$LOGFILE --exclude-from=$FP_EXCLUDE_GLOBAL --include-from=$FP_INCLUDE_GLOBAL"

to:

Code: Select all

RSYNC_RUN_OPTIONS="-alHpvP --delete --log-file=$LOGFILE --exclude-from=$FP_EXCLUDE_GLOBAL --include-from=$FP_INCLUDE_GLOBAL"

I did a backup from my 'working' microSD and a restore over my 'broken' microSD and now everything seems to work perfectly.

Added a pull request for the change.

Legend! Great find and great fix, good stuff