Bug#893054: systemd: System failed to boot after upgrade/install systemd from systemd:i386

2018-03-15 Thread Jeff Ketchum 
Actually, I was able to just now get it to boot with that config, so this
seems to be an intermittent problem. I hit it most of the time.
It is during boot, and systemd

It may not be with systemd, but that is where the upgrades came from,
everything else was working before that.

Here is another failed boot. this is the last thing in the log.

Mar 15 16:54:56 jket-deb NetworkManager[794]:   [1521154496.1043]
device (enp3s0): carrier: link connected
Mar 15 16:54:56 jket-deb ModemManager[788]:   Couldn't check support
for device '/sys/devices/pci:00/:00:1c.2/:03:00.0': not
supported by any plugin
Mar 15 16:54:56 jket-deb ModemManager[788]:   Couldn't check support
for device '/sys/devices/pci:00/:00:1c.7/:04:00.0': not
supported by any plugin
Mar 15 16:55:26 jket-deb NetworkManager[794]:   [1521154526.2209]
device (br0): carrier: link connected
Mar 15 16:55:27 jket-deb avahi-daemon[795]: Joining mDNS multicast group on
interface br0.IPv6 with address fe80::fab1:56ff:feb8:524a.
Mar 15 16:55:27 jket-deb avahi-daemon[795]: New relevant interface br0.IPv6
for mDNS.
Mar 15 16:55:27 jket-deb avahi-daemon[795]: Registering new address record
for fe80::fab1:56ff:feb8:524a on br0.*.
Mar 15 16:55:29 jket-deb avahi-daemon[795]: Leaving mDNS multicast group on
interface br0.IPv6 with address fe80::fab1:56ff:feb8:524a.
Mar 15 16:55:29 jket-deb avahi-daemon[795]: Joining mDNS multicast group on
interface br0.IPv6 with address 2603:3026:414:b1f0:fab1:56ff:feb8:524a.
Mar 15 16:55:29 jket-deb avahi-daemon[795]: Registering new address record
for 2603:3026:414:b1f0:fab1:56ff:feb8:524a on br0.*.
Mar 15 16:55:29 jket-deb avahi-daemon[795]: Withdrawing address record for
fe80::fab1:56ff:feb8:524a on br0.
Mar 15 16:55:53 jket-deb systemd-udevd[429]: seq 2260
'/devices/pci:00/:00:01.0/:01:00.0' is taking a long time
Mar 15 16:55:55 jket-deb systemd-udevd[429]: seq 3061
'/devices/virtual/vtconsole/vtcon1' is taking a long time
Mar 15 16:57:53 jket-deb systemd-udevd[429]: seq 2260
'/devices/pci:00/:00:01.0/:01:00.0' killed
Mar 15 16:57:55 jket-deb systemd-udevd[429]: seq 3061
'/devices/virtual/vtconsole/vtcon1' killed
Mar 15 16:57:55 jket-deb systemd-udevd[429]: worker [466] terminated by
signal 9 (KILL)
Mar 15 16:57:55 jket-deb systemd-udevd[429]: worker [466] failed while
handling '/devices/virtual/vtconsole/vtcon1'
Mar 15 17:00:38 jket-deb NetworkManager[794]:   [1521154838.7769]
device (wlp4s0): set-hw-addr: set MAC address to 6E:1A:B4:B7:1B:66
(scanning)
Mar 15 17:00:38 jket-deb NetworkManager[794]:   [1521154838.7973]
device (wlp4s0): supplicant interface state: ready -> disabled
Mar 15 17:00:38 jket-deb NetworkManager[794]:   [1521154838.8324]
device (wlp4s0): supplicant interface state: disabled -> inactive
Mar 15 17:00:38 jket-deb wpa_supplicant[793]: wlp4s0: Reject scan trigger
since one is already pending


On Thu, Mar 15, 2018 at 4:40 PM, Michael Biebl  wrote:

