Bug#919509: Restart logind on package updates

[Michael Biebl]

Control: retitle -1 restart logind on package updates
Control: block -1 by 798097

On Thu, 28 Feb 2019 15:09:14 -0600 "Karl O. Pinc"  wrote:
> If systemd restarts all of its processes which are affected
> by package upgrade then the only reason to require a restart would
> be if some changes in new systemd packages required a restart
> of non-systemd components.  So maybe this is a non-bug.

We restart (in buster) all systemd components besides logind:
https://salsa.debian.org/systemd-team/systemd/commit/b8c239e122ef193c6aab1c65ab1c6d2b598de3d7

logind nowadays supports being restarted
https://github.com/systemd/systemd/commit/aed24c4cd7641da6f530853d10637568c13c8f35

So the remaining bit is that Xorg no longer aborts on logind restarts
See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798097
https://gitlab.freedesktop.org/xorg/xserver/issues/531

Once that is fixed in xserver-xorg, I would rather restart logind on
upgrades then requesting a reboot. So re-purposing the bug report
accordingly.
It's a bit sad that #798097 is still unfixed, but I'm not sure what I
can do to move this issue forward.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#925160: systemd: user session slow to start (11 seconds)

[Michael Biebl]

On 20.03.19 17:36, Laurent Bonnaud wrote:
> Package: systemd
> Version: 241-2
> Severity: important
> 
> 
> Dear Maintainer,
> 
> on this system, an initial ssh connection needs 11 seconds to complete (as 
> root or any other user).  Further connections are fast.

Is this problem reproducible if you login locally?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#925160: systemd: user session slow to start (11 seconds)

[Michael Biebl]

Am 20.03.19 um 19:01 schrieb Laurent Bonnaud:
> Timestamp generators-start: Wed 2019-03-20 15:06:27 CET
> Timestamp generators-finish: Wed 2019-03-20 15:06:38 CET

That is odd.
Do you have any (user) generators which might take a long time?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#925160: systemd: user session slow to start (11 seconds)

[Michael Biebl]

Am 20.03.19 um 19:19 schrieb Michael Biebl:
> Am 20.03.19 um 19:01 schrieb Laurent Bonnaud:
>> Timestamp generators-start: Wed 2019-03-20 15:06:27 CET
>> Timestamp generators-finish: Wed 2019-03-20 15:06:38 CET
> 
> That is odd.
> Do you have any (user) generators which might take a long time?

Typical places to check:

/usr/lib/systemd/user-environment-generators/
/usr/lib/systemd/user-generators/

and the equivalent locations in /etc and ~/.config/systemd

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#925160: systemd: user session slow to start (11 seconds)

[Michael Biebl]

Control: tags -1 + moreinfo

Am 20.03.19 um 19:24 schrieb Michael Biebl:
> Am 20.03.19 um 19:19 schrieb Michael Biebl:
>> Am 20.03.19 um 19:01 schrieb Laurent Bonnaud:
>>> Timestamp generators-start: Wed 2019-03-20 15:06:27 CET
>>> Timestamp generators-finish: Wed 2019-03-20 15:06:38 CET
>>
>> That is odd.
>> Do you have any (user) generators which might take a long time?
> 
> Typical places to check:
> 
> /usr/lib/systemd/user-environment-generators/
> /usr/lib/systemd/user-generators/
> 
> and the equivalent locations in /etc and ~/.config/systemd
> 

Another info that might help give a clue is setting
LogLevel=debug in /etc/systemd/user.conf, reboot, log in, then attach
the output of journalctl --user -b


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#925160: systemd: user session slow to start (11 seconds)

[Michael Biebl]

Control: reassign -1 im-config
Control: tags -1 - moreinfo
Control: affects -1 + systemd

Am 21.03.19 um 13:51 schrieb Laurent Bonnaud:
> On 20/03/2019 19.39, Michael Biebl wrote:
> 
>> Another info that might help give a clue is setting
>> LogLevel=debug in /etc/systemd/user.conf, reboot, log in, then attach
>> the output of journalctl --user -b
> 
> Thanks, it allowed me to find the cause of the problem:
> 
> Mar 21 13:41:49 hostname sshd[237915]: Accepted publickey for root from 
> 193.55.51.152 port 41646 ssh2: RSA 
> SHA256:wmFQ70BsRjT4uCWua2ddnbfFv7kiMecLHVNtZMw0KMk
> Mar 21 13:41:49 hostname sshd[237915]: pam_unix(sshd:session): session opened 
> for user root by (uid=0)
> Mar 21 13:41:49 hostname systemd-logind[743]: New session 4844 of user root.
> Mar 21 13:41:49 hostname systemd[1]: Starting User Manager for UID 0...
> Mar 21 13:41:49 hostname systemd[237918]: pam_unix(systemd-user:session): 
> session opened for user root by (uid=0)
> Mar 21 13:41:49 hostname systemd[237918]: Found container virtualization none.
> Mar 21 13:41:49 hostname systemd[237918]: systemd 241 running in user mode 
> for user 0/root. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP 
> +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELF
> Mar 21 13:41:49 hostname systemd[237918]: RLIMIT_MEMLOCK is already as high 
> or higher than we need it, not bumping.
> Mar 21 13:41:49 hostname systemd[237918]: Found cgroup2 on 
> /sys/fs/cgroup/unified, unified hierarchy for systemd controller
> Mar 21 13:41:49 hostname systemd[237918]: Unified cgroup hierarchy is located 
> at /sys/fs/cgroup/unified/user.slice/user-0.slice/user@0.service. Controllers 
> are on legacy hierarchies.
> Mar 21 13:41:49 hostname systemd[237918]: Got EBADF when using 
> BPF_F_ALLOW_MULTI, which indicates it is supported. Yay!
> Mar 21 13:41:49 hostname systemd[237918]: Controller 'cpu' supported: yes
> Mar 21 13:41:49 hostname systemd[237918]: Controller 'cpuacct' supported: yes
> Mar 21 13:41:49 hostname systemd[237918]: Controller 'io' supported: no
> Mar 21 13:41:49 hostname systemd[237918]: Controller 'blkio' supported: yes
> Mar 21 13:41:49 hostname systemd[237918]: Controller 'memory' supported: yes
> Mar 21 13:41:49 hostname systemd[237918]: Controller 'devices' supported: yes
> Mar 21 13:41:49 hostname systemd[237918]: Controller 'pids' supported: yes
> Mar 21 13:41:49 hostname systemd[237918]: Controller 'bpf-firewall' 
> supported: yes
> Mar 21 13:41:49 hostname systemd[237918]: Controller 'bpf-devices' supported: 
> yes
> Mar 21 13:41:49 hostname systemd[237918]: Set up TFD_TIMER_CANCEL_ON_SET 
> timerfd.
> Mar 21 13:41:49 hostname systemd[237918]: Serializing 
> user-environment-generators to memfd.
> Mar 21 13:41:49 hostname systemd[237918]: Successfully forked off 
> '(sd-executor)' as PID 237922.
> Mar 21 13:41:49 hostname systemd[237922]: Serializing 
> 30-systemd-environment-d-generator to memfd.
> Mar 21 13:41:49 hostname systemd[237922]: Successfully forked off '(direxec)' 
> as PID 237923.
> Mar 21 13:41:49 hostname systemd[237922]: 
> /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator
>  succeeded.
> Mar 21 13:41:49 hostname systemd[237922]: Serializing 60-flatpak to memfd.
> Mar 21 13:41:49 hostname systemd[237922]: Successfully forked off '(direxec)' 
> as PID 237924.
> Mar 21 13:41:49 hostname systemd[237922]: 
> /usr/lib/systemd/user-environment-generators/60-flatpak succeeded.
> Mar 21 13:41:49 hostname systemd[237922]: Serializing 70-im-config to memfd.
> Mar 21 13:41:49 hostname systemd[237922]: Successfully forked off '(direxec)' 
> as PID 237927.
> Mar 21 13:42:02 hostname systemd[237922]: 
> /usr/lib/systemd/user-environment-generators/70-im-config succeeded.
> 
> Therefore the problem is in 
> /usr/lib/systemd/user-environment-generators/70-im-config.  Moving this file 
> away solves the problem :>.
> 
> Should I reassign this bug to the im-config package ?

Yup, let's do this.

@Laurent: you can attach the output of "reportbug --template im-config"
so the im-config maintainers have a bit more context.

Regards,
Michael




signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#925190: udev: Random execution order of RUN commands

[Michael Biebl]

Am 21.03.19 um 03:58 schrieb Celelibi:
> It looks like it's actually already fixed upstream.
> https://github.com/systemd/systemd/issues/11368
> Fixed by the commit:
> https://github.com/systemd/systemd/commit/39a15c8a8dad26deda140867f03e44a535b7bd8d

This sounds like something that should be fixed for buster.

>> Versions of packages udev is related to:
>> ii  systemd  241-1
> 
> By looking at the debian source, it looks like it's also fixed in 242-2.
> I'll test it when I can, but I think it should work.
> 

I guess you mean 241-2, as there is no 242-2 (yet).
241-2 does not contain that upstream fix.

Would be great if you test a package with this fix applied and confirm
the fix.

Regards,
Michael




signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#925409: unblock: systemd/241-2

