Your message dated Tue, 10 Oct 2023 12:07:16 +0100
with message-id <d412bd6b800915323b0875aee5922612a1fe0ef4.ca...@debian.org>
and subject line Re: systemd-sysusers: on WSL1, /etc/passwd lock fails, breaks
other dpkg postinst
has caused the Debian Bug report #1053749,
regarding systemd-sysusers: on WSL1, /etc/passwd lock fails, breaks other dpkg
postinst
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1053749: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053749
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 254.5-1
Severity: normal
X-Debbugs-Cc: max+b...@prehl.us
Dear Maintainer,
I am new to submitting bug reports so please bear with me.
I am running Debian Sid in WSL1. As of a few releases ago, systemd and
systemd-timesyncd started using systemd-sysusers in their dpkg postinst
scripts. It was during some system upgrades that I found out that
systemd-sysusers is quite broken on the WSL1 system due to a bad lock
implementation.
You can see several reports in this post:
- https://superuser.com/a/1805742/1298503
I was able to work around this issue by following some of the advice in
the thread. Moving the postinst scripts temporarily, then running dpkg
--configure, then putting them back.
It was while exploring these scripts that I found the references to
systemd-sysusers.
I tried using systemd-sysusers on it's own and it will not work AT ALL,
it only produces the error:
`Failed to take /etc/passwd lock: Permission denied`
Because it was so badly broken, i also opened a report on the systemd
upstream repo:
- https://github.com/systemd/systemd/issues/29512
I'm hoping at the very least that Debian can build in some fallbacks in
the postinst scripts so that we are still able to update our systems on
WSL1 without intense workarounds.
-- Package-specific info:
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (650, 'testing'), (600, 'unstable'), (500, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.4.0-19041-Microsoft (UP)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Versions of packages systemd depends on:
ii libacl1 2.3.1-3
ii libaudit1 1:3.1.1-1
ii libblkid1 2.39.2-2
ii libc6 2.37-12
ii libcap2 1:2.66-4
ii libcryptsetup12 2:2.6.1-5
ii libfdisk1 2.39.2-2
ii libgcrypt20 1.10.2-3
ii libkmod2 30+20230601-2
ii liblz4-1 1.9.4-1
ii liblzma5 5.4.4-0.1
ii libmount1 2.39.2-2
ii libp11-kit0 0.25.0-4
ii libseccomp2 2.5.4-1+b3
ii libselinux1 3.5-1
ii libssl3 3.0.11-1
ii libsystemd-shared 254.5-1
ii libsystemd0 254.5-1
ii libzstd1 1.5.5+dfsg2-2
ii mount 2.39.2-2
ii systemd-dev 254.5-1
Versions of packages systemd recommends:
ii dbus [default-dbus-system-bus] 1.14.10-1
ii systemd-timesyncd [time-daemon] 254.5-1
Versions of packages systemd suggests:
ii libfido2-1 1.13.0-1
pn libqrencode4 <none>
pn libtss2-esys-3.0.2-0 <none>
pn libtss2-mu0 <none>
pn libtss2-rc0 <none>
pn polkitd <none>
ii python3 3.11.4-5+b1
pn python3-pefile <none>
pn systemd-boot <none>
pn systemd-container <none>
pn systemd-homed <none>
pn systemd-resolved <none>
pn systemd-userdbd <none>
Versions of packages systemd is related to:
ii dbus-user-session 1.14.10-1
pn dracut <none>
pn initramfs-tools <none>
pn libnss-systemd <none>
ii libpam-systemd 254.5-1
ii udev 254.5-1
-- no debconf information
--- End Message ---
--- Begin Message ---
Control: tags -1 wontfix
On Tue, 10 Oct 2023 06:56:30 -0400 "Max P." <max+b...@prehl.us> wrote:
> Package: systemd
> Version: 254.5-1
> Severity: normal
> X-Debbugs-Cc: max+b...@prehl.us
>
> Dear Maintainer,
>
> I am new to submitting bug reports so please bear with me.
>
> I am running Debian Sid in WSL1. As of a few releases ago, systemd
and
> systemd-timesyncd started using systemd-sysusers in their dpkg
postinst
> scripts. It was during some system upgrades that I found out that
> systemd-sysusers is quite broken on the WSL1 system due to a bad lock
> implementation.
>
> You can see several reports in this post:
> - https://superuser.com/a/1805742/1298503
>
> I was able to work around this issue by following some of the advice
in
> the thread. Moving the postinst scripts temporarily, then running
dpkg
> --configure, then putting them back.
>
> It was while exploring these scripts that I found the references to
> systemd-sysusers.
>
> I tried using systemd-sysusers on it's own and it will not work AT
ALL,
> it only produces the error:
>
> `Failed to take /etc/passwd lock: Permission denied`
>
> Because it was so badly broken, i also opened a report on the systemd
> upstream repo:
> - https://github.com/systemd/systemd/issues/29512
>
> I'm hoping at the very least that Debian can build in some fallbacks
in
> the postinst scripts so that we are still able to update our systems
on
> WSL1 without intense workarounds.
WSL1 is de-facto deprecated, just switch to WSL2. This is basic
filesystem functionality and it just needs to work. If you don't want
to switch to WSL2 for any reason, then just use Debian oldstable
instead of unstable.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
--- End Message ---