> Am 15.03.2018 um 23:31 schrieb Jeff Ketchum:
> > Package: systemd
> > Version: 238-2
> > Severity: normal
> >
> >
> >
> > -- Package-specific info:
> >
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers unstable
> >   APT policy: (500, 'unstable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
> > Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
> LANGUAGE=en_US.utf8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages systemd depends on:
> > ii  adduser  3.117
> > ii  libacl1  2.2.52-3+b1
> > ii  libapparmor1 2.12-3
> > ii  libaudit11:2.8.2-1
> > ii  libblkid12.31.1-0.5
> > ii  libc62.27-2
> > ii  libcap2  1:2.25-1.2
> > ii  libcryptsetup12  2:2.0.1-1
> > ii  libgcrypt20  1.8.1-4
> > ii  libgpg-error01.27-6
> > ii  libidn11 1.33-2.1
> > ii  libip4tc01.6.2-1
> > ii  libkmod2 25-1
> > ii  liblz4-1 0.0~r131-2+b1
> > ii  liblzma5 5.2.2-1.3
> > ii  libmount12.31.1-0.5
> > ii  libpam0g 1.1.8-3.7
> > ii  libseccomp2  2.3.1-2.1
> > ii  libselinux1  2.7-2+b1
> > ii  libsystemd0  238-2
> > ii  mount2.31.1-0.5
> > ii  procps   2:3.3.12-4
> > ii  util-linux   2.31.1-0.5
> >
> > Versions of packages systemd recommends:
> > ii  dbus1.12.6-2
> > ii  libpam-systemd  238-2
> >
> > Versions of packages systemd suggests:
> > ii  policykit-10.105-18
> > pn  systemd-container  
> >
> > Versions of packages systemd is related to:
> > pn  dracut   
> > ii  initramfs-tools  0.130
> > ii  udev 238-2
> >
> > -- Configuration Files:
> > /etc/systemd/journald.conf changed:
> > [Journal]
> > Storage=auto
> >
> >
> > -- no debconf information
> >
> > I upgraded systemd, and after a failure to boot, realized it was on
> >

Bug#893054: systemd: System failed to boot after upgrade/install systemd from systemd:i386

2018-03-15 Thread Michael Biebl 
Am 15.03.2018 um 23:31 schrieb Jeff Ketchum:
> Package: systemd
> Version: 238-2
> Severity: normal
> 
> 
> 
> -- Package-specific info:
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
> LANGUAGE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages systemd depends on:
> ii  adduser  3.117
> ii  libacl1  2.2.52-3+b1
> ii  libapparmor1 2.12-3
> ii  libaudit11:2.8.2-1
> ii  libblkid12.31.1-0.5
> ii  libc62.27-2
> ii  libcap2  1:2.25-1.2
> ii  libcryptsetup12  2:2.0.1-1
> ii  libgcrypt20  1.8.1-4
> ii  libgpg-error01.27-6
> ii  libidn11 1.33-2.1
> ii  libip4tc01.6.2-1
> ii  libkmod2 25-1
> ii  liblz4-1 0.0~r131-2+b1
> ii  liblzma5 5.2.2-1.3
> ii  libmount12.31.1-0.5
> ii  libpam0g 1.1.8-3.7
> ii  libseccomp2  2.3.1-2.1
> ii  libselinux1  2.7-2+b1
> ii  libsystemd0  238-2
> ii  mount2.31.1-0.5
> ii  procps   2:3.3.12-4
> ii  util-linux   2.31.1-0.5
> 
> Versions of packages systemd recommends:
> ii  dbus1.12.6-2
> ii  libpam-systemd  238-2
> 
> Versions of packages systemd suggests:
> ii  policykit-10.105-18
> pn  systemd-container  
> 
> Versions of packages systemd is related to:
> pn  dracut   
> ii  initramfs-tools  0.130
> ii  udev 238-2
> 
> -- Configuration Files:
> /etc/systemd/journald.conf changed:
> [Journal]
> Storage=auto
> 
> 
> -- no debconf information
> 
> I upgraded systemd, and after a failure to boot, realized it was on
> systemd:i386.
> I went into a recovery environment and removed systemd:i386 and
> installed systemd.
> After that It failed to boot at a different location.
> I was able to get it to boot by removing the kernel parameter
> for the nouveau driver to use the binary firmware.
> 
> nouveau.config=NvGrUseFw=1

Where exactly is the problem that is caused by 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@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#893054: systemd: System failed to boot after upgrade/install systemd from systemd:i386

2018-03-15 Thread Jeff Ketchum 
Package: systemd
Version: 238-2
Severity: normal



-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.117
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.12-3
ii  libaudit11:2.8.2-1
ii  libblkid12.31.1-0.5
ii  libc62.27-2
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.1-1
ii  libgcrypt20  1.8.1-4
ii  libgpg-error01.27-6
ii  libidn11 1.33-2.1
ii  libip4tc01.6.2-1
ii  libkmod2 25-1
ii  liblz4-1 0.0~r131-2+b1
ii  liblzma5 5.2.2-1.3
ii  libmount12.31.1-0.5
ii  libpam0g 1.1.8-3.7
ii  libseccomp2  2.3.1-2.1
ii  libselinux1  2.7-2+b1
ii  libsystemd0  238-2
ii  mount2.31.1-0.5
ii  procps   2:3.3.12-4
ii  util-linux   2.31.1-0.5

Versions of packages systemd recommends:
ii  dbus1.12.6-2
ii  libpam-systemd  238-2

Versions of packages systemd suggests:
ii  policykit-10.105-18
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 238-2

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
Storage=auto


-- no debconf information

I upgraded systemd, and after a failure to boot, realized it was on
systemd:i386.
I went into a recovery environment and removed systemd:i386 and
installed systemd.
After that It failed to boot at a different location.
I was able to get it to boot by removing the kernel parameter
for the nouveau driver to use the binary firmware.

nouveau.config=NvGrUseFw=1

Mar 14 10:39:17 jket-deb kernel: nouveau :01:00.0: bios: version 
80.06.41.00.0a
Mar 14 10:39:17 jket-deb kernel: nouveau :01:00.0: firmware: direct-loading 
firmware nvidia/gk106/fecs_inst.bin
Mar 14 10:39:17 jket-deb kernel: nouveau :01:00.0: firmware: direct-loading 
firmware nvidia/gk106/fecs_data.bin
Mar 14 10:39:17 jket-deb kernel: nouveau :01:00.0: firmware: direct-loading 
firmware nvidia/gk106/gpccs_inst.bin
Mar 14 10:39:17 jket-deb kernel: nouveau :01:00.0: firmware: direct-loading 
firmware nvidia/gk106/gpccs_data.bin
Mar 14 10:39:17 jket-deb kernel: nouveau :01:00.0: fb: 1024 MiB GDDR5

Mar 14 10:39:18 jket-deb kernel: nouveau :01:00.0: DRM: allocated 1920x1080 
fb: 0x6, bo 125ba628
Mar 14 10:39:18 jket-deb kernel: fbcon: nouveaufb (fb0) is primary device


Mar 14 10:39:51 jket-deb avahi-daemon[793]: Joining mDNS multicast group on 
interface br0.IPv6 with address fe80::fab1:56ff:feb8:524a.
Mar 14 10:39:51 jket-deb avahi-daemon[793]: New relevant interface br0.IPv6 for 
mDNS.
Mar 14 10:39:51 jket-deb avahi-daemon[793]: Registering new address record for 
fe80::fab1:56ff:feb8:524a on br0.*.
Mar 14 10:39:52 jket-deb avahi-daemon[793]: Leaving mDNS multicast group on 
interface br0.IPv6 with address fe80::fab1:56ff:feb8:524a.
Mar 14 10:39:52 jket-deb avahi-daemon[793]: Joining mDNS multicast group on 
interface br0.IPv6 with address 2603:3026:414:b1f0:fab1:56ff:feb8:524a.
Mar 14 10:39:52 jket-deb avahi-daemon[793]: Registering new address record for 
2603:3026:414:b1f0:fab1:56ff:feb8:524a on br0.*.
Mar 14 10:39:52 jket-deb avahi-daemon[793]: Withdrawing address record for 
fe80::fab1:56ff:feb8:524a on br0.
Mar 14 10:40:17 jket-deb systemd-udevd[439]: seq 2262 
'/devices/pci:00/:00:01.0/:01:00.0' is taking a long time
Mar 14 10:40:19 jket-deb systemd-udevd[439]: seq 3069 
'/devices/virtual/vtconsole/vtcon1' is taking a long time

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

Bug#892989: weird chars found in dpkg output

2018-03-15 Thread Michael Biebl 
Am 15.03.2018 um 18:11 schrieb Michael Biebl:
> Am 15.03.2018 um 14:38 schrieb Guillem Jover:
> 
>> AFAIR, this is coming from systemd, and the character should be an
>> arrow (→), but I assume there's some kind of locale/encoding problem
>> somewhere. Perhaps even a misconfiguration in your system, but I'll
>> leave that up to the systemd maintainers.
> 
> Harald, what is your locale?
> What do you get if you run systemctl enable/disable directly?

Oh, and which version of systemd is this?

Btw, I can't really reproduce your problem:
With a UTF-8 locale (which you really should enable), systemctl will use
'→', for a non-UTF8 locale, systemctl will fall back to '->'


-- 
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@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#892989: weird chars found in dpkg output

2018-03-15 Thread Michael Biebl 
Am 15.03.2018 um 14:38 schrieb Guillem Jover:

> AFAIR, this is coming from systemd, and the character should be an
> arrow (→), but I assume there's some kind of locale/encoding problem
> somewhere. Perhaps even a misconfiguration in your system, but I'll
> leave that up to the systemd maintainers.

Harald, what is your locale?
What do you get if you run systemctl enable/disable directly?




-- 
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@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#893014: marked as done (systemd: journalctl -g and --grep fail (in different ways))

2018-03-15 Thread Debian Bug Tracking System 
Your message dated Thu, 15 Mar 2018 18:09:25 +0100
with message-id <630c41a4-828b-4796-a8c5-c3a5d4813...@debian.org>
and subject line Re: Bug#893014: systemd: journalctl -g and --grep fail (in 
different ways)
has caused the Debian Bug report #893014,
regarding systemd: journalctl -g and --grep fail (in different ways)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
893014: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893014
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 237-4
Severity: normal