[Michael Biebl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package systemd

This version has a couple of fixes we'd like to see land in buster. The
package has been in unstable without a reported regression.

The changelog is

systemd (241-2) unstable; urgency=medium

  [ Martin Pitt ]
  * debian/tests/boot-smoke: Create journal and udevdb artifacts on all
failures
  * autopkgtests: Replace obsolete $ADT_* variables
  * networkd-test: Ignore failures of test_route_only_dns* in containers.
This test exposes a race condition when running in LXC, see issue #11848
for details. Until that is understood and fixed, skip the test as it's
not a recent regression. (Closes: #924539)
  * Bump Standards-Version to 4.3.0.
No changes necessary.
  * debian/tests/boot-smoke: Only check current boot for connection timeouts.
Otherwise we'll catch some
Failed to resolve group 'render': Connection timed out
messages that happen in earlier boots during VM setup, before the
"render" group is created.
Fixes https://github.com/systemd/systemd/issues/11875
  * timedated: Fix emitted value when ntp client is enabled/disabled.
Fixes a regression introduced in 241.
  * debian/tests/timedated: Check enabling/disabling NTP.
Assert that `timedatectl set-ntp` correctly controls the service, sets
the `org.freedesktop.timedate1 NTP` property, and sends the right
`PropertiesChanged` signal.
This reproduces <https://github.com/systemd/systemd/issues/11944> and
also the earlier <https://github.com/systemd/systemd/issues/9672>.

  [ Michael Biebl ]
  * Disable fallback DNS servers in resolved (Closes: #923081)
  * cgtop: Fix processing of controllers other than CPU (Closes: #921280)
  * udev: Restore debug level when logging a failure in the external prog
called by IMPORT{program} (Closes: #924199)
  * core: Remove "." path components from required mount paths.
Fixes mount related failures when a user's home directory contains "/./"
(Closes: #923881)
  * udev.init: Use new s-s-d --notify-await to start udev daemon.
Fixes a race condition during startup under SysV init.
Add versioned dependency on dpkg (>= 1.19.3) to ensure that a version
of start-stop-daemon which supports --notify-await is installed.
(Closes: #908796)
  * Make /dev/dri/renderD* accessible to group "render"
Follow upstream and make render nodes available to a dedicated system
group "render" instead of "video". Keep the uaccess tag for local,
active users.

 -- Michael Biebl   Fri, 15 Mar 2019 18:33:54 +0100


CCed debian-boot/kibi for the udeb unblock


unblock systemd/241-2

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#925190: udev: Random execution order of RUN commands

[Michael Biebl]

Am 26.03.19 um 16:01 schrieb Celelibi:
> Note that some hunks apply with an offset. But nontheless, it applies
> and work.

Thanks for testing the patch. Very much appreciated.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#925524: init-system-helpers: Please provide a stretch backport for debhelper 12~

[Michael Biebl]

Am 28.03.19 um 11:08 schrieb wf...@niif.hu:
> Felipe Sateler  writes:
> 
>> I'm not opposed to a backport, and I don't think there are many
>> problems with attempting it. However, I do not have time to prepare
>> and test such a backport. Help welcome.
> 
> I can do the busy-work of backporting, but I lack the perspective to
> tell whether it's feasible now or in the long run.  Looking at the
> changelog it feels safe to install 1.56 on a stretch system, and this
> close to the release I wouldn't expect anything to come up before
> stretch-backports closes, though...
> 

Personally I prefer to revert the compat bumps when doing backports for
stretch (like in [1]) as I like to to keep the impact on the stable
system as minimal as possible. Pulling in a newer i-s-h is a rather
significant change. Thankfully not as significant as we had between
jessie → stretch. So a backport of i-s-h might indeed be feasible on a
cursory glance.

Regards,
Michael


[1]
https://salsa.debian.org/debian/rsyslog/commit/6bd5a7915e826650750e5864e035edb1f4d2e31a
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#919825: systemd: local filesystems other than '/' and '/usr' not checked and mounted -- emergency mode

[Michael Biebl]

On Wed, 13 Mar 2019 01:10:09 -0500 Bob Tracy  wrote:
> On Tue, Mar 12, 2019 at 12:37:27PM +0100, Michael Biebl wrote:
> > I can't really trawl through the complete config file.
> > What I noticed from the journal are errors like this
> > 
> > Feb 14 04:12:20 smirkin systemd-udevd[435]: sr0: Failed to apply ACL:
> > Operation not supported
> > Feb 14 04:12:31 smirkin systemd-udevd[440]: sg1: Failed to apply ACL:
> > Operation not supported
> > ...
> > 
> > You probably want to enable
> >   CONFIG_TMPFS_XATTR
> >   CONFIG_{TMPFS,EXT4_FS,XFS,BTRFS_FS,...}_POSIX_ACL
> > 
> > If that makes a difference, I dunno.
> 
> Those kernel config parameters are currently designated "optional" in
> the systemd README file, and I'd be really annoyed to find out they
> aren't.  I have no use for the extended attribute and ACL support in a
> non-SELINUX context, but it would not surprise me in the least to find
> out that systemd has some kind of dependency on it.  I'll enable those
> options for my next build.
> 
> > You could try running udev in debug mode (see /etc/udev/udev.conf) and
> > check if you can spot any errors.
> 
> Worth a try.

Any news here, Bob?
Did you have a chance to try a Debian kernel / run udev in debug mode?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#925524: init-system-helpers: Please provide a stretch backport for debhelper 12~

[Michael Biebl]

https://ftp-master.debian.org/backports-new.html

> Am 31.03.2019 um 16:31 schrieb wf...@niif.hu:
> 
> Michael Biebl  writes:
> 
>> Personally I prefer to revert the compat bumps when doing backports for
>> stretch (like in [1]) as I like to to keep the impact on the stable
>> system as minimal as possible. Pulling in a newer i-s-h is a rather
>> significant change.
> 
> I see.  Dropping back to compat 10 is certainly an option, now that I
> know that only compat 11 is affected.  Thing is, this package never
> used compat 10, so this requires careful review.
> 
>> Thankfully not as significant as we had between jessie → stretch. So a
>> backport of i-s-h might indeed be feasible on a cursory glance.
> 
> Given that it would potentially help several maintainers, could you
> please give this some more serious consideration?  Strictly on the
> theoretical level, of course. :)
> -- 
> Thanks,
> Feri
> 
> ___
> Pkg-systemd-maintainers mailing list
> Pkg-systemd-maintainers@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926037: systemd: localectl console keymap configuration delayed

[Michael Biebl]

Am 30.03.19 um 18:11 schrieb Iiro Laiho:
> Package: systemd
> Version: 232-25+deb9u9
> Severity: important
> Tags: l10n
> 
> Dear Maintainer,
> 
> When I set the system keymap using the "localectl" command, the 
> application of the new layout to the virtual consoles is delayed. The 
> delay seems to be unpredictable. I have currently no idea what does 
> finally trigger the change or when it happens. Sometimes reboot seems to 
> do it, sometimes not.

Can you post the exact commands you used and what you did next.
I'm not quite sure what you mean with "application of the new layout to
the virtual consoles is delayed".
Did you logout/login again in the mean time and still got the same layout?

TTBOMK, localectl just writes to /etc/default/keyboard and /etc/default
/console-setup and leaves it up to console-setup to apply those changes,
which is usually done during bootup.
There is also a /lib/udev/rules.d/90-console-setup.rules, i.e is
triggered via udev. So it might be possible, that console-setup applies
the changes when the hardware configuration changes.



Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#890265: systemd: journalctl compiled without pattern matching support

[Michael Biebl]

On Mon, 19 Feb 2018 11:25:56 +0100 Michael Biebl  wrote:
> Am 12.02.2018 um 18:02 schrieb Calum Mackay:
> > Package: systemd
> > Version: 237-2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > The -g/--grep option was recently added to the man page, but:
> > 
> > $ journalctl --grep=blah
> > Compiled without pattern matching support
> > 
> > this could be a man page bug, of course, although it's a useful feature.
> 
> As the message says, systemd has been compiled without pattern matching
> support. This is deliberate, as this would required linking against
> pcre2, which would basically make this library mandatory on every
> system. That's why I hesitated to enable that feature.

I'm fine with turning this feature on in buster+1.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#917423: systemd-sysv: centrally document which "legacy" packages/replaced are replaced by systemd

[Michael Biebl]

Am 03.04.19 um 01:58 schrieb Christoph Anton Mitterer:
> On Wed, 2019-04-03 at 00:15 +0200, Michael Biebl wrote:
>> Feel free to submit additions/corrections/updates to the release-
>> notes,
>> if you think those changes are not satisfactory.
> 
> I think it's good start... one perhaps missing thing:
> 
> I vaguely recall to have read somewhere, that some of the *acpi*
> packages was also considered to be obsoleted/replaced by systemd.
> Was it acpid? But I might be wrong.

https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#idm1558




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926316: systemd: Installing the systemd package switches the init system to systemd

[Michael Biebl]

Am 03.04.19 um 18:08 schrieb Felipe Sateler:
> Looks like sysvinit-core needs XB-Important: yes to prevent such easy
> removal.

I though about this too, but on the other hand with "init" we actually
allow users to switch between sysvinit and systemd and adding
XB-Important: yes to sysvinit-core would render "init" moot.

I have to say I'm surprised apt prefers uninstalling a package to
satisfy a Recommends over not installing a Recommends and keeping that
package.


If systemd is the active PID 1, we want libpam-systemd installed
alongside. So far we also considered that users might not have
systemd-sysv installed but instead boot with init=/lib/systemd/systemd.
I have no idea how common that is, so maybe an alternative could be to
move the libpam-systemd Recommends from systemd to systemd-sysv
(alongside the existing libnss-systemd).


WDYT? Is it too late in the release cycle to make such a change?

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#921267: systemd fails to reach shutdown.target when rebooting or shutting down the system after resuming from suspend

[Michael Biebl]

Hi,

so far the bug reports all mention that this is specific to AMD hardware.

Does the affected system have an AMD CPU/graphics card?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#919231: Salt-master unable to access directories

[Michael Biebl]

On Wed, 27 Feb 2019 10:33:48 -0300 Felipe Sateler 
wrote:
> Control: found -1 241-5
> Control: tags -1 confirmed upstream
> Control: forwarded -1 https://github.com/systemd/systemd/issues/11842
> 
> I was able to reproduce the issue, and forwarded this upstream.

Seems like something which we should consider fixing for buster.

Felipe, this bug is marked as fixed upstream. Since you already had a
look at this issue, could you cherry-pick the necessary upstream commits
and verify that the issue is fixed?

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926316: systemd: Installing the systemd package switches the init system to systemd

[Michael Biebl]

Am 03.04.19 um 20:34 schrieb Felipe Sateler:
> On Wed, Apr 3, 2019 at 1:23 PM Michael Biebl  <mailto:bi...@debian.org>> wrote:

> I have no idea how common that is, so maybe an alternative could be to
> move the libpam-systemd Recommends from systemd to systemd-sysv
> (alongside the existing libnss-systemd).
> 
> 
> Makes a lot of sense to me.
>  
> 
> WDYT? Is it too late in the release cycle to make such a change?
> 
> 
> I don't know. Most likely we would need a tight dependency on systemd,
> to ensure at least one pacakge Recommends libpam-systemd.

If we want to ensure that, we'd have to add a versioned systemd-sysv
dependency to systemd (or a versioned Breaks for that matter). Both are
problematic.
But I might be misunderstanding what you have in mind here.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: systemd-logind, lightdm, and a multiseat issue

[Michael Biebl]

Hi

Am 07.04.19 um 19:29 schrieb Eythan Weg:
> Hi,
> 
> I hope this is the right place to seek help for my difficulty.
> 
> I have been a way for sometime with my desktop shutdown, and upon my
> return had some trouble that I misdiagnosed and along the way I have
> upgraded systemd, lightdm, dbus and xserver family of packages.  My
> system is a two-seated desktop that worked like that for some years.  It
> turns out that the issue that caused my travail was completely unrelated
> to the upgrade mentioned.
> 
> But now I cannot have the second seat completely established if at all.
> I.e seat0 is completely functional and seat1 shows login but the mouse
> and keyboard show their effects on the display attached to seat0.

I don't really have any experience with multi seat.
My advise would be to raise your question on the upstream mailing list
at https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926603: Debian fails to start after installation into Virtualbox

[Michael Biebl]

Control: tags -1 moreinfo

Am 07.04.19 um 18:51 schrieb Andy Ruddock:
> Package: systemd
> Severity: critical
> 
> I'm running Windows 10 (Home edition - up to date) on the desktop, with
> Virtualbox (v6.0.4).
> I've used both the netinst CD & the testing DVD (downloaded today -
> 07/Apr/2019) to install Buster.
> After installation the system fails to start with many errors.
> The first is :
> 
> systemd[1]: user.slice: Failed to set inovcation ID for unit: File
> exists
> [FAILED]: Failed to start User and Session Slice.
> 
> other services then fail to start :
> 
> [FAILED] Failed to start Slices.
> [FAILED] Failed to listen on udev Kernel Socket.
> [FAILED] Failed to start Remote File Systems.
> [FAILED] Failed to listen on Syslog Socket.
> 
> and many more, followed by
> 
> systemd[1]: Timed out waiting for device /dev/disk/by-uuid/2cb
> 
> finally
> 
> [FAILED] Failed to start Network.
> 
> At which point there is no more, the system just halts.
> 
> Starting with "quiet" removed from linux invocation in grub, I see
> 
> systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX
> +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS
> +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2
> default-hierarchy=hybrid)
> systemd[1]: Detected virtualization oracle.
> systemd[1]: Detected architecture x86-64.
> 
> Welcome to Debian GNU/Linux buser/sid!

Please follow the instructions at
https://freedesktop.org/wiki/Software/systemd/Debugging/ and get us a
verbose debug log from the complete boot.
Please also attach the output of "reportbug --template systemd" on the
affected system.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926703: unblock: systemd/241-3

[Michael Biebl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi release team,

I'd like to request an unblock for the systemd package. A full debdiff
is attached but for easier review I've also created an annotated
changelog to the individual changes.

It fixes a security issue (CVE-2019-3842) which should enter testing as
soon as possible.
The package itself builds a udeb, so requires an unblock by kibi (in
CC). Two of the patches touch udev (see the fix for #925190 and #924199),
everything else should not be relevant for the udebs.



systemd (241-3) unstable; urgency=high

  [ Michael Biebl ]
  * Drop systemd-shim alternative from libpam-systemd.
A fixed systemd-shim package which works with newer versions of systemd
is unlikely to happen given that the systemd-shim package has been
removed from the archive. Drop the alternative dependency from
libpam-systemd accordingly.

https://salsa.debian.org/systemd-team/systemd/commit/8d292a0afd3abaa3e393ee731cb346a61dfa2bf2

This change is basically not changing anything, as the alternative
dependency "systemd-shim (>= 10-4~)" was never available in the archive.
It's mostly clean-up and making the life of apt a bit easier by not
having to consider non-available alternatives. It's also confusing to
users to still see systemd-shim listed as alternative when it has been
removed from the archive.

  * Properly remove duplicate directories from systemd package.
When removing duplicate directories from the systemd package, sort the
list of directories in reverse order so we properly delete nested
directories.

https://salsa.debian.org/systemd-team/systemd/commit/cdd220dd3ef632c76406d02366733713235dcfa2

Mostly cleanup. The systemd package mistakenly shipped an empty
/usr/lib/systemd/tests/testdata/ and /etc/udev/ directory. Those
directories are supposed to be shipped by the systemd-tests and udev
binary package.

  * udev: Run programs in the specified order (Closes: #925190)

https://salsa.debian.org/systemd-team/systemd/commit/95a57c2179fcd7beb52c9d73d08473469034d059
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925190

This fixes an important regression in udev and should definitly be fixed
in buster.

  * bash-completion: Use default completion for redirect operators
(Closes: #924541)

https://salsa.debian.org/systemd-team/systemd/commit/d4eebefd0b41ff58a7bf6d9c7f1898c011e7576f
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924541

Minor issue, mostly polish. No regression potential as it's an isolated
fix to the bash completion file.

  * networkd: Clarify that IPv6 RA uses our own stack, no the kernel's
(Closes: #815582)

https://salsa.debian.org/systemd-team/systemd/commit/0ceb922acc4e7ff4c6d8ed1d853c232da12af906
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815582

Simple doc update, no regression potential.

  * Revert "Drop systemd-timesyncd.service.d/disable-with-time-daemon.conf"
Apparently Conflicts= are not a reliable mechanism to ensure alternative
NTP implementations take precedence over systemd-timesyncd.
(Closes: #902026)

https://salsa.debian.org/systemd-team/systemd/commit/e1b3868e8b297a40e3dbfef1dfab80f3e5e0e8ef
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902026

This basically reverts back to what we had in stretch. We tried a
different approach during the buster development cycle, but it didn't
work out.

  * network: Fix routing policy rule issue.
When multiple links request a routing policy, make sure they are all
applied correctly. (Closes: #924406)

https://salsa.debian.org/systemd-team/systemd/commit/2d871ae4727dcad604cba6d92156882dadf69ab6
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924406

Explicitly requested fix. Isolated fix to systemd-networkd, so
regression potential is small.

  * pam-systemd: Use secure_getenv() rather than getenv()
Fixes a vulnerability in the systemd PAM module which insecurely uses
the environment and lacks seat verification permitting spoofing an
active session to PolicyKit. (CVE-2019-3842)

https://salsa.debian.org/systemd-team/systemd/commit/996e854fef1554829b757e7c1a515805b7f08d7a
https://www.debian.org/security/2019/dsa-4428

Fixes a security issue which was fixed in stable and should also enter
buster.


  [ Martin Pitt ]
  * Enable udev autopkgtest in containers.
This test doesn't actually need udev.service (which is disabled in
containers) and works fine in LXC.
  * Enable boot-and-service autopkgtest in containers
- Skip tests which can't work in containers.
- Add missing rsyslog test dependency.
- e2scrub_reap.service fails in containers, ignore (filed as #926138)
- Relax pgrep pattern for gdm, as there's no wayland session in
  containers.

https://salsa.debian.org/systemd-team/systemd/commit/c923cd4a7edf9f103f079c864ef47575e5d8a868
https://salsa.debian.org/s

Re: udev post installation script fails

[Michael Biebl]

Am 09.04.19 um 21:39 schrieb Roland Fries:
> Hello,
> 
> my udev post installation script fails for quite some time now.
> 
> I was lazy and hoped that a new udev version would fix that issue, but
> it didn't.
> 
> Here is the output:
> 
> root@cross-mail:~# LANG=C dpkg -D2 --configure -a
> Setting up udev (215-17+deb8u11) ...
> D02: fork/exec /var/lib/dpkg/info/udev.postinst ( configure
> 215-17+deb8u7 )
> + update_hwdb
> + udevadm hwdb --update --usr
> + addgroup --system input
> addgroup: The group `input' already exists as a system group. Exiting.
> + [ -z 215-17+deb8u7 ]
> + upgrade_fixes configure 215-17+deb8u7
> + chrooted
> + stat -c %d/%i /
> + stat -Lc %d/%i /proc/1/root
> + [ 2049/2 = 2049/2 ]
> + return 1
> + [ -d /dev/.udev/ -a ! -d /run/udev/ ]
> + dpkg --compare-versions 215-17+deb8u7 lt 171-3
> + dpkg --compare-versions 215-17+deb8u7 lt 204-1
> + chrooted
> + stat -c %d/%i /
> + stat -Lc %d/%i /proc/1/root
> + [ 2049/2 = 2049/2 ]
> + return 1
> + [ -e /etc/udev/kernel-upgrade ]
> + can_start_udevd
> + supported_kernel
> + uname -r
> + return 0
> + [ ! -d /sys/class/ ]
> + ps --no-headers --format args ax
> + egrep -q ^\[
> + grep -q [[:space:]]devtmpfs$ /proc/filesystems
> + [ -e /etc/udev/disabled ]
> + return 0
> + handle_service_rename
> + dpkg --compare-versions  lt 204-1
> + [ -d /run/systemd/system ]
> + systemctl stop udev.service udev-control.socket udev-kernel.socket
> + true
> + rm -f /run/systemd/system/systemd-udevd.service
> + rm -f /run/systemd/system/udev.service
> + [ -d /run/systemd/system ]
> + systemctl daemon-reload
> + invoke-rc.d udev restart
> dpkg: error processing package udev (--configure):
>  subprocess installed post-installation script returned error exit
> status 102
> Errors were encountered while processing:
>  udev
> 
> Why are those two "return 1" in there ?
> 
> The comparison should return 0 because statement [ 2049/2 = 2049/2 ] is
> true.

What makes you think so? chrooted() returns 1 if you are not in a chroot.


> How can I fix this ?

Check why
invoke-rc.d udev restart
fails.
That's your culprit.
That said, jessie is no longer supported, please upgrade.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926886: Please mention video->render change in udev.NEWS

[Michael Biebl]

Control: notfound -1 243-1
Control: found -1 241-3

Hi Guido

Am 11.04.19 um 21:46 schrieb Guido Günther:
> Package: udev
> Version: 243-1

I suppose you meant 241-3 here...

> Severity: normal
> 
> Hi,
> it took me a while to figure out why rendering got broken in my wayland
> compositor. It would be great if the change from video to render group
> could be mentioned in udev.NEWS.

That is unexpected.
We still apply the uaccess tag for /dev/dri/renderD* so should be
accessible to local, active sessions (including a wayland session)

Can you paste the output of
getfacl /dev/dri/renderD*


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926886: Please mention video->render change in udev.NEWS

[Michael Biebl]

Am 11.04.2019 um 22:47 schrieb Michael Biebl:
> Am 11.04.19 um 21:46 schrieb Guido Günther:

>> it took me a while to figure out why rendering got broken in my wayland
>> compositor. It would be great if the change from video to render group
>> could be mentioned in udev.NEWS.
> 
> That is unexpected.
> We still apply the uaccess tag for /dev/dri/renderD* so should be
> accessible to local, active sessions (including a wayland session)
> 

Btw, what exactly was the breakage?
I assume you worked around that for now by adding your user to group
render?
Which wayland compositor is that, btw? How do you start it?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926886: Please mention video->render change in udev.NEWS

[Michael Biebl]

Am 11.04.19 um 23:27 schrieb Michael Biebl:

> Btw, what exactly was the breakage?
> I assume you worked around that for now by adding your user to group
> render?
> Which wayland compositor is that, btw? How do you start it?

Fwiw, GNOME on Wayland (with gdm) seems to work fine here. At least I
didn't recognize any breakage.
And I have

$ getfacl /dev/dri/renderD128
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/renderD128
# owner: root
# group: render
user::rw-
user:michael:rw-
group::rw-
mask::rw-
other::---

If this looks different for you, the output of

$ loginctl show-session $XDG_SESSION_ID

would be useful as well.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926936: udev: systemd-udevd PID file name produces false positive with rkhunter for XORDDOS malware

[Michael Biebl]

Control: reassign -1 rkhunter

Am 12.04.19 um 14:53 schrieb Andrew J. Buehler:
> It is possible to whitelist this filename in rkhunter's configuration 
> settings,
> but doing so does - however mildly - increase the likelihood that if this
> malware does get a foothold on the system, rkhunter will not detect it. Thus, 
> a
> way to remove this false positive from the udev side would be preferable.

Fwiw, this only affects sysvinit systems and I'm not convinced the udev
package should work around rkhunter limitations.
Clearly this is a false-positive of rkhunter and should be fixed there.
I'll reassign this to rkhunter.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927008: systemd-journal-upload: Upload to http://logserver:19532/upload failed with code 411: gth Required

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/systemd/issues/11571

On 13.04.19 13:35, Vitry David Gilbert wrote:
> Package: systemd-journal-remote
> Version: 241-1~bpo9+1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> Remote client can't send log to logserver with error failed with code 411: 
> gth Required
> Worked before last stable upgrade
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Latest upgrade break journald

Seems to be https://github.com/systemd/systemd/issues/11571

Can you test the PR at
https://github.com/systemd/systemd/pull/11953 ?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#923773: logind sessions are ended immediately after login

[Michael Biebl]

Control: tags -1 moreinfo unreproducible


Doesn't look like libpam-systemd is properly installed
> dbus-update-activation-environment: systemd --user not found, ignoring 
> --systemd argument

> cinnamon-session[23689]: WARNING: t+0,00945s: Could not get session id for 
> session. Check that logind is properly installed and pam_systemd is getting 
> used at login.

> pn  logind | consolekit


What's the output of
reportbug --template systemd
reportbug --template libpam-systemd


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#923773: logind sessions are ended immediately after login

[Michael Biebl]

Am 14.04.19 um 14:51 schrieb Steinar H. Gunderson:
> On Sun, Apr 14, 2019 at 01:33:43PM +0200, Michael Biebl wrote:
>> What's the output of
>> reportbug --template systemd
>> reportbug --template libpam-systemd
> 
> Attaching.

Hm, something is borked in the encoding, making the log a bit hard to read.

That said, I'm wondering if this is really from the same system (seeing
that the kernel information differs).

Could you also please paste the output of
grep pam_systemd /etc/pam.d/*

and a full "journalctl -alb" log after a reboot and then a failed login.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926603: Debian fails to start after installation into Virtualbox

[Michael Biebl]

On Mon, 8 Apr 2019 01:10:28 +0200 Michael Biebl  wrote:
> Control: tags -1 moreinfo
> 
> Am 07.04.19 um 18:51 schrieb Andy Ruddock:
> > Package: systemd
> > Severity: critical
> > 
> > I'm running Windows 10 (Home edition - up to date) on the desktop, with
> > Virtualbox (v6.0.4).
> > I've used both the netinst CD & the testing DVD (downloaded today -
> > 07/Apr/2019) to install Buster.
> > After installation the system fails to start with many errors.
> > The first is :
> > 
> > systemd[1]: user.slice: Failed to set inovcation ID for unit: File
> > exists
> > [FAILED]: Failed to start User and Session Slice.
> > 
> > other services then fail to start :
> > 
> > [FAILED] Failed to start Slices.
> > [FAILED] Failed to listen on udev Kernel Socket.
> > [FAILED] Failed to start Remote File Systems.
> > [FAILED] Failed to listen on Syslog Socket.
> > 
> > and many more, followed by
> > 
> > systemd[1]: Timed out waiting for device /dev/disk/by-uuid/2cb
> > 
> > finally
> > 
> > [FAILED] Failed to start Network.
> > 
> > At which point there is no more, the system just halts.
> > 
> > Starting with "quiet" removed from linux invocation in grub, I see
> > 
> > systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX
> > +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS
> > +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2
> > default-hierarchy=hybrid)
> > systemd[1]: Detected virtualization oracle.
> > systemd[1]: Detected architecture x86-64.
> > 
> > Welcome to Debian GNU/Linux buser/sid!
> 
> Please follow the instructions at
> https://freedesktop.org/wiki/Software/systemd/Debugging/ and get us a
> verbose debug log from the complete boot.
> Please also attach the output of "reportbug --template systemd" on the
> affected system.

Any updates here? Can you provide the requested information`

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: libvirtd upgrade broken stretch->buster

[Michael Biebl]

Hi Sam

Am 15.04.2019 um 20:38 schrieb Sam Hartman:
> control: severity -1 serious
> 
> justification: libvirtd upgrades from stretch to buster break causing
> apt to fail and requiring the admin to get the systemd units into a
> consistent state before things can continue
> 
> 
> Unfortunately based on discussion so far this is a complex bug to fix.
> Ubuntu's solution is to drop the sysv scripts and to drop  Also= lines
> in some of the units.
> 
> The systemd maintainers proposed that dropping Also as well as some
> changes to move toward dh_systemd_start being used even when sysvinit
> scripts are present would help this situation.  Unfortunately it at
> least doesn't look like those changes are in debhelper for buster.
> Systemd folks, do you have any suggestions  on how to approach this for
> buster?

Using debhelper compat level 12, you are able to completely decouple
dh_installinit and dh_installsystemd which would give you the ability to
implement what you want afaics.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: libvirtd upgrade broken stretch->buster

[Michael Biebl]

Am 15.04.19 um 22:18 schrieb Michael Biebl:
> Using debhelper compat level 12, you are able to completely decouple
> dh_installinit and dh_installsystemd which would give you the ability to
> implement what you want afaics.

From debhelper's changelog:


debhelper (12.1) unstable; urgency=medium
[..]
  * dh_installinit: In compat 12, pass --skip-systemd-native to update-rc.d
to make it ignore systemd services.
  * dh_installsystemd: In compat 12, avoid relying on dh_installinit's
shell snippets for starting services.  (Closes: #887904, #887900)


And init-system-helpers:

init-system-helpers (1.52) unstable; urgency=medium
[..]
  * invoke-rc.d: add option to do nothing for native systemd units.
It is useful to simplify maintainer scripts, since it allows executing
this command for sysvinit/openrc
systems, and deb-systemd-invoke for systemd systems



Versions of debhelper and init-system-helpers implementing those bits
are available in buster and stretch-backports.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927173: udev: wrong device name when booting

[Michael Biebl]

Control: tags -1 + moreinfo

On 15.04.19 22:35, Julien-Benjamin wrote:
> Package: udev
> Version: 232-25+deb9u11
> Severity: normal
> 
> Dear Maintainer,
> 
> Sometimes when I boot, udev gives alsa a wrong device name for my USB DAC 
> (HiFimeDIY SA9023 - model:UAE23).
> 
> When in this state, unplugging/plugging it back, udev gives the proper name.

Can you be more specific, how udev assigns this name?
Is there a udev rule doing so? In which case, which udev rules files is it?
Have you made sure to include the udev rule in the initramfs?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927173: udev: wrong device name when booting

[Michael Biebl]

Am 18.04.19 um 01:43 schrieb Jul':
> Sorry for the lack of details.
> 
> 1) how udev assigns this name?
> 
> Since I have no custom udev rule, AFAIK, udev assigns it with the standards 
> rules (in "/lib/udev/rules.d/60-persistent-alsa.rules" since it is a sound 
> device).
> 

This rules file just creates a few symlinks in /dev/snd/by-id/ and
/dev/snd/by-path/

I don't see how that could influence your card being detected under
different names.

The dmesg output you posted looks like those messages come directly from
the kernel. Maybe this is a kernel issue?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927173: udev: wrong device name when booting

[Michael Biebl]

Am 18.04.19 um 17:03 schrieb JB:
> I managed to track this bug down to udev,

How?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927173: Adding details

[Michael Biebl]

Am 18.04.19 um 19:35 schrieb JB:
> If it can help, it happened to other people, e.g. here with Arch : 
> https://bbs.archlinux.org/viewtopic.php?id=222301
> 

Felipe, with your PA hat on, can you take a look at this?

To me this looks like a kernel/driver issue, but would welcome your
input on this.

Regards,
Michael




signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927173: Adding details

[Michael Biebl]

Control: reassign -1 linux-image-4.9.0-8-amd64

Am 19.04.19 um 02:17 schrieb Felipe Sateler:
> 
> 
> On Thu, Apr 18, 2019 at 8:05 PM JB  > wrote:
> 
> My bad, I thought it was the case but I mixed up the numbers.
> 
> Please find enclosed the details you've asked for.
> 
> 
> This confirms that ID_MODEL_ID changes and that ID_VENDOR changes
> although ID_VENDOR_ID does not. I think this is a kernel bug.


Thanks for you input, Felipe.

Re-assigning accordingly

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926886: Please mention video->render change in udev.NEWS

[Michael Biebl]

On Fri, 12 Apr 2019 10:47:39 +0200 Guido =?iso-8859-1?Q?G=FCnther?=
 wrote:
> Hi,
> On Thu, Apr 11, 2019 at 11:27:05PM +0200, Michael Biebl wrote:
> > Am 11.04.2019 um 22:47 schrieb Michael Biebl:
> > > Am 11.04.19 um 21:46 schrieb Guido Günther:
> > 
> > >> it took me a while to figure out why rendering got broken in my wayland
> > >> compositor. It would be great if the change from video to render group
> > >> could be mentioned in udev.NEWS.
> > > 
> > > That is unexpected.
> > > We still apply the uaccess tag for /dev/dri/renderD* so should be
> > > accessible to local, active sessions (including a wayland session)
> > > 
> > 
> > Btw, what exactly was the breakage?
> 
> Rendering got corrupted since the compositor could not open the render
> node but used /dev/card1.
> 
> > I assume you worked around that for now by adding your user to group
> > render?
> > Which wayland compositor is that, btw? How do you start it?
> 
> It's a wlroots based compositor started by a systemd unit¹ and the /dev
> tmpfs has currently no ACLs (due to
> https://github.com/systemd/systemd/issues/9674) so the uaccess rules
> don't apply here. So while I think that uaccess is way more common
> (otherwise I'd picked up a way higher severity for the bug) changing
> groups of devices might merit a clear warning.


Hm, I'm a bit undecided. This seems like a very special setup you have
there and a NEWS entry is shown to basically every user.
If it was a more common issue, I would totally agree with you.

Martin, Marco, what's your take on this?

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927698: udev dependencies broken on stretch

[Michael Biebl]

Am 23.04.19 um 21:11 schrieb Marko von Oppen:
> On Sun, 21 Apr 2019 20:23:26 +0200 Michael Biebl  wrote:
> 
>> This is by design. The init script requires a start-stop-daemon with
>> support for --notify-await.
>> This is only necessary for sysvinit users. If you don't want to use
>> systemd then backports is not available to you.
>> You can ask the dpkg maintainer for a backport of dpkg though.
> 
> Hi Michael,
> 
> there seems to be a misunderstanding at your side.

Not really, it seems you are misunderstanding the issue. The udev
package is not for sysvinit only.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#919231: Salt-master unable to access directories

[Michael Biebl]

Hi Felipe

On Wed, 3 Apr 2019 15:29:44 -0300 Felipe Sateler 
wrote:
> Unfortunately the fix seems to have been merged with some other
> refactorings and the diff is not as small[1]. I'll try to check if some of
> the patches are not necessary.
> 
> 
> [1] https://github.com/systemd/systemd/pull/12005/files


Were you able to make some progress here?

I'm considering making another upload for buster to fix #927008 (without
that upstream patch, systemd-journal-remote/upload is pretty much
useless in buster)

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927008: systemd-journal-upload: Upload to http://logserver:19532/upload failed with code 411: gth Required

[Michael Biebl]

Control: severity -1 serious
Control: tags -1 + patch

On Sat, 13 Apr 2019 20:18:09 +0200 Michael Biebl  wrote:
> Control: forwarded -1 https://github.com/systemd/systemd/issues/11571
> 
> On 13.04.19 13:35, Vitry David Gilbert wrote:
> > Package: systemd-journal-remote
> > Version: 241-1~bpo9+1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > *** Reporter, please consider answering these questions, where appropriate 
> > ***
> > 
> >* What led up to the situation?
> > Remote client can't send log to logserver with error failed with code 411: 
> > gth Required
> > Worked before last stable upgrade
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > Latest upgrade break journald
> 
> Seems to be https://github.com/systemd/systemd/issues/11571
> 
> Can you test the PR at
> https://github.com/systemd/systemd/pull/11953 ?

I could reproduce the failure on a buster system and also verify that
the patch in PR#11953 fixes the issue.
As systemd-journal-remote/upload is pretty much broken in buster, I'm
bumping this issue to RC.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927911: systemd: Does not expand %h identifier in ExecStart

[Michael Biebl]

Am 25.04.19 um 01:55 schrieb Norbert Preining:
> Package: systemd
> Version: 241-3
> Severity: important
> 
> Hi
> 
> it seems that the documentation of systemd is incorrect, or incomplete,
> as it states that
>   suffix. In the unit file itself, the instance parameter may be referred 
> to using "%i" and other
>   specifiers, see below.
>   (man page of systemd.unit)
> and down there %h is listed as home directory of the user.
> 
> We use a systemd unit file that has onedrive@.service
>   ExecStart=/usr/bin/onedrive --monitor 
> --confdir=/home/%i/.config/onedrive
> which works as expected. But the moment I change it to
>   ExecStart=/usr/bin/onedrive --monitor --confdir=%h/.config/onedrive
> it breaks because %h is not expanded.

Looks like a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868269

Can you attach the full .service file please.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927911: systemd: Does not expand %h identifier in ExecStart

[Michael Biebl]

Am 25.04.19 um 11:09 schrieb Norbert Preining:
> Hi Michael,
> 
> On Thu, 25 Apr 2019, Michael Biebl wrote:
>> Looks like a duplicate of
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868269
> 
> Indeed. Interesting that systemd changed the behaviour but it is not
> documented ... (well ... we know).
> 

Well, there are the following paragraphs from the systemd NEWS file

From v228
https://github.com/systemd/systemd/blob/master/NEWS#L3926

* In unit files the behaviour of %u, %U, %h, %s has
  changed. These specifiers will now unconditionally resolve
  to the various user database fields of the user that the
  systemd instance is running as, instead of the user
  configured in the specific unit via User=. Note that this
  effectively doesn't change much, as resolving of these
  specifiers was already turned off in the --system instance
  of systemd, as we cannot do NSS lookups from PID 1. In the
  --user instance of systemd these specifiers where correctly
  resolved, but hardly made any sense, since the user instance
  lacks privileges to do user switches anyway, and User= is
  hence useless. Moreover, even in the --user instance of
  systemd behaviour was awkward as it would only take settings
  from User= assignment placed before the specifier into
  account. In order to unify and simplify the logic around
  this the specifiers will now always resolve to the
  credentials of the user invoking the manager (which in case
  of PID 1 is the root user).

From v209
https://github.com/systemd/systemd/blob/master/NEWS#L6855

* %h, %s, %U specifier support is not available anymore when
  used in unit files for PID 1. This is because NSS calls are
  not safe from PID 1. They stay available for --user
  instances of systemd, and as special case for the root user.


>> Can you attach the full .service file please.
> 
> Here is the .in version that is then configure-d into the .service file

Thanks. So with the above, what you should get is that %h is resolved to
/root, as you run that service as a system service. Or is %h not
expanded at all?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927911: systemd: Does not expand %h identifier in ExecStart

[Michael Biebl]

Am 25.04.19 um 11:28 schrieb Michael Biebl:
> Thanks. So with the above, what you should get is that %h is resolved to
> /root, as you run that service as a system service. Or is %h not
> expanded at all?

Actually, I think systemd resolves %h for PID 1 to '/'. Would need to
double check though.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927911: systemd: Does not expand %h identifier in ExecStart

[Michael Biebl]

Am 25.04.19 um 11:33 schrieb Michael Biebl:
> Am 25.04.19 um 11:28 schrieb Michael Biebl:
>> Thanks. So with the above, what you should get is that %h is resolved to
>> /root, as you run that service as a system service. Or is %h not
>> expanded at all?
> 
> Actually, I think systemd resolves %h for PID 1 to '/'. Would need to
> double check though.
> 

Re-reading the systemd.unit man page, it says for %u and %h that it
resolves to the root user for the systemd manager instance.
While this correctly describes the behaviour, it could be a bit clearer,
documenting that setting `User=` has no effect.
I've filed https://github.com/systemd/systemd/issues/12389


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927911: systemd: Does not expand %h identifier in ExecStart

[Michael Biebl]

Am 25.04.19 um 12:24 schrieb Norbert Preining:
> Hi
> 
>> From v228
>> https://github.com/systemd/systemd/blob/master/NEWS#L3926
> 
>> From v209
>> https://github.com/systemd/systemd/blob/master/NEWS#L6855
> 
> Ok, but the documentation o freedesktop.org and the man pages do not
> mention that, and in fact mention the contrary ...

The man pages say that %h and %u are resolved to the root user if you
are using the system instance (PID 1).
That is consistent with the behaviour you are getting.
If I missed a part which mentions the contrary, could you quote the
relevant bits from the documentation, so it can be fixed?

That said, I do acknowledge that the systemd.unit(5) man page could be
clearer what effect it has on %h and %u when setting `User=` when

Which is why I filed the upstream bug report.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever

[Michael Biebl]

Am 28.04.19 um 18:00 schrieb Brad Barnett:
> 
> Package: udev
> Version: 232-25+deb9u11
> 
> After today's upgrade to debian 9.9, I attempted to create a disk image.
> 
> I have a script, it does the following:
> 
> ###
> dd if=/dev/zero of=/tmp/ff1.raw bs=1G seek=8 count=0
> sync
> sleep 1
> parted /tmp/ff1.raw mklabel msdos
> parted -s /tmp/ff1.raw mkpart primary linux-swap 1 100
> parted -s -- /tmp/ff1.raw mkpart primary ext2 101 -1
> parted -s -- /tmp/ff1.raw set 2 boot on
> sleep 5
> losetup -Pf /tmp/ff1.raw --show
> ###
> 
> The above has been run several times per month, for years.
> 
> After today's upgrade I rebooted, ran the above, and it locked on losetup.
> 
> I see this:
> 
> # ps auxwwf
> 
> root   346  0.0  0.1  45656  3420 ?Ss   11:30   0:00 
> /lib/systemd/systemd-udevd --daemon
> root  2596  0.0  0.0  45564  2120 ?S11:31   0:00  \_ 
> /lib/systemd/systemd-udevd --daemon
> root  2597  0.0  0.0  45564  2184 ?D11:31   0:00  \_ 
> /lib/systemd/systemd-udevd --daemon
> root  2599  0.0  0.1  45644  3096 ?S11:31   0:00  \_ 
> /lib/systemd/systemd-udevd --daemon
> root  2602  0.0  0.0  45564  2120 ?D11:31   0:00  \_ 
> /lib/systemd/systemd-udevd --daemon
> root  2603  0.0  0.0  45656  1936 ?D11:31   0:00  \_ 
> /lib/systemd/systemd-udevd --daemon
> root  2607  0.0  0.0  45656  1936 ?D11:31   0:00  \_ 
> /lib/systemd/systemd-udevd --daemon
> root  2609  0.0  0.0  45564  2120 ?D11:31   0:00  \_ 
> /lib/systemd/systemd-udevd --daemon
> root  2610  0.0  0.0  45656  1936 ?D11:31   0:00  \_ 
> /lib/systemd/systemd-udevd --daemon
> root  2612  0.0  0.0  45656  1936 ?D11:31   0:00  \_ 
> /lib/systemd/systemd-udevd --daemon
> 
> And
> 
> root  2591  0.0  0.0   8064   780 pts/2D11:31   0:00 
> /sbin/losetup -Pf /tmp/ff1.raw --show
> 
> I also see this (last 3 'blocks' pasted):
> 
> Apr 28 11:34:17 buildvm kernel: [  242.831744] INFO: task systemd-udevd:2612 
> blocked for more than 120 seconds.
> Apr 28 11:34:17 buildvm kernel: [  242.831807]   Not tainted 
> 4.9.0-9-amd64 #1 Debian 4.9.168-1
> Apr 28 11:34:17 buildvm kernel: [  242.831859] "echo 0 > 
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Apr 28 11:34:17 buildvm kernel: [  242.831927] systemd-udevd   D0  2612   
>  346 0x0004
> Apr 28 11:34:17 buildvm kernel: [  242.831932]  8a2dbb10c400 
>  8a2dbacc5240 8a2dbfa18980
> Apr 28 11:34:17 buildvm kernel: [  242.831939]  af411500 
> af84409e7b58 aee15a99 1e580f2a959617cf
> Apr 28 11:34:17 buildvm kernel: [  242.831946]  000402c0
> 8a2dbfa18980  8a2dbacc5240
> 
> Apr 28 11:34:17 buildvm kernel: [  242.831952] Call Trace:
> Apr 28 11:34:17 buildvm kernel: [  242.831960]  [] ? 
> __schedule+0x239/0x6f0
> Apr 28 11:34:17 buildvm kernel: [  242.831967]  [] ? 
> schedule+0x32/0x80
> Apr 28 11:34:17 buildvm kernel: [  242.831973]  [] ? 
> schedule_preempt_disabled+0xa/0x10
> Apr 28 11:34:17 buildvm kernel: [  242.831977]  [] ? 
> __mutex_lock_slowpath+0xb4/0x130
> Apr 28 11:34:17 buildvm kernel: [  242.831982]  [] ? 
> mutex_lock+0x1b/0x30
> Apr 28 11:34:17 buildvm kernel: [  242.831988]  [] ? 
> lo_open+0x15/0x50 [loop]
> Apr 28 11:34:17 buildvm kernel: [  242.831994]  [] ? 
> __blkdev_get+0xd3/0x470
> Apr 28 11:34:17 buildvm kernel: [  242.832001]  [] ? 
> blkdev_get+0x126/0x330
> Apr 28 11:34:17 buildvm kernel: [  242.832008]  [] ? 
> unlock_new_inode+0x44/0x70
> Apr 28 11:34:17 buildvm kernel: [  242.832014]  [] ? 
> bdget+0xfa/0x110
> Apr 28 11:34:17 buildvm kernel: [  242.832020]  [] ? 
> blkdev_get_by_dev+0x40/0x40
> Apr 28 11:34:17 buildvm kernel: [  242.832026]  [] ? 
> do_dentry_open+0x234/0x340
> Apr 28 11:34:17 buildvm kernel: [  242.832030]  [] ? 
> path_openat+0x777/0x15b0
> Apr 28 11:34:17 buildvm kernel: [  242.832037]  [] ? 
> page_add_file_rmap+0x11/0x110
> Apr 28 11:34:17 buildvm kernel: [  242.832042]  [] ? 
> do_filp_open+0x91/0x100
> Apr 28 11:34:17 buildvm kernel: [  242.832047]  [] ? 
> handle_mm_fault+0xcc3/0x1350
> Apr 28 11:34:17 buildvm kernel: [  242.832052]  [] ? 
> __check_object_size+0xfa/0x1d8
> Apr 28 11:34:17 buildvm kernel: [  242.832058]  [] ? 
> do_sys_open+0x12e/0x210
> Apr 28 11:34:17 buildvm kernel: [  242.832064]  [] ? 
> do_syscall_64+0x8d/0xf0
> Apr 28 11:34:17 buildvm kernel: [  242.832069]  [] ? 
> entry_SYSCALL_64_after_swapgs+0x58/0xc6
> Apr 28 11:36:18 buildvm kernel: [  363.661408] INFO: task losetup:2591 
> blocked for more than 120 seconds.
> Apr 28 11:36:18 buildvm kernel: [  363.661487]   Not tainted 
> 4.9.0-9-amd64 #1 Debian 4.9.168-1
> Apr 28 11:36:18 buildvm kernel: [  363.661541] "echo 0 > 
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Apr 28 11:36:18 buildvm kernel: [  363.661610] losetup D0  2591   
>1 0x0004
> Apr 28 11:36:18 b

Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever

[Michael Biebl]

Am 28.04.19 um 19:41 schrieb Michael Biebl:

> This looks like a kernel regression.
> Do you use a Debian kernel? From which version did you upgrade?
> If you downgrade to the previous kernel version, does the problem go away.

From
https://tracker.debian.org/news/1038093/accepted-linux-49168-1-source-into-proposed-updates-stable-new-proposed-updates/

 https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.162
 - Revert "loop: Fix double mutex_unlock(&loop_ctl_mutex) in
   loop_control_ioctl()"
 - Revert "loop: Get rid of loop_index_mutex"
 - Revert "loop: Fold __loop_release into loop_release"

That looks very suspicious.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever

[Michael Biebl]

Am 28.04.19 um 19:41 schrieb Michael Biebl:
> Do you use a Debian kernel? From which version did you upgrade?
> If you downgrade to the previous kernel version, does the problem go away.

Btw, please use reportbug next time, so we have this information readily
available and don't need to spend time asking for it.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#928102: systemd: CVE-2019-3843 CVE-2019-3844

[Michael Biebl]

Hi

Am 28.04.19 um 09:14 schrieb Salvatore Bonaccorso:
> Please adjust the affected versions in the BTS as needed. I think
> affected versions are back to the one in  stretch were support for
> DynamicUsers were added. Overall though the issue seems to be low
> impacted, thus I have marked it as no-dsa for stretch, but let us know
> if this is wrong assessment for severity.


I agree with this assessment and don't plan to make a stable (or even
buster) upload for this.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever

[Michael Biebl]

Control: reassign -1 linux-image-4.9.0-9-amd64
Control: severity -1 important

Am 28.04.19 um 20:32 schrieb Brad Barnett:
> 
> Ack, should have thought of that. 
> 
> Just tested.  OK kernel:
> 
> 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3 (2019-02-02) x86_64 GNU/Linux
> 
> Borked kernel:
> 
> 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1 (2019-04-12) x86_64
> 
> Hmm.  Just noticed GNU/Linux tag is missing too..


Thanks for checking, Reassigning to the linux package and bumping
severity a bit. Seems like something that should be fixed in stable.

> 
> 
> On Sun, 28 Apr 2019 19:41:47 +0200
> Michael Biebl  wrote:
> 
>> This looks like a kernel regression.
>> Do you use a Debian kernel? From which version did you upgrade?
>> If you downgrade to the previous kernel version, does the problem go
>> away.
> 
> ___
> Pkg-systemd-maintainers mailing list
> Pkg-systemd-maintainers@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
> 


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927458: apt-daily.timer Adding random time every 5 seconds

[Michael Biebl]

On Sat, 20 Apr 2019 04:30:24 + "Boylan, Ross" 
wrote:
> Package: apt
> Version: 1.4.9
> Severity: normal
> 
> Dear Maintainer,
> 
> Severity note: This appears to be relatively trivial problem in its impact 
> on the system.  However, it has two possible more serious consequences:
> 1. The logs will end up taking a lot of space because of the constant messges.
> 2. The repeated randomization may end up producing really wild random numbers,
> as a result of which the timers may fire either way too fast or way too slow.
> 
> The log spam also makes it more difficult to identify interesting things in 
> the log (I know 
> there are ways around that), and the whole process must impose some 
> performance penalty.
> 
>* What led up to the situation?
> After a recent upgrade to stretch, my logs are filled with messages like this
> Apr 19 12:38:27 ross-mail systemd[1]: apt-daily.timer: Adding 9h 57min 
> 34.907602s random time.
> Apr 19 12:38:27 ross-mail systemd[1]: apt-daily-upgrade.timer: Adding 51min 
> 17.211953s random time.
> Apr 19 12:38:32 ross-mail systemd[1]: Time has been changed

The underlying problem is, that your system time constantly changes.
As a result, systemd will recalculate its timers.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927458: apt-daily.timer Adding random time every 5 seconds

[Michael Biebl]

Am 30.04.19 um 10:07 schrieb Michael Biebl:
> The underlying problem is, that your system time constantly changes.
> As a result, systemd will recalculate its timers.

Let me rephrase that: Why is the system time changed every 5s?
How much does your clock drift in that time frame?

I'm asking, because changing the system time every 5s seems pretty
excessive and I try to understand why your system does it.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927911: systemd: Does not expand %h identifier in ExecStart

[Michael Biebl]

Am 26.04.19 um 03:56 schrieb Norbert Preining:
> Hi
> 
>> The man pages say that %h and %u are resolved to the root user if you
>> are using the system instance (PID 1).
>> That is consistent with the behaviour you are getting.
>> If I missed a part which mentions the contrary, could you quote the
>> relevant bits from the documentation, so it can be fixed?
> 
>   Unit files can be parameterized by a single argument called the
>   "instance name". The unit is then constructed based on a "template file"
>   which serves as the definition of multiple services or other units.
>   A template unit must have a single "@" at the end of the name (right
>   before the type suffix). The name of the full unit is formed by 
> inserting
>   the instance name between "@" and the unit type suffix. In the unit file
>   itself, the instance parameter may be referred to 
>   using "%i" and other specifiers, see below.
>  ^^
> 
> There is no real indication what means "below", but the somehow for me
> logical reference is the section
>   Specifiers
> 
>   Many settings resolve specifiers which may be used to write generic
>   unit files referring to runtime or unit parameters that are replaced
>   when the unit files are loaded. Specifiers must be known and resolvable
>   for the setting to be valid. The following specifiers are understood:
> 
>   Table 4. Specifiers available in unit files
>   ...
> 
> In my reading that says:
>   You can use %i and other specifiers **as laid out in the secion
>   "Specifiers" in the Unit file** 
> 
> I searched all occurrences of % in the man page, and that is all that is
> said.

See [1]

>> That said, I do acknowledge that the systemd.unit(5) man page could be
>> clearer what effect it has on %h and %u when setting `User=` when
> 
> I am not sure how this relates to my question.

Section "SPECIFIERS" [1] in systemd.unit(5) says this about %h

>│"%h"  │ User home directory │ This is the 
> home directory of the user   │
>│  │ │ running the 
> service manager instance. In │
>│  │ │ case of the 
> system manager this resolves │
>│  │ │ to "/root". 
>   


So, the documentation says that %h is expanded to the home directory of
root user in your case (as you run the service as system service).
The incorrect bit is, that the documentation says it is expanded to
"/root" whereas really it is "/" for system services.

In your case, you use "User=" and I think (please correct me if I'm
wrong) you expected "%h" to be expanded to the home directory of that
user specified via "User="

That's why I filed an upstream bug report
- to fix the documentation to say "/" instead of "/root"
- to be more explicit that setting "User=" has no effect on %h


[1]
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Specifiers
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927458: apt-daily.timer Adding random time every 5 seconds

[Michael Biebl]

Hi

Am 30.04.19 um 18:22 schrieb Boylan, Ross:
> According to the internet, the time updates every 5 seconds are coming from 
> HyperV, the host hypervisor under which the system in question is running.  
> Why HyperV acts that way I don't know (guessing: to avoid large time jumps); 
> I agree it seems absurd.  I'm running on a VM under HyperV.
> 
> As noted in my original report, these updates can reportedly be suppressed at 
> the hypervisor level but a) it seems that might eventually cause clock drift 
> and b) I have no direct access to the hypervisor (though I could ask someone 
> who does).
> 
> I also don't know if HyperV would react badly if the VM time were not in sync 
> with the host (e.g., disable hyperv time updates + install chrony).  I would 
> hope not, but the aggressive update schedule also suggests it might.

I'm not really convinced, systemd is to blame here.
That said, if you feel strongly about this, please consider filing a bug
report upstream at https://github.com/systemd/systemd/issues
Maybe upstream is willing to add a workaround for this rather
questionable HyperV behaviour.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#927458: apt-daily.timer Adding random time every 5 seconds

[Michael Biebl]

On 30.04.19 20:18, Boylan, Ross wrote:
> What is the result of having time randomization called repeatedly, with our 
> current setup?
> If each randomization adds r seconds, r1 the first time, r2 the second, etc, 
> and t is the original time, is the result after repeated (n) randomizations
> t+rn (the good case)
> t+r1+r2+...+rn (bad case)
> If r is always >=, as the message about adding time suggests, the bad case 
> will probably mean the timer never goes off.
> If r can be negative, it means that the timer will go off at a wildly random 
> time.

You can check when the timer will fire:
Use "systemctl status apt-daily.timer"

I don't think the randomized time is accumulated. Or is this not the
case for you? In that case, I would appreciate a log showing that behaviour.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#928615: Please switch to libidn2

[Michael Biebl]

Am 07.05.19 um 18:56 schrieb Laurent Bigonville:
> Source: systemd
> Version: 241-3
> Severity: wishlist
> 
> Hi,
> 
> It might be intresting to switch from libidn11 to libidn2
> 
> On a freshly debootstrapped chroot, libidn2 is already installed:
> 
> # apt-cache rdepends --installed libidn2-0
> libidn2-0
> Reverse Depends:
>   libc6
>   iputils-ping
>   libgnutls30
> 
> While libidn11 is only used by systemd:
> 
> # apt-cache rdepends --installed libidn11
> libidn11
> Reverse Depends:
>   systemd

Sure, fine with me.


Does
https://salsa.debian.org/systemd-team/systemd/commit/4338e49e744376d2b47afb14f85d944f0e871a89
look to you?
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#921267: systemd fails to reach shutdown.target when rebooting or shutting down the system after resuming from suspend

[Michael Biebl]

Control: tags -1 - moreinfo

There has been progress in tracking down the root cause of this issue:
https://github.com/systemd/systemd/issues/11810#issuecomment-489727505

Turns out, RDRAND, which is used to generate uuid's is not stable on
certain AMD processor models after a resume.
This is arguably a firmware/hardware issue and should best be fixed in
the kernel by blacklisting affected CPU models.
https://github.com/systemd/systemd/issues/11810#issuecomment-490275562
suggests that this is specific to AMD CPU family 22, but needs verification.

A fixed kernel for buster seems unlikely at this point, so I wonder
whether we should revert
https://github.com/systemd/systemd/commit/cc83d5197ca08d68fa78167b6a64e9f28da3cc96
i.e. systemd will use getrandom() for uuid generation.

The Debian kernel uses CONFIG_RANDOM_TRUST_CPU=y and it is my
understanding that with CONFIG_RANDOM_TRUST_CPU=y it is less likely that
getrandom() will stall during boot due to missing entropy.

Would welcome input from other team members and Ben, how we should
proceed here for buster.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#928659: systemd: "systemctl reboot " broken since v240 - fixed in v242

[Michael Biebl]

Am 08.05.19 um 15:09 schrieb Serge Schneider:
> Package: systemd
> Version: 241-3+rpi1
> Severity: normal
> 
> Dear Maintainer,
> 
> v240 of systemd broke the mechanism that passes reboot arguments to the 
> kernel.
> https://github.com/systemd/systemd/issues/11828
> 
> I've tested that adding this patch to the current Buster version (241-3) 
> resolves the problem.
> https://github.com/vesajaaskelainen/systemd/commit/b4bf7e500b28362c2bf50f0320dc66a55b92cda2.patch
> 
> I don't know if the issue is considered critical enough to update the package 
> now that Buster is frozen,
> but it would certainly be appreciated.

Thanks for the detailed bug report.
Seems reasonable to get this fix into buster.
As I was planning to make a 241-4 for buster anyway, I'll consider
including this patch.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#921267: systemd fails to reach shutdown.target when rebooting or shutting down the system after resuming from suspend

[Michael Biebl]

William,

Am 08.05.19 um 13:52 schrieb Michael Biebl:
> 
> A fixed kernel for buster seems unlikely at this point, so I wonder
> whether we should revert
> https://github.com/systemd/systemd/commit/cc83d5197ca08d68fa78167b6a64e9f28da3cc96
> i.e. systemd will use getrandom() for uuid generation.

upstream has proposed a different approach which attempts to filter out
bogus data from RDRAND.
See https://github.com/systemd/systemd/issues/11810#issuecomment-490284361

I've built test packages with that proposed patch applied and uploaded
them to https://people.debian.org/~biebl/systemd/buster/
Could you test those packages and report back if that fixes your problems?

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#928686: systemd: XFS filesystem errors when using systemd suspend-then-hibernate target

[Michael Biebl]

Am 08.05.2019 um 23:06 schrieb Shubhra Prakash Nandi:
> Package: systemd
> Version: 241-3
> Severity: important
> 
> Dear Maintainer,
> 
> I saw XFS errors in syslog as given below when I updated suspend target in 
> logind.conf to use suspend-then-hibernate instead. 
> These errors do not appear when I use only suspend target or suspend sedation 
> solution as given in this Debian wiki - 
> https://wiki.debian.org/SystemdSuspendSedation which is basically an 
> alternative to suspend-then-hibernate systemd target.
> 
> XFS errors happen irrespective to when suspend level is s2idle or s2ram 
> (deep).
> 
> I expect suspend-then-hibernate should work similar to SystemdSuspendSedation 
> solution given in Debian wiki where no XFS filesystem errors appear.
> 
> May  4 00:04:09 my-pc kernel: [  332.306253] PM: suspend entry (deep)
> May  4 00:04:09 my-pc systemd-sleep[5254]: Suspending system...
> May  4 00:04:10 my-pc kernel: [  332.306257] PM: Syncing filesystems ... done.
> May  4 00:04:10 my-pc kernel: [  333.478986] (NULL device *): firmware: 
> direct-loading firmware iwlwifi-9000-pu-b0-jf-b0-38.ucode
> May  4 00:04:30 my-pc kernel: [  333.542791] (NULL device *): firmware: 
> direct-loading firmware i915/kbl_dmc_ver1_04.bin
> May  4 00:04:30 my-pc kernel: [  333.543080] Freezing user space processes 
> ... (elapsed 0.003 seconds) done.
> May  4 00:04:30 my-pc kernel: [  333.546820] OOM killer disabled.
> May  4 00:04:30 my-pc kernel: [  333.546821] Freezing remaining freezable 
> tasks ... 
> May  4 00:04:30 my-pc kernel: [  353.550044] Freezing of tasks failed after 
> 20.003 seconds (1 tasks refusing to freeze, wq_busy=0):
> May  4 00:04:30 my-pc kernel: [  353.550073] xfsaild/dm-7D0   775 
>  2 0x8000
> May  4 00:04:30 my-pc kernel: [  353.550079] Call Trace:
> May  4 00:04:30 my-pc kernel: [  353.550095]  ? __schedule+0x2a2/0x870
> May  4 00:04:30 my-pc kernel: [  353.550101]  schedule+0x28/0x80
> May  4 00:04:30 my-pc kernel: [  353.550106]  schedule_timeout+0x26d/0x390
> May  4 00:04:30 my-pc kernel: [  353.550113]  wait_for_completion+0x11f/0x190
> May  4 00:04:30 my-pc kernel: [  353.550121]  ? wake_up_q+0x70/0x70
> May  4 00:04:30 my-pc kernel: [  353.550217]  ? __xfs_buf_submit+0x122/0x240 
> [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550290]  ? xfs_buf_read_map+0x106/0x170 
> [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550372]  ? 
> xfs_trans_read_buf_map+0xaa/0x2e0 [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550444]  xfs_buf_iowait+0x22/0xd0 [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550516]  __xfs_buf_submit+0x122/0x240 
> [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550585]  xfs_buf_read_map+0x106/0x170 
> [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550667]  
> xfs_trans_read_buf_map+0xaa/0x2e0 [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550736]  xfs_imap_to_bp+0x67/0xd0 [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550814]  xfs_iflush+0x10f/0x240 [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550893]  xfs_inode_item_push+0x13c/0x190 
> [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550971]  xfsaild+0x3a4/0x7e0 [xfs]
> May  4 00:04:30 my-pc kernel: [  353.551048]  ? 
> xfs_trans_ail_cursor_first+0x80/0x80 [xfs]
> May  4 00:04:30 my-pc kernel: [  353.551054]  kthread+0x112/0x130
> May  4 00:04:30 my-pc kernel: [  353.551059]  ? kthread_bind+0x30/0x30
> May  4 00:04:30 my-pc kernel: [  353.551065]  ret_from_fork+0x35/0x40
> May  4 00:04:30 my-pc kernel: [  353.551146] Restarting kernel threads ... 
> done.
> May  4 00:04:30 my-pc kernel: [  353.552574] OOM killer enabled.
> May  4 00:04:30 my-pc kernel: [  353.552575] Restarting tasks ... done.

This looks like a kernel problem, not a systemd problem.
Can you elaborate why you filed this against systemd?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#928982: Bug: 'systemctl is-enabled' return enabled/true when alias symlinks exist

[Michael Biebl]

Am 14.05.19 um 16:58 schrieb Martin Olsson:
> Package: systemd
> Version: 232-25+deb9u11
> 
> Problem:
> The command 'systemctl is-enabled myfoobar.target' return "enabled"
> (exit code 0) when it should return "disabled" (code >0).


Please share the full myfoobar.target


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929072: systemd: Dependency propagation on units inconsistent during start

[Michael Biebl]

Am 16.05.19 um 13:21 schrieb Drexl Johannes:
> during a more complicated setup of different services we found something
> odd when starting single branches. Minimal setup to reproduce:

Thanks for your bug report.
To make it easier to reproduce, can you please attach the (dummy)
services to illustrate the problem and also explicitly list the commands
you used.
Also, as you mentioned that this is not a Debian specific problem, it's
usually best to file such issues upstream at
https://github.com/systemd/systemd/issues
Can you do that?

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929152: systemd emergency mode: cannot mount directory on /mnt

[Michael Biebl]

Control: tags -1 + moreinfo

On 18.05.19 10:25, -- wrote:
> Package: systemd
> Version: 241-3
> Severity: normal
> 
> 
> 1. add to /etc/fstab
> UUID=broken_uuid  /mntbtrfs   defaults0 0
> 2. reboot
> 3. Wait for the prompt "A start job is running"
> 4. Login
> 5. "mount /dev/vda /mnt" won't work (ls /mnt will be empty)
> 6. "mount /dev/vda /srv" (or any other directory) works

Why is this a systemd problem?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926886: Please mention video->render change in udev.NEWS

[Michael Biebl]

Am 23.04.19 um 19:48 schrieb Guido Günther:

> On Tue, Apr 23, 2019 at 07:29:52PM +0200, Michael Biebl wrote:

>> Hm, I'm a bit undecided. This seems like a very special setup you have
>> there and a NEWS entry is shown to basically every user.
>> If it was a more common issue, I would totally agree with you.
> 
> I was on the fence here as well. It's something not very common but if it
> hits you it's quite annoying.

So, I've added such a NEWS entry for udev
https://salsa.debian.org/systemd-team/systemd/commit/e3772a013721083a740ab9dedbf060cf5b3c3709
but either I made a mistake or apt-listchanges is buggy, since on none
of my systems this NEWS entry was shown.

Any ideas?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Fwd: Linux (RHEL 7.6 with OSP 14) Bugs

[Michael Biebl]

Am 18.05.19 um 18:53 schrieb Amer Hwitat:

> I didn't test on Debian flavors but I think it's the same, the problem
> is with RabbitMQ heart beats, when the server is disconnected it times
> out causing this problem of kernel loop.
> 

That doesn't look like a systemd problem, so I doubt we can help you
with that, especially since it does happen on a RHEL system where we
have no experience with.

There a likely better support channels then this list to ask RHEL
specific questions.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929215: unblock: systemd/241-4

[Michael Biebl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package systemd

All patches are cherry-picked from upstream git.

Annotated changelog:

systemd (241-4) unstable; urgency=medium

  * journal-remote: Do not request Content-Length if Transfer-Encoding is
chunked (Closes: #927008)

https://salsa.debian.org/systemd-team/systemd/commit/d8e4bc4487b0f32b39b15152040351261329e92a

Without this fix, systemd-journal-remote is pretty much completely
broken, that's why I had marked this bug RC for the
systemd-journal-remote package


  * systemctl: Restore "systemctl reboot ARG" functionality.
Fixes a regression introduced in v240. (Closes: #928659)

https://salsa.debian.org/systemd-team/systemd/commit/8127cbd86fadf245dd28666c1bfe82a3eb116448


  * random-util: Eat up bad RDRAND values seen on AMD CPUs.
Some AMD CPUs return bogus data via RDRAND after a suspend/resume cycle
while still reporting success via the carry flag.
Filter out invalid data like -1 (and also 0, just to be sure).
(Closes: #921267)

https://salsa.debian.org/systemd-team/systemd/commit/efbcf5102f0ac7b43a2f7b8c79084fdfd2d1fa72

RDRAND is used by systemd for its hashmap implementation. On some AMD
CPUs (AMD CPU family 22), RDRAND returns bogus data after
suspend/resume, leading to severe mis-behaviour of systemd. Typical
symptoms are failure to shutdown properly or when trying suspend again.


  * Add check to switch VTs only between K_XLATE or K_UNICODE.
Switching to K_UNICODE from other than L_XLATE can make the keyboard
unusable and possibly leak keypresses from X.
(CVE-2018-20839, Closes: #929116)

https://salsa.debian.org/systemd-team/systemd/commit/5a564c6ef3906c0f3885a3a2aafce772393f760a


  * Document that DRM render nodes are now owned by group "render"
(Closes: #926886)

https://salsa.debian.org/systemd-team/systemd/commit/e3772a013721083a740ab9dedbf060cf5b3c3709

Documentation update, which was explicitly requested for the
video->render change of the the /dev/dri/renderD* devices.

KiBi (and debian-boot) is in CC

Full debdiff is attached.

Regards,
Michael

unblock systemd/241-4

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 231cbb6..e13fd93 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,23 @@
+systemd (241-4) unstable; urgency=medium
+
+  * journal-remote: Do not request Content-Length if Transfer-Encoding is
+chunked (Closes: #927008)
+  * systemctl: Restore "systemctl reboot ARG" functionality.
+Fixes a regression introduced in v240. (Closes: #928659)
+  * random-util: Eat up bad RDRAND values seen on AMD CPUs.
+Some AMD CPUs return bogus data via RDRAND after a suspend/resume cycle
+while still reporting success via the carry flag.
+Filter out invalid data like -1 (and also 0, just to be sure).
+(Closes: #921267)
+  * Add check to switch VTs only between K_XLATE or K_UNICODE.
+Switching to K_UNICODE from other than L_XLATE can make the keyboard
+unusable and possibly leak keypresses from X.
+(CVE-2018-20839, Closes: #929116)
+  * Document that DRM render nodes are now owned by group "render"
+(Closes: #926886)
+
+ -- Michael Biebl   Fri, 17 May 2019 21:16:33 +0200
+
 systemd (241-3) unstable; urgency=high
 
   [ Michael Biebl ]
diff --git 
a/debian/patches/Add-check-to-switch-VTs-only-between-K_XLATE-or-K_UNICODE.patch
 
b/debian/patches/Add-check-to-switch-VTs-only-between-K_XLATE-or-K_UNICODE.patch
new file mode 100644
index 000..6efd7ec
--- /dev/null
+++ 
b/debian/patches/Add-check-to-switch-VTs-only-between-K_XLATE-or-K_UNICODE.patch
@@ -0,0 +1,56 @@
+From: Balint Reczey 
+Date: Wed, 24 Apr 2019 17:24:02 +0200
+Subject: Add check to switch VTs only between K_XLATE or K_UNICODE
+
+Switching to K_UNICODE from other than L_XLATE can make the keyboard
+unusable and possibly leak keypresses from X.
+
+BugLink: https://launchpad.net/bugs/1803993
+(cherry picked from commit 13a43c73d8cbac4b65472de04bb88ea1bacdeb89)
+---
+ src/basic/terminal-util.c | 9 -
+ src/vconsole/vconsole-setup.c | 7 +++
+ 2 files changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/src/basic/terminal-util.c b/src/basic/terminal-util.c
+index 48ede7d..c7a7455 100644
+--- a/src/basic/terminal-util.c
 b/src/basic/terminal-util.c
+@@ -1273,11 +1273,18 @@ int vt_verify_kbmode(int fd) {
+ }
+ 
+ int vt_reset_keyboard(int fd) {
+-int kb;
++int kb, r;
+ 
+

Bug#926886: Please mention video->render change in udev.NEWS

[Michael Biebl]

Am 19.05.19 um 13:43 schrieb Guido Günther:

> On Sat, May 18, 2019 at 01:20:05PM +0200, Michael Biebl wrote:

>> https://salsa.debian.org/systemd-team/systemd/commit/e3772a013721083a740ab9dedbf060cf5b3c3709
>> but either I made a mistake or apt-listchanges is buggy, since on none
>> of my systems this NEWS entry was shown.
>>
>> Any ideas?
> 
> I can at least confirm that I didn't see the new entry when upgrading
> udev. The NEWS entry looks correct though and apt-listchanges seems to
> think it showed it:
> 
> # apt-listchanges --profile=apt --dump-seen | grep systemd
> libconfig-model-systemd-perl 0.239.1-1
> systemd 241-4
> 

I wonder if apt-listchanges gets confused, if a src package ships
multiple (different) NEWS files in different binary packages.

I just made a dist-upgrade of a test VM from stretch to buster, and
noticed that quite a few NEWS entries were missing / not shown.
E.g. the 2.29.2-3 news entry for the "mount" package (built from
src:util-linux) was missing as well. So seems to a general problem.

Looks like a rather important bug in apt-listchanges to me.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#926886: Please mention video->render change in udev.NEWS

[Michael Biebl]

Am 19.05.19 um 13:43 schrieb Guido Günther:
> # apt-listchanges --profile=apt --dump-seen | grep systemd
> libconfig-model-systemd-perl 0.239.1-1
> systemd 241-4

Hm, interesting. That returns

$ apt-listchanges --profile=apt --dump-seen | grep systemd
systemd 241-1

Which makes no sense at all, as there was no NEWS entry for 241-1.
Neither for udev nor systemd.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929229: systemd, udev -- keyboard freezes after exiting X in version 241-4

[Michael Biebl]

Control: reassign -1 systemd 241-4
Control: severity -1 serious
Control: forwarded -1 https://github.com/systemd/systemd/issues/12616

Am 19.05.19 um 18:51 schrieb S R Wright:
> Package: systemd, udev
> Version: 241-4
> Kernel: seen in 5.1.3 and 4.19.44
> 
>> dpkg -l | egrep "^ii" | egrep "241-4"
> ii  libnss-systemd:amd64  241-4
> amd64nss module providing dynamic user and group name resolution
> ii  libpam-systemd:amd64  241-4
> amd64system and service manager - PAM module
> ii  libsystemd0:amd64 241-4
> amd64systemd utility library
> ii  libudev1:amd64241-4
> amd64libudev shared library
> ii  systemd   241-4
> amd64system and service manager
> ii  systemd-sysv  241-4
> amd64system and service manager - SysV links
> ii  udev  241-4
> amd64/dev/ and hotplug management daemon
> 
> 
> I am unsure whether the problem is with systemd or udev, but while 
> operational with versions 241-3, upon upgrading to 241-4, the keyboard stops 
> working after exiting X. I am using startx and fvwm.


It's
https://salsa.debian.org/systemd-team/systemd/commit/5a564c6ef3906c0f3885a3a2aafce772393f760a
So in the systemd package. Reassigning accordingly and bumping to RC.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929229: systemd, udev -- keyboard freezes after exiting X in version 241-4

[Michael Biebl]

Am 19.05.19 um 21:13 schrieb S R Wright:
> Is this confined to systemd 241-4?  Will back-revving to 241-3 be a
> sufficient workaround?

It will. To satisfy dependencies, you'll need to downgrade libsystemd0
as well (and libpam-systemd, libnss-systemd, systemd-* in case you have
those installed)

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929462: systemd-journal-remote: systemd-journal-upload user missing

[Michael Biebl]

Control: tags -1 = moreinfo unreproducible
Control: severity -1 normal

Am 24.05.19 um 02:24 schrieb Paul Emmerich:
> Package: systemd-journal-remote
> Version: 241-3
> Severity: grave
> Justification: renders package unusable
> Tags: newcomer
> 
> Dear Maintainer,
> 
> we are maintaining a Debian live image that uses systemd-journal-remote to
> send log files to a log collector. The systemd-journal-upload unit fails
> to start on buster:
> 
> May 22 07:23:34 ceph06 systemd[1]: Starting Journal Remote Upload Service...
> May 22 07:23:34 ceph06 systemd[40869]: systemd-journal-upload.service: Failed 
> to determine user credentials: No such process
> May 22 07:23:34 ceph06 systemd[40869]: systemd-journal-upload.service: Failed 
> at step USER spawning /usr/local/bin/update-journal-configuration.sh: No such 
> process
> 
> It tries to run as user systemd-journal-upload which seems to be missing.

I can't reproduce the problem in a buster VM.
systemd-journal-upload.service uses
DynamicUser, so it is not necessary to allocate a static system user.

Do you have libnss-systemd installed? If not, does it help if you
install it?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929480: systemd: systemctl hangs while starting services waiting for systemd-tty-ask-password-agent

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

Am 24.05.19 um 12:12 schrieb root:
> Package: systemd
> Version: 232-25+deb9u11
> Severity: important
> 
> Dear Maintainer,
> 
> * What led up to the situation?
> Fresh install of Raspbian.
> 
> * What exactly did you do (or not do) that was effective (or ineffective)?
> Installed gpsd, chrony. Then tried to restart chronyd from ssh.
> 
> * What was the outcome of this action?
> systemctl hangs while starting chronyd waiting for 
> systemd-tty-ask-password-agent what shouldn't happen, because root does not 
> need to be asked for passwords.
> 
> * What outcome did you expect instead?
> systemctl starting chronyd (or other services) regardless waiting for any 
> password entry.
> 
> This bug is a regression. It was reported about four years ago, fixed. And 
> now it is there again.

Unfortunately, I can't reproduce the problem, so it will be hard to
further diagnose it. Can you reproduce the issue (reliably)?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929488: buster: system hangs on shutdowwn

[Michael Biebl]

Control: tags -1 + moreinfo

Am 24.05.19 um 16:19 schrieb gilles.nau...@laposte.net:
> Package: systemd-sysv
> Version: 241-3
> Debain Version: buster
> Severity: important
> 
> Dear maintainers:
> 
> I tried to upgrade my laptop from Stretch to Buster.( I use lightldm for
> login and Xface  as DM).
> On shutdown, the screen freezes and I have to power off my laptop manually.
> I found that the command "lspci" hangs also the system.
> I went back to Stretch and run "lshw" command : you will find the result
> at the end of my message.
> I have the same behavior with the Debian-Live-buster DVD : so, I can
> execute complementary command in order to find out where is the bug.


Can you please change the kernel command and remove the "quiet"
parameter and instead add "systemd.log_level=debug"

Then shutdown and make a screenshot when it hangs.
Which command did you use to shutdown the system?

If lspci freezes your system, you might have a kernel problem.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929652: systemd: sshd processes are not put into the correct slice/scope

[Michael Biebl]

Control: tags -1 + moreinfo

Am 27.05.19 um 23:03 schrieb Simon Beirnaert:
> Package: systemd
> Version: 232-25+deb9u11
> Severity: normal
> 
> Dear Maintainer,
> 
> 
> Systemd does not seem to consistently put sshd processes under the
> relevant user's slice. I have a user with 10925 sshd processes related
> to its sessions. 7552 of those are put under session scopes in the
> user's slice. 3372 are put under system.slice (ssh.service). The ones
> under the user slice are neatly grouped into session scopes whereas
> the ones under the system slice are not.
> 
> This is making it impossible to put accurate limits to the sshd
> processes, or the user's processes. I can set TasksMax, but that only
> has a value if the tasks are counted correctly.
> 
> If there's any more information needed to debug this, please let me
> know.

You need to have libpam-systemd enabled and PAM support in sshd as well
for processes spawned from an SSH session to be put in the user slice.

~11000 sshd processes for one user seems unusual. What kind of setup is
this? Are you sure all those sshd processes were going through the PAM
stack?
You might add the "debug" flag to the pam_systemd.so config to get more
information.
What do you get from pam_systemd.so for an exemplary sshd process which
is not put into the user slice? Do you get anything in the journal from
systemd-logind for this process?
You can increase what's being logged by systemd-logind with
"systemd-analyze log-level"

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929655: Obscure "Failed to set invocation ID for unit: File exists" error

[Michael Biebl]

Control: forcemerge 921267 -1

Am 28.05.19 um 00:59 schrieb Kathryn Tolsen:
> Package: systemd
> Version: 241-3
> Severity: Serious
> 
> All systemd services are failing to start, best guess is, this is
> related to:
> 
> https://github.com/systemd/systemd/issues/11810

This is already fixed in 241-4 and a duplicate of #921267

Merging accordingly.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929655: Confirmed issue 11810, release-critical

[Michael Biebl]

Am 28.05.19 um 23:35 schrieb Kathryn Tolsen:

> Thank you, and *pokes the D-I team* this means YOU! We need this update
> to 241-4 or 241-5!

241-4 resp. 241-5 waits for an unblock from the release team and the
installer team.
See the request at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929215


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929726: ask-password: prevent buffer overrow when reading from keyring

[Michael Biebl]

Thanks for the patch, Dan.
I see this has already been committed upstream, which is great.

Am 29.05.19 um 17:50 schrieb Dan Streetman:
> +Subject: [PATCH] ask-password: prevent buffer overrow when reading from
 ^
I assume this is a typo and you meant either buffer overrun or overflow

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929728: systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug

[Michael Biebl]

Am 29.05.19 um 18:02 schrieb Dan Streetman:
> Package: systemd
> Version: 241-5
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu eoan ubuntu-patch
> 
> Dear Maintainer,
> 
> 'storage' test fails on some archs/releases trying to modprobe and/or rmmod 
> scsi_debug.
> 

I've never seen this failure. Can you eloborate on the conditions when
this happens?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929730: systemd: boot-and-services test expects first kernel log line, but not always in logs

[Michael Biebl]

Am 29.05.19 um 18:19 schrieb Dan Streetman:
> Package: systemd
> Version: 241-5
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu eoan ubuntu-patch
> 
> Dear Maintainer,
> 
> boot-and-services test expects the first(ish) kernel log line to be in the 
> system logs, but that is not guaranteed to be in the logs.
> 
> -- Package-specific info:
> 
> 
>   * d/t/boot-and-services:
> - don't fail if some kernel msgs are missed (LP: #1830479)


Afair, this is due to the kernel ring buffer being too small (on arm64)
Wouldn't it be better to address that? After all, you also want early
boot messages when running systemd in production.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929652: systemd: sshd processes are not put into the correct slice/scope

[Michael Biebl]

Am 04.06.19 um 14:25 schrieb Simon Beirnaert:
> Sorry for the late reply here. Got caught up in other stuff. I did 
> some digging around. Set the loglevel with systemd-analyze to debug 
> and also added the debug flag to pam_systemd.so.
> 
> What I noticed is that on boot, when 5000+ machines try to 
> authenticate at once, pam_systemd seems to fall on its ass and fail 
> due to resource exhaustion. An excerpt from journalctl is attached 
> below.
> 
> I thought this might've been the reason behind sshd processes not 
> being assigned to the correct slice, but the processes for which 
> these log entries are generated are not available on the system 
> anymore, which I take as meaning that the sshd process exited 
> because it couldn't open a session.
> 
> I tried to go about it the other way around and search for logs 
> generated by any sshd process which is under the system.slice. I
> used this oneliner to do so:
> 
> for i in $(systemctl status ssh | grep 'sshd: ' | sed -E 
> 's/[^0-9]*([0-9]*)[^0-9]*/\1/'); do echo "==> logs for process $i"; 
> journalctl | grep '\[$i\]'; done | less
> 
> The search came up empty. For none of the currently 7000+ sshd 
> processes which aren't in the correct user slice, there are any logs 
> in journalctl. I verified and all logs since boot time are currently 
> still in the journal, it hasn't rotated yet.
> 

If you have 5000 users authenticate at once, I can imagine, that
libpam-systemd/systemd/dbus run into some limits.
Would you mind testing with v241 (either from backports or by setting up
a buster system) and if the problem is still reproducible, file it
upstream at https://github.com/systemd/systemd/issues

Thanks,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929728: systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug

[Michael Biebl]

Hi Dan

Am 29.05.19 um 18:02 schrieb Dan Streetman:
> Package: systemd
> Version: 241-5
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu eoan ubuntu-patch
> 
> Dear Maintainer,
> 
> 'storage' test fails on some archs/releases trying to modprobe and/or rmmod 
> scsi_debug.
> 
> -- Package-specific info:
> 
> 
>   * d/t/storage:
> - fix handling of scsi_debug module, test drives (LP: #1829347)
> 

If you submit a merge request via
https://salsa.debian.org/systemd-team/systemd it makes it a bit easier
to review and apply the changes.


Since Martin is our autopkgtest expert I'd prefer if he reviews this patch.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929730: systemd: boot-and-services test expects first kernel log line, but not always in logs

[Michael Biebl]

Am 29.05.19 um 18:49 schrieb Dan Streetman:
> On Wed, May 29, 2019 at 12:35 PM Michael Biebl  wrote:
>>
>> Am 29.05.19 um 18:19 schrieb Dan Streetman:
>>> Package: systemd
>>> Version: 241-5
>>> Severity: normal
>>> Tags: patch
>>> User: ubuntu-de...@lists.ubuntu.com
>>> Usertags: origin-ubuntu eoan ubuntu-patch
>>>
>>> Dear Maintainer,
>>>
>>> boot-and-services test expects the first(ish) kernel log line to be in the 
>>> system logs, but that is not guaranteed to be in the logs.
>>>
>>> -- Package-specific info:
>>>
>>>
>>>   * d/t/boot-and-services:
>>> - don't fail if some kernel msgs are missed (LP: #1830479)
>>
>>
>> Afair, this is due to the kernel ring buffer being too small (on arm64)
>> Wouldn't it be better to address that? After all, you also want early
>> boot messages when running systemd in production.
> 
> that's one reason; is systemd missing kernel messages due to no fault
> of its own really something that should fail the test case?
> 

Good question. Since Martin is our autopkgtest expert, it's probably
best to wait for his reply here.

Again, if you submit a MR via salsa, you make it a bit easier for us to
review and apply the changes.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929488: buster: system hangs on shutdowwn

[Michael Biebl]

On Fri, 24 May 2019 16:48:09 +0200 Michael Biebl  wrote:
> Control: tags -1 + moreinfo
> 
> Am 24.05.19 um 16:19 schrieb gilles.nau...@laposte.net:
> > Package: systemd-sysv
> > Version: 241-3
> > Debain Version: buster
> > Severity: important
> > 
> > Dear maintainers:
> > 
> > I tried to upgrade my laptop from Stretch to Buster.( I use lightldm for
> > login and Xface  as DM).
> > On shutdown, the screen freezes and I have to power off my laptop manually.
> > I found that the command "lspci" hangs also the system.
> > I went back to Stretch and run "lshw" command : you will find the result
> > at the end of my message.
> > I have the same behavior with the Debian-Live-buster DVD : so, I can
> > execute complementary command in order to find out where is the bug.
> 
> 
> Can you please change the kernel command and remove the "quiet"
> parameter and instead add "systemd.log_level=debug"
> 
> Then shutdown and make a screenshot when it hangs.
> Which command did you use to shutdown the system?
> 
> If lspci freezes your system, you might have a kernel problem.

Any updates?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#914015: bus-daemon: Activated service 'org.freedesktop.systemd1' failed

[Michael Biebl]

On Mon, 13 May 2019 16:07:27 +0100 Simon McVittie  wrote:
> Control: reassign -1 systemd
> 
> On Sun, 18 Nov 2018 at 15:52:39 +0100, Helge Kreutzmann wrote:
> > At the very end of the boot, just after the first user logs in
> > (usually using sddm / X) I get the following messages in my logs:
> > Nov 18 07:02:33 samd dbus-daemon[2879]: [session uid=1000 pid=2877] 
> > Activated service 'org.freedesktop.systemd1' failed: Process 
> > org.freedesktop.systemd1 exited with status 1
> > Nov 18 07:02:33 samd dbus-daemon[2879]: [session uid=1000 pid=2877] 
> > Activated service 'org.freedesktop.systemd1' failed: Process 
> > org.freedesktop.systemd1 exited with status 1
> 
> These messages are caused by the "stub" service files that systemd
> installs. It installed them because early versions of systemd activation
> required them to exist.
> 
> Since dbus 1.11.0, a dbus-daemon that is run with --systemd-activation
> automatically assumes that o.fd.systemd1 is an activatable
> service. As a result, after Debian 10 'buster' is released,
> /usr/share/dbus-1/services/org.freedesktop.systemd1.service and
> /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service should
> become unnecessary, and they can be removed from the systemd package for
> bullseye.
> 
> (Pedantically, systemd ought to have Breaks: dbus (<< 1.11.0) after that
> change is made, but we don't support upgrades that skip a release.)

I assume we will still need the stub service files for the other
services provided by systemd? Looking through system-services, I have

org.freedesktop.hostname1.service:Exec=/bin/false
org.freedesktop.import1.service:Exec=/bin/false
org.freedesktop.locale1.service:Exec=/bin/false
org.freedesktop.login1.service:Exec=/bin/false
org.freedesktop.machine1.service:Exec=/bin/false
org.freedesktop.network1.service:Exec=/bin/false
org.freedesktop.resolve1.service:Exec=/bin/false
org.freedesktop.systemd1.service:Exec=/bin/false
org.freedesktop.timedate1.service:Exec=/bin/false
org.freedesktop.timesync1.service:Exec=/bin/false


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

[Michael Biebl]

On Fri, 24 May 2019 09:30:50 +0200 =?utf-8?q?Rapha=C3=ABl_Hertzog?=
 wrote:
> Package: systemd
> Version: 241-3
> Severity: serious
> File: systemd-networkd
> User: de...@kali.org
> Usertags: origin-kali
> 
> I upgraded an (OVH) dedicated server to Debian buster with systemd 241-3 and
> while it rebooted correctly, the network did not came back. Looking into
> the logs I saw the following messages:
> 
> May 20 12:37:10 euterpe systemd-networkd[756]: eno3: Could not bring up 
> interface: Invalid argument
> May 20 12:37:14 euterpe systemd-networkd[756]: eno3: Gained carrier
> May 20 12:37:14 euterpe systemd-networkd[756]: eno3: could not set address: 
> Permission denied

What's the status of this bug?
Can you reproduce it with v242 from experimental?
I guess upstream is waiting for your feedback:
https://github.com/systemd/systemd/issues/12656#issuecomment-496293294

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

[Michael Biebl]

Am 05.06.19 um 14:03 schrieb Raphael Hertzog:
> Hi,
> 
> On Wed, 05 Jun 2019, Michael Biebl wrote:
>> What's the status of this bug?
> 
> No progress.
> 
>> Can you reproduce it with v242 from experimental?
> 
> Yes.
> 
>> I guess upstream is waiting for your feedback:
>> https://github.com/systemd/systemd/issues/12656#issuecomment-496293294
> 
> I will provide my result with systemd from git master soon. But there's
> not much else that I can do.

systemd-networkd.service in v241 is locked down more tightly then v232.
It might be worth a try to comment out the hardening features one by one
to see if one of them causes your problem.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#930077: systemd: add :native to python3-evdev build dependency

[Michael Biebl]

Am 06.06.19 um 17:13 schrieb W. Martin Borgert:
> Source: systemd
> Version: 241-5
> 
> Please change the build dependency
> 
>  python3-evdev ,
> 
> to
> 
>  python3-evdev:native ,
> 
> Only with that change I could cross-compile the package. TIA!

Could you give a bit more details on why this is necessary and e.g. why
python3-pyparsing does not need :native?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#930077: systemd: add :native to python3-evdev build dependency

[Michael Biebl]

Am 06.06.19 um 22:16 schrieb W. Martin Borgert:
> On 2019-06-06 19:59, Michael Biebl wrote:
>> Could you give a bit more details on why this is necessary and e.g. why
>> python3-pyparsing does not need :native?
> 
> I'm not even sure myself, but I try my best :-)
> 
> Short: python3-evdev is any, python3-pyparsing is all.
> 
> Longer: When cross-building, one needs the -dev packages for the
> host arch, e.g. building on amd64 for armel needs
> libfoo-dev:armel. Anything that is executed during build, e.g.
> yacc, lex, Python stuff must be amd64, of course. The Python
> interpreter must be amd64 ("native), and that counts for "any"
> modules, too, e.g. python3-evdev. python3-pyparsing is "all", so
> there is no need for :native.

I guess the problem is that python3.7 is marked as Multi-Arch: allowed?

Bringing Helmut into the loop here.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#930105: systemd: prerm fail breaks apt and renders system hard to recover

[Michael Biebl]

Control: severity -1 normal

Am 07.06.19 um 00:55 schrieb Adam Borowski:
> Source: systemd
> Version: 241-5
> Severity: critical
> Justification: breaks the whole system
> 
> 
> When trying to switch to any other init system (and d-i offers no way to
> start with anything but systemd), prerm refuses to uninstall _in the middle
> of the apt run_.  This leaves the system in a broken state, with a good part
> of tools refusing to start (including apt itself), and for obvious reasons
> unbootable.  Anyone without a good knowledge of dpkg's internals would be
> unable to recover the system at all.  To even attempt recovery, one has to
> rm -rf /run/systemd or otherwise neuter the prerm script.
> 
> Thus, what's even the point of this prerm check?  The way dependencies
> between systemd components are written, getting apt to even attempt removing
> systemd requires a pretty deliberate action.  If, unlike other init systems,
> systemd can't cleanly shut down, it's a problem but for any remotely
> adequate modern piece of software not a fatal one: any filesystem from this
> millenium won't corrupt data on an unexpected power loss, any database
> worth its salt won't corrupt data without intentionally defeating fsync, and
> so on.   Ie, without the prerm check you may need a SysRq-B or power cycle,
> with it you currently end with up with system that can't even run apt.

The prerm check is there for a reason (to be able to cleanly shutdown)
and switch over.
Once that is done, you can opt to remove the systemd package if you so
desire.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#930120: init: Documentation error for telinit/init - does not use 'systemctl isolate xxx'

[Michael Biebl]

Control: tags -1 + moreinfo

Am 07.06.19 um 15:51 schrieb J. Pfennig:
> The man page of telinit/init says (for 'telinit N'):
> 
>Change the SysV runlevel. This is translated into an activation request 
> for runlevel2.target,
>runlevel3.target, ... and is equivalent to systemctl isolate 
> runlevel2.target, systemctl isolate
>runlevel3.target, ...
> 
> But when using telinit 2 or init 2 (or event booting the kernel with "2"
> as an argument), the effective operation is:
> 
> 'systemctl start runlevel2.target'
> ### but not 'sytemctl isolate runlevel2.target' ### as documented
> 

I'm pretty sure "telinit" uses isolate.
See
https://github.com/systemd/systemd/blob/master/src/initctl/initctl.c#L101

So the documentation looks correct to me.
Please elaborate


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#930652: systemd removes static ipv4 address from ethernet sporadically

[Michael Biebl]

Control: tags -1 + moreinfo

Am 17.06.2019 um 18:35 schrieb Joshua Hudson:
> Package: systemd
> Version: 241-5
> Severity: important
> 
> This is in fact a corporate server; real email is jhud...@cedaron.com
> but if I try to use that source for reportbug, nothing goes through. :(
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> Machine has been losing ipv4 address out of ethernet sporadically.
> This machine does not use NetworkManager anymore as all interfaces are static.
> ifup should run at boot and nothing ever touch network configuration
> again.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Uninstalled NetworkManager, thinking that was the culpret. It wasn't.
> There's not much left on the machine that monitors network interfaces.
> 
>

If you are using ifup (ifupdown) to configure your network and
systemd-networkd is not active, why is this bug report filed against
systemd?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#930652: systemd removes static ipv4 address from ethernet sporadically

[Michael Biebl]

[please always CC the bug report]

Am 17.06.2019 um 18:54 schrieb Joshua Hudson:
> systemd-networkd is active. NetworkManager is not.

Well, the systemd-analyze dump you attached to this bug report shows
systemd-networkd.service as inactive. And you also said this:


>> Am 17.06.2019 um 18:35 schrieb Joshua Hudson:
>>> Machine has been losing ipv4 address out of ethernet sporadically.
>>> This machine does not use NetworkManager anymore as all interfaces are
>>> static.
>>> ifup should run at boot and nothing ever touch network configuration
>>> again.

ifup is provided by the ifupdown package.

Please provide logs, which show that systemd-networkd is actually active
and share your networkd network configuration.
It's really hard to make sense out of this bug report.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#930652: systemd removes static ipv4 address from ethernet sporadically

[Michael Biebl]

If you do actually use networkd, please share your networkd
configuration and provide a debug log.
See
https://coreos.com/os/docs/latest/network-config-with-networkd.html#debugging-networkd

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#930120: init: Documentation error for telinit/init - does not use 'systemctl isolate xxx'

[Michael Biebl]

On Fri, 7 Jun 2019 17:32:00 +0200 Michael Biebl  wrote:
> Control: tags -1 + moreinfo
> 
> Am 07.06.19 um 15:51 schrieb J. Pfennig:
> > The man page of telinit/init says (for 'telinit N'):
> > 
> >Change the SysV runlevel. This is translated into an activation request 
> > for runlevel2.target,
> >runlevel3.target, ... and is equivalent to systemctl isolate 
> > runlevel2.target, systemctl isolate
> >runlevel3.target, ...
> > 
> > But when using telinit 2 or init 2 (or event booting the kernel with "2"
> > as an argument), the effective operation is:
> > 
> > 'systemctl start runlevel2.target'
> > ### but not 'sytemctl isolate runlevel2.target' ### as documented
> > 
> 
> I'm pretty sure "telinit" uses isolate.
> See
> https://github.com/systemd/systemd/blob/master/src/initctl/initctl.c#L101
> 
> So the documentation looks correct to me.
> Please elaborate


I still don't see the problem here, that said if you feel strongly about
this and think this needs to be addressed, please raise this upstream at
https://github.com/systemd/systemd/issues

After all, this doesn't look like a Debian specific issue.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#913222: journalctl: bash-completion: incorrect sorting of --priority arguments

[Michael Biebl]

Will be fixed in v243.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#851402: failed unmounting /var during shutdown

[Michael Biebl]

Will be fixed in v243.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#904913: systemd: systemctl cat 'foo*' (using shellglob patterns) only lists active units

[Michael Biebl]

Should be fixed in v243.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

[Michael Biebl]

Hi Raphael,

On Tue, 11 Jun 2019 15:51:14 +0200 Raphael Hertzog 
wrote:
> Hi,
> 
> On Wed, 05 Jun 2019, Michael Biebl wrote:
> > systemd-networkd.service in v241 is locked down more tightly then v232.
> > It might be worth a try to comment out the hardening features one by one
> > to see if one of them causes your problem.
> 
> Thanks for the idea! I tried that but it did not help. I found the issue
> after a few more tries tweaking the network configuration file. It's
> simply that the system has IPv6 disabled in the kernel policy while the
> .network file instructs to configure an IPv6 address.
> 
> Both are contradictory but they happily lived together up-to-now.
> I don't know what changed but if we don't improve systemd-networkd
> to just skip IPv6 configuration when the kernel has a policy disabling
> IPv6, then we will have plenty of servers broken on upgrades because
> it's quite common to keep the network configuration file provided by
> the hoster and just disable IPv6 at the kernel level with sysctl:
> 
> $ grep ipv6 /etc/sysctl.conf
> # Disable ipv6
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.lo.disable_ipv6 = 1

Ok, thanks for figuring out the root cause.
Given that this only happens under very special circumstances and
networkd not being enabled by default, I'm not entirely sure if this
issue should qualify as RC.
Cherry-picking the 6 upstream commits leads to a merge conflict when
applied on top of v241 and I haven't yet investigated if those can
easily be resolved.
TBH, I feel a bit uneasy doing this change so late in the release cycle
and personally I would downgrade this issue to non-RC and fix this via a
v243 upload to buster-backports.

If you feel strongly about this though, please feel free ask the release
team if the change is ok. A tested patch set would be great in this case.

Regards,
Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers