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

sudo sh -c 'cd /bin && mv -f systemd-sysusers systemd-sysusers.org && ln -s echo systemd-sysusers'

in case you get a mv: cannot move 'systemd-sysusers' to 'systemd-sysusers.org': Permission denied error

sudo sh -c 'cd /bin && mv -f systemd-sysusers systemd-sysusers.org && ln -s echo systemd-sysusers'

in case you get a mv: cannot move 'systemd-sysusers' to 'systemd-sysusers.org': Permission denied error

It works for me.Thanks very much.

FWIW, here is my workaround:

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

+1 works for me, Thanks