journalctl(1) says:

   -g, --grep=
   Filter output to entries where the MESSAGE= field matches the
   specified regular expression. PERL-compatible regular expressions
   are used, see pcre2pattern(3) for a detailed description of the
   syntax.

   If the pattern is all lowercase, matching is case insensitive.
   Otherwise, matching is case sensitive. This can be overridden with
   the --case-sensitive option, see below.


however:

0 dkg@alice:~$ journalctl --grep=hello
Compiled without pattern matching support
0 dkg@alice:~$ journalctl -g hello
journalctl: invalid option -- 'g'
1 dkg@alice:~$ 


note that --grep=hello returns 0 and provides a user-comprehensible
warning about why it didn't work.

but -g hello returns 1 and just gives an incomprehensible error
message that doesn't indicate why it's failing.

I think the right approach would be to return a non-zero error code in
both cases, and to print the same reasonable explanation in both
cases.

--dkg

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.117
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.12-3
ii  libaudit11:2.8.2-1
ii  libblkid12.31.1-0.4
ii  libc62.27-1
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.1-1
ii  libgcrypt20  1.8.1-4
ii  libgpg-error01.27-6
ii  libidn11 1.33-2.1
ii  libip4tc01.6.2-1
ii  libkmod2 25-1
ii  liblz4-1 0.0~r131-2+b1
ii  liblzma5 5.2.2-1.3
ii  libmount12.31.1-0.4
ii  libpam0g 1.1.8-3.7
ii  libseccomp2  2.3.1-2.1
ii  libselinux1  2.7-2+b1
ii  libsystemd0  237-4
ii  mount2.31.1-0.4
ii  procps   2:3.3.12-4
ii  util-linux   2.31.1-0.4

