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

Updating systemd in WSL1 Kali Linux fails with Failed to take /etc/passwd lock: Invalid argument #10397

Open
1 of 2 tasks
firewave opened this issue Aug 16, 2023 · 12 comments
Open
1 of 2 tasks
Labels

Comments

@firewave
Copy link

Windows Version

Microsoft Windows [Version 10.0.19045.3324]

WSL Version

1.2.5.0

Are you using WSL 1 or WSL 2?

  • WSL 2
  • WSL 1

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:

Preconfiguring packages ...
Setting up systemd (254-1) ...
Failed to take /etc/passwd lock: Invalid argument
dpkg: error processing package systemd (--configure):
 installed systemd package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)

Diagnostic Logs

No response

@firewave
Copy link
Author

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

@qdel
Copy link

qdel commented Aug 17, 2023

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.

@nvsofts
Copy link

nvsofts commented Aug 17, 2023

In my environment, disabling postinst script of polkitd was needed.

$ sudo mv /var/lib/dpkg/info/polkitd.postinst /tmp/

@OneBlue OneBlue added the wsl1 label Aug 22, 2023
@issa0sg
Copy link

issa0sg commented Aug 25, 2023

Did your windows break because of wsl? now my wsl doesn't open either. It's like he just disappeared :D o heil windows

@qdel
Copy link

qdel commented Aug 26, 2023

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...

@qdel
Copy link

qdel commented Sep 2, 2023

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.

@firewave
Copy link
Author

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.

@qdel
Copy link

qdel commented Oct 10, 2023

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 ?

@DesktopECHO
Copy link

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) ...

@Heptazhou
Copy link

FWIW, here is my workaround:

cd /bin && mv -f systemd-sysusers{,.org} && ln -s echo systemd-sysusers && cd -

@brjsp
Copy link

brjsp commented Nov 6, 2023

This affects also Tumbleweed. Here systemd is pulled as a dependency of man while being completely unneeded.

@Pavel-Sushko
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants