You are not logged in.
I did a blooper due to a partial upgrade.
I intended to just upgrade archlinux-keyring of an old system first via
$ sudo pacman -Sy archlinux-keyring
to avoid broken package messages due to an outdated keyring before a
$ sudo pacman -Syu
Unfortunately, I did not read pacman's messages before hitting return, and thusly pacman also upgraded pacman and sudo
Since on this remote system, sudo is my only means of becoming root, I now have this issue:
$ sudo -s
sudo: /usr/lib/libc.so.6: version `GLIBC_2.34' not found (required by sudo)
sudo: /usr/lib/libc.so.6: version `GLIBC_2.34' not found (required by /usr/lib/sudo/libsudo_util.so.0)
I tried to inject a downloaded libc.so.6 via LD_LIBRARY_PATH to no avail.
$ LD_LIBRARY_PATH=. sudo -s
sudo: /usr/lib/libc.so.6: version `GLIBC_2.34' not found (required by sudo)
sudo: /usr/lib/libc.so.6: version `GLIBC_2.34' not found (required by /usr/lib/sudo/libsudo_util.so.0)
I suspect sudo does not support this for security reasons, so that nobody can inject a malicious library.
Is there any possiblilty to rescue the system or getting sudo to work again without being root (since sudo does not work)?
Last edited by schard (2022-03-26 15:53:36)
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
Schard, i answered you in the german bbs. Have a look.
Offline
Schard, i answered you in the german bbs. Have a look.
How is that useful to anyone reading the thread in this forum?
Is there any possiblilty to rescue the system or getting sudo to work again without being root (since sudo does not work)?
The usual procedure would be to use archiso, mount the old system to (say) /mnt, and use pacman --root /mnt -Syu.
Since on this remote system, sudo is my only means of becoming root, I now have this issue:
Not sure what's the point of this, but considering the obvious downsides, I'd consider unlocking your root account after fixing your system.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
Append systemd.unit=rescue.target to the kernel parameters when booting.
Offline
Well, this is a remote system, which I can only access via SSH and OpenVPN.
I just wanted to investigate possibilities to not having to have the system be brought in.
Locking the root account was a configuration decision in favor of security.
But honestly, the questionable benefit is negligible compared to the headache when administering the systems.
So, yes, I will definitely change that.
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
Do you have polkit/pkexec available?
You'll need to shells.
Get the PID of the first "echo $$" and use it in the second, "pkttyagent --process $PID_HERE"
You should™ then (given you're in %wheel) be able to run "pkexec" in the first terminal, provide the password of your user in the second and get a rootshell in the first.
(The internal agent is broken and yells a nonsenical error)
Offline
Do you have polkit/pkexec available?
Unfortunately not. But I appreciate the idea. Wouldn't have thought of that.
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
Not possible? So there's no way to access the boot screen? At least when I had a VPS, I could login to the provider, and open a VNC window which gave me access to the boot loader.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
My company is the provider and the system is not a VPS. It's a digital signage device.
Inofficial first vice president of the Rust Evangelism Strike Force
Offline