Versions of packages systemd recommends:
ii  dbus1.12.6-2
ii  libpam-systemd  237-4

Versions of packages systemd suggests:
ii  policykit-10.105-18
ii  systemd-container  237-4

Versions of packages systemd is related to:
ii  dracut   047-2
pn  initramfs-tools  
ii  udev 237-4

-- Configuration Files:
/etc/systemd/resolved.conf changed [not included]

-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 238-1

Am 15.03.2018 um 15:39 schrieb Daniel Kahn Gillmor:
> Package: systemd
> Version: 237-4
> Severity: normal
> 
> journalctl(1) says:
> 
>-g, --grep=
>Filter output to entries where the MESSAGE= field matches the
>specified regular expression. PERL-compatible regular expressions
>are used, see pcre2pattern(3) for a detailed description of the
>syntax.
> 
>If the pattern is all lowercase, matching is case insensitive.
>Otherwise, matching is case sensitive. This can be overridden with
>the --case-sensitive option, see below.
> 
> 
> however:
> 
> 0 dkg@alice:~$ journalctl --grep=hello
> Compiled without pattern matching support
> 0 dkg@alice:~$ journalctl -g hello
> journalctl: invalid option -- 'g'
> 1 dkg@alice:~$ 
> 
> 
> note that --grep=hello returns 0 and provides a user-comprehensible
> warning about why it didn't work.
> 
> but -g hello returns 1 and just gives an incomprehensible error
> message that doesn't indicate why it's failing.
> 
> I think the right approach would be to return a non-zero error code in
> both cases, and to print the same reasonable explanation in both
> cases.
> 

-g was not

Bug#893014: systemd: journalctl -g and --grep fail (in different ways)

2018-03-15 Thread Daniel Kahn Gillmor 
Package: systemd
Version: 237-4
Severity: normal

