It’ll work - but is not needed to alter the setuid bit on one binary. su root
is likely all that is needed
or just log in from a TTY as root (if possible, if that is enabled)
Thanks all.
The issue is I don’t use timeshift, but Vorta on /home
and even with chroot from a live, I can chown root:root /usr/bin/sudo
But chmod 4755 /usr/bin/sudo brings me again /usr/bin/sudo must be owned by uid 0 and have the setuid bit set …
which both should result in confirming that you are root
then: chmod u+s /usr/bin/sudo
It should definitely be possible to access the system by booting a live USB and mounting the / partition and then
change to root (through sudo for example) and then target the file via it’s PATH
chmod u+s /run/media/some_name/usr/bin/sudo
as an example.
It would be weird if that would not work.
Apparently you did try to set the immutable attribute on su (via the already defunct sudo command)
Not sure whether that is a good idea - but root can always re-set it or simply ignore it.
… if it succeeded at all …
Previously there were only different levels of backup (only configuration, only data, entire home, entire disk, disaster recovery…)
There are now also file systems that support snapshots. While this is no substitute for a good backup strategy, in your case (and countless others) a rollback to a previous snapshot would be completely successful. (The disk wasn’t broken)
A rollback can be done in a few minutes (faster than you find your backups)
You should familiarize yourself with the following topics:
File systems that can take snapshots (like btrfs)
Utilities that automatically create snapshots (hourly, daily, weekly, and for updates before and after) and delete old snapshots (like snapper or timeshift)
btrfs (You can find good Information about Btrfs in the wiki Btrfs - Manjaro)
timeshift (very easy to use, but inflexible)
snapper (more customizable, but needs some training)