Open firewave opened 1 year ago
The same issue was referenced here (albeit in scope of a possibly completely different issue): https://superuser.com/questions/1803992/getting-this-error-failed-to-take-etc-passwd-lock-invalid-argument#comment2829160_1803992
This affects also debian.
While the superuser.com post could give hints, I found it really too much aggressive on the deletion of the /var/lib/dpkg/info folder.
I had to do such instead:
$> sudo mv /var/lib/dpkg/info/systemd-timesyncd.postinst /tmp/
$> sudo mv /var/lib/dpkg/info/systemd.postinst /tmp/
$> sudo dpkg --configure -a
This will actually allow dpkg to "configure" the package, albeit, doing nothing because the postinst script is not here anymore.
I found that both script are using systemd-sysusers command to update passwd / group files according to a conf file. I ensured that my local files are correct comparing to the appropriate conf file.
I have then put them back in place, just for being clean.
In my environment, disabling postinst script of polkitd
was needed.
$ sudo mv /var/lib/dpkg/info/polkitd.postinst /tmp/
Did your windows break because of wsl? now my wsl doesn't open either. It's like he just disappeared :D o heil windows
Did your windows break because of wsl? now my wsl doesn't open either. It's like he just disappeared :D o heil windows
Completly not related issue...
Actually this issue is quite annoying as it happens in all postinst script which calls "systemd-sysusers" to setup users and groups.
My workaround for the moment is to modify /var/lib/dpkg/info/[package-name].postinst and comment the call to systemd-sysusers.
Actually this issue is quite annoying as it happens in all postinst script which calls "systemd-sysusers" to setup users and groups.
As that application is broken (running it separately also triggers the same error) you could just no-op it out by replacing it with an empty script. That should make things a bit easier than modify scripts. IIRC WSL1 is not utilizing init/systemd so that should not have any detrimental effect on the system.
IIRC WSL1 is not utilizing init/systemd so that should not have any detrimental effect on the system.
For what I understand, this systemd-sysusers is just a helper script to update passwd and groups files. So, as long as we keep the same users groups or whatever, that should be ok. But if the bugs stays long, we could have unsync of user rights and reach problems here.
ie: what if we want to install service xyz and run it using command line (making our self init ?) as the correct user ?
Ran into this with Kali-xRDP
Install opensysusers
The following NEW packages will be installed:
opensysusers
Selecting previously unselected package opensysusers.
(Reading database ... 20796 files and directories currently installed.)
Preparing to unpack .../opensysusers_0.7.3-2_all.deb ...
Adding 'diversion of /bin/systemd-sysusers to /bin/systemd-sysusers.real by opensysusers'
Unpacking opensysusers (0.7.3-2) ...
Setting up opensysusers (0.7.3-2) ...
FWIW, here is my workaround:
cd /bin && mv -f systemd-sysusers{,.org} && ln -s echo systemd-sysusers && cd -
This affects also Tumbleweed. Here systemd is pulled as a dependency of man while being completely unneeded.
FWIW, here is my workaround:
cd /bin && mv -f systemd-sysusers{,.org} && ln -s echo systemd-sysusers && cd -
Only thing that worked for me from everything I tried.
+1
Windows Version
Microsoft Windows [Version 10.0.19045.3324]
WSL Version
1.2.5.0
Are you using WSL 1 or WSL 2?
Kernel Version
4.4.0-19041-Microsoft
Distro Version
Kali Linux
Other Software
No response
Repro Steps
Try to update your system with
sudo apt-get update && sudo apt-get dist-upgrade
Expected Behavior
The Update succeeds.
Actual Behavior
Updating the
systemd
package fails:Diagnostic Logs
No response