journalctl(1) says:

   -g, --grep=
   Filter output to entries where the MESSAGE= field matches the
   specified regular expression. PERL-compatible regular expressions
   are used, see pcre2pattern(3) for a detailed description of the
   syntax.

   If the pattern is all lowercase, matching is case insensitive.
   Otherwise, matching is case sensitive. This can be overridden with
   the --case-sensitive option, see below.


however:

0 dkg@alice:~$ journalctl --grep=hello
Compiled without pattern matching support
0 dkg@alice:~$ journalctl -g hello
journalctl: invalid option -- 'g'
1 dkg@alice:~$ 


note that --grep=hello returns 0 and provides a user-comprehensible
warning about why it didn't work.

but -g hello returns 1 and just gives an incomprehensible error
message that doesn't indicate why it's failing.

I think the right approach would be to return a non-zero error code in
both cases, and to print the same reasonable explanation in both
cases.

--dkg

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.117
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.12-3
ii  libaudit11:2.8.2-1
ii  libblkid12.31.1-0.4
ii  libc62.27-1
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.1-1
ii  libgcrypt20  1.8.1-4
ii  libgpg-error01.27-6
ii  libidn11 1.33-2.1
ii  libip4tc01.6.2-1
ii  libkmod2 25-1
ii  liblz4-1 0.0~r131-2+b1
ii  liblzma5 5.2.2-1.3
ii  libmount12.31.1-0.4
ii  libpam0g 1.1.8-3.7
ii  libseccomp2  2.3.1-2.1
ii  libselinux1  2.7-2+b1
ii  libsystemd0  237-4
ii  mount2.31.1-0.4
ii  procps   2:3.3.12-4
ii  util-linux   2.31.1-0.4

Versions of packages systemd recommends:
ii  dbus1.12.6-2
ii  libpam-systemd  237-4

Versions of packages systemd suggests:
ii  policykit-10.105-18
ii  systemd-container  237-4

Versions of packages systemd is related to:
ii  dracut   047-2
pn  initramfs-tools  
ii  udev 237-4

-- Configuration Files:
/etc/systemd/resolved.conf changed [not included]

-- no debconf information

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

Processed: Re: Bug#892989: weird chars found in dpkg output

2018-03-15 Thread Debian Bug Tracking System 
Processing control commands:

> reassign -1 systemd
Bug #892989 [dpkg] weird chars found in dpkg output
Bug reassigned from package 'dpkg' to 'systemd'.
No longer marked as found in versions dpkg/1.18.24.
Ignoring request to alter fixed versions of bug #892989 to the same values 
previously set

-- 
892989: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892989
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

Bug#892585: systemd: can not create user.slice/user session, after upgrade systemd from 237-4 to 238-1/2

2018-03-15 Thread johnw 

Hi, only me have this problem?
Any idea, why new version(238-x) systemd, can not create user-slice?
and can not start "/usr/bin/start-pulseaudio-x11" ??
--
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC



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

Bug#892651: Bug#892794: systemd-networkd fails to configure IPv6 without MTU from RA

2018-03-15 Thread Florent Fourcot 

Hello,

I confirm that patched package works as well for networks with MTU 
options enabled in RA.


I used nldecap tool (https://github.com/etene/nldecap) to check systemd 
behavior for IPv6 configuration.


232-25+deb9u1 => not reading MTU at all, and it breaks partially IPv6 
connectivity for networks with lower MTU (regression between jessie and 
stretch, since systemd was not configuring IPv6 before and that kernel 
was reading MTU values).


nldecap output (for a link without MTU enabled, but same trace for a 
link with MTU):


[packet 528] route, message 1 (unknown type)
├─header
│ ├─pid : 1
│ ├─length : 92
[...]
│ │ ├─flags : 0
│ │ ├─attrs
│ │ │ ├[0] RTA_GATEWAY : 'fe80::50:43ff:fef5:1c47'
│ │ │ ├[1] RTA_PRIORITY : 0
│ │ │ ├[2] RTA_PREF : '00'
│ │ │ └[3] RTA_OIF : 2
│ │ ├─table : 254



232-25+deb9u2 => working MTU, but no default route anymore for networks 
without MTU option provided. nldecap reports only route provided with 
MTU attribute (not a surprise, consistent with the current bug report), 
routes without MTU are not configured at all.


nldecap output with MTU enabled (see new RTA_METRICS field):

[packet 2] route, message 1 (unknown type)
├─header
│ ├─pid : 1
│ ├─length : 104
[...]
│ │ ├─flags : 0
│ │ ├─attrs
│ │ │ ├[0] RTA_GATEWAY : 'fe80::224:d4ff:fea7:108'
│ │ │ ├[1] RTA_PRIORITY : 0
│ │ │ ├[2] RTA_PREF : '00'
│ │ │ ├[3] RTA_OIF : 2
│ │ │ └[4] RTA_METRICS
│ │ │   └─attrs
│ │ │ └[0] RTAX_MTU : 1480
│ │ ├─table : 254


With version compiled by Cyril Brulebois, both version are working, but 
there is a small difference for link without MTU (RTA_metrics is set, 
even if this is empty):


├─header
│ ├─pid : 1
│ ├─length : 96
[...]
│ │ ├─flags : 0
│ │ ├─attrs
│ │ │ ├[0] RTA_GATEWAY : 'fe80::50:43ff:fef5:1c47'
│ │ │ ├[1] RTA_PRIORITY : 0
│ │ │ ├[2] RTA_PREF : '00'
│ │ │ ├[3] RTA_OIF : 2
│ │ │ └[4] RTA_METRICS   <= this is new
│ │ │   └─attrs : []
│ │ ├─table : 254

For the best of my knowledge, it's safe and should not have any side 
effect. But it's not exactly the same netlink packet than with version 
232-25+deb9u1


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

Bug#892651: Bug#892794: systemd-networkd fails to configure IPv6 without MTU from RA

2018-03-15 Thread Cyril Brulebois 
Hi Russ,

Russ Allbery  (2018-03-14):
> Cyril Brulebois  writes:
> 
> > I've put up an amd64 build for stretch here:
> >   https://people.debian.org/~kibi/systemd/
> 
> > along with the source package. I'm also attaching the source debdiff.
> 
> > I'm not tagging this bug report with +patch yet, as this needs to be
> > tested on networks with and without advertised MTU (in case that doesn't
> > work in the latter case, reverting the commit introduced in the 9.4
> > point release might be just as good…).
> 
> Thank you!  I've built this for one of my systems where I was having this
> problem and upgraded systemd, libsystemd0, libpam-systemd, and
> libnss-resolve to the updated version.  I can confirm that IPv6 is still
> working fine on that system on a network that doesn't advertise an MTU,
> and I'm not seeing the errors in my logs.

Thanks for the confirmation!

I've just received a matching report:
 - without MTU, current packages: same error as you regarding the lack
   of data.
 - without MTU, patched packages: the error goes away, and the
   interface's MTU is used.
 - with specific MTU, both current and patched packages: the RA's MTU is
   used.

This seems to confirm two things:
 - the proposed patch fixes the regression;
 - the “let's look at the advertised MTU in the RA” feature introduced
   by the last upload still works fine.

So it looks to me we should consider going forward with this extra
patch, instead of simply reverting the patch introduced in the last
upload. I'll leave the final word to the systemd maintainers, of course.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#892651: Bug#892794: systemd-networkd fails to configure IPv6 without MTU from RA

2018-03-15 Thread Cyril Brulebois 
Marc Haber  (2018-03-15):
> On Thu, Mar 15, 2018 at 05:24:07AM +0100, Cyril Brulebois wrote:
> > I've put up an amd64 build for stretch here:
> >   https://people.debian.org/~kibi/systemd/
> > 
> > along with the source package. I'm also attaching the source debdiff.
> 
> I would need to build my own systemd since I need two other patches for
> crippling IPv6 bugs to have a useable systemd-networkd.
> 
> Do I still need to do that?
> 
> That being said, please consider applying the two other patches from
> #869995 to get working IPv6 in stretch's sytstemd-networkd as well.

The maintainers might want to investigate those extra two patches, but
I'm personally interested in fixing the regression introduced by my
suggested change. Having more moving parts doesn't seem too helpful to
achieve that.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#892651: Bug#892794: systemd-networkd fails to configure IPv6 without MTU from RA

2018-03-15 Thread Marc Haber 
On Thu, Mar 15, 2018 at 05:24:07AM +0100, Cyril Brulebois wrote:
> I've put up an amd64 build for stretch here:
>   https://people.debian.org/~kibi/systemd/
> 
> along with the source package. I'm also attaching the source debdiff.

I would need to build my own systemd since I need two other patches for
crippling IPv6 bugs to have a useable systemd-networkd.

Do I still need to do that?

That being said, please consider applying the two other patches from
#869995 to get working IPv6 in stretch's sytstemd-networkd as well.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

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