Debian Bug report logs - #837759
network configuration stops working reliably

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Wolfgang Walter <wolfgang.walter@stwm.de>

To: submit@bugs.debian.org

Subject: network configuration stops working reliably

Date: Wed, 14 Sep 2016 11:59:57 +0200

Package: systemd
Version: 231-6
Severity: grave

Starting with version 231-6 the configuration of network interfaces stops 
working reliably when rebooting a system. Downgrading to 231-5 fixes the 
problem.

Symptoms: If a network interface is configured using /etc/network/interfaces 
it seems that systemd now sometimes removes the configured ip4 and/or ipv6 
addresses in the boot process. It also seems to remove routes of network 
interfaces configured manually or with /etc/network/interfaces if the link 
state changes.

This seems not only be the case with interfaces configured via /etc/network/
interfaces but with any interface one creates and assigns ip addresses 
manually.

I tested this with a script:

#!/bin/sh
if [ "$1" = start ]; then
ip link del TEST >/dev/null 2>&1 || true
ip link add name TEST type dummy
ip -b - <<"EOF"
link set TEST up
addr add 10.10.10.10/32 dev TEST nodad
addr add 2a01:1:1:1::1/128 dev TEST nodad
addr add 2a01:1:1:1::2/128 dev TEST nodad
addr add 2a01:1:1:1::3/128 dev TEST nodad
addr add 2a01:1:1:1::4/128 dev TEST nodad
addr add 2a01:1:1:1::5/128 dev TEST nodad
EOF
ip addr ls TEST
sleep 2
elif [ "$1" = stop ]; then
ip addr flush dev TEST
ip link del TEST
fi

which I start with as a systemd oneshot service with
	Before=systemd-networkd.service

I can see in the journal that TEST has all adresses assigned but with 231-6 it 
looses them again (probably when systemd-networkd.service starts). With 231-5 
or earlier this in not the case.


Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Message #10 received at 837759@bugs.debian.org (full text, mbox, reply):

From: Felipe Sateler <fsateler@debian.org>

To: Wolfgang Walter <wolfgang.walter@stwm.de>, 837759@bugs.debian.org

Subject: Re: Bug#837759: network configuration stops working reliably

Date: Wed, 14 Sep 2016 10:00:28 -0300

Control: tags -1 moreinfo

On 14 September 2016 at 06:59, Wolfgang Walter <wolfgang.walter@stwm.de> wrote:
> Package: systemd
> Version: 231-6
> Severity: grave
>
> Starting with version 231-6 the configuration of network interfaces stops
> working reliably when rebooting a system. Downgrading to 231-5 fixes the
> problem.
>
> Symptoms: If a network interface is configured using /etc/network/interfaces
> it seems that systemd now sometimes removes the configured ip4 and/or ipv6
> addresses in the boot process. It also seems to remove routes of network
> interfaces configured manually or with /etc/network/interfaces if the link
> state changes.
>
> This seems not only be the case with interfaces configured via /etc/network/
> interfaces but with any interface one creates and assigns ip addresses
> manually.
>
> I tested this with a script:
>
> #!/bin/sh
> if [ "$1" = start ]; then
> ip link del TEST >/dev/null 2>&1 || true
> ip link add name TEST type dummy
> ip -b - <<"EOF"
> link set TEST up
> addr add 10.10.10.10/32 dev TEST nodad
> addr add 2a01:1:1:1::1/128 dev TEST nodad
> addr add 2a01:1:1:1::2/128 dev TEST nodad
> addr add 2a01:1:1:1::3/128 dev TEST nodad
> addr add 2a01:1:1:1::4/128 dev TEST nodad
> addr add 2a01:1:1:1::5/128 dev TEST nodad
> EOF
> ip addr ls TEST
> sleep 2
> elif [ "$1" = stop ]; then
> ip addr flush dev TEST
> ip link del TEST
> fi
>
> which I start with as a systemd oneshot service with
>         Before=systemd-networkd.service
>
> I can see in the journal that TEST has all adresses assigned but with 231-6 it
> looses them again (probably when systemd-networkd.service starts). With 231-5
> or earlier this in not the case.

It appears you are using systemd-networkd. Could you please attach
your networkd configuration?

Version 231-6 is built with iptables support, so that may be causing
an interaction that was not visible before.

-- 

Saludos,
Felipe Sateler

Message #17 received at 837759@bugs.debian.org (full text, mbox, reply):

From: Wolfgang Walter <wolfgang.walter@stwm.de>

To: Felipe Sateler <fsateler@debian.org>

Cc: 837759@bugs.debian.org

Subject: Re: Bug#837759: network configuration stops working reliably

Date: Wed, 14 Sep 2016 17:56:15 +0200

Am Mittwoch, 14. September 2016, 10:00:28 schrieben Sie:

> Control: tags -1 moreinfo
> 
> On 14 September 2016 at 06:59, Wolfgang Walter <wolfgang.walter@stwm.de> 
wrote:

> > Package: systemd
> > Version: 231-6
> > Severity: grave
> > 
> > Starting with version 231-6 the configuration of network interfaces stops
> > working reliably when rebooting a system. Downgrading to 231-5 fixes the
> > problem.
> > 
> > Symptoms: If a network interface is configured using
> > /etc/network/interfaces it seems that systemd now sometimes removes the
> > configured ip4 and/or ipv6 addresses in the boot process. It also seems
> > to remove routes of network interfaces configured manually or with
> > /etc/network/interfaces if the link state changes.
> > 
> > This seems not only be the case with interfaces configured via
> > /etc/network/ interfaces but with any interface one creates and assigns
> > ip addresses manually.
> > 
> > I tested this with a script:
> > 
> > #!/bin/sh
> > if [ "$1" = start ]; then
> > ip link del TEST >/dev/null 2>&1 || true
> > ip link add name TEST type dummy
> > ip -b - <<"EOF"
> > link set TEST up
> > addr add 10.10.10.10/32 dev TEST nodad
> > addr add 2a01:1:1:1::1/128 dev TEST nodad
> > addr add 2a01:1:1:1::2/128 dev TEST nodad
> > addr add 2a01:1:1:1::3/128 dev TEST nodad
> > addr add 2a01:1:1:1::4/128 dev TEST nodad
> > addr add 2a01:1:1:1::5/128 dev TEST nodad
> > EOF
> > ip addr ls TEST
> > sleep 2
> > elif [ "$1" = stop ]; then
> > ip addr flush dev TEST
> > ip link del TEST
> > fi
> > 
> > which I start with as a systemd oneshot service with
> > 
> >         Before=systemd-networkd.service
> > 
> > I can see in the journal that TEST has all adresses assigned but with
> > 231-6 it looses them again (probably when systemd-networkd.service
> > starts). With 231-5 or earlier this in not the case.

> 
> It appears you are using systemd-networkd. Could you please attach
> your networkd configuration?

Yes, systemd-networkd ist active. But on most machines I only have *.link 
entries, usually one to name the device:

======================
[Match]
MACAddress=11:22:33:44:55:66

[Link]
Name=net
WakeOnLan=off
======================

Most of them are virtual machines.


On those machine where I also habe *.netdev and *.network entries this also 
happens. The one with the simpliest has only one *.network:

======================
[Match]
Name=net

[Network]
LinkLocalAddressing=ipv6
IPv6AcceptRouterAdvertisements=no
DHCP=no
Address=10.11.12.13/24
Gateway=10.11.12.1
Address=2001:1234:1::abc1
Address=2001:1234:1::abc2
Address=2001:1234:1::abc3
Address=2001:1234:1::abc4
NTP=2001:1234:1::123

[Route]
Gateway=fe80::1
PreferredSource=2001:1234:1::abc1
======================

This interface works fine. But other interfaces configured by 
/etc/network/interfaces or the manually created interface TEST loose there 
ipv4 and ipv6 addresses.

Please note, that I did not create a *.link entry for TEST on any of the 
machines. 


If I later restart these interfaces (with ifdown + ifup for 
/etc/network/interfaces, systemctl restart test-network-device.service for 
TEST) they keep their addresses.



> 
> Version 231-6 is built with iptables support, so that may be causing
> an interaction that was not visible before.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Message #22 received at 837759@bugs.debian.org (full text, mbox, reply):

From: Wolfgang Walter <wolfgang.walter@stwm.de>

To: Felipe Sateler <fsateler@debian.org>

Cc: 837759@bugs.debian.org

Subject: Re: Bug#837759: network configuration stops working reliably

Date: Wed, 14 Sep 2016 23:34:26 +0200

On Wednesday, 14 September 2016 10:00:28 CEST Felipe Sateler wrote:
> Control: tags -1 moreinfo
> 
> On 14 September 2016 at 06:59, Wolfgang Walter <wolfgang.walter@stwm.de> wrote:
> > Package: systemd
> > Version: 231-6
> > Severity: grave
> > 
> > Starting with version 231-6 the configuration of network interfaces stops
> > working reliably when rebooting a system. Downgrading to 231-5 fixes the
> > problem.
> > 
> > Symptoms: If a network interface is configured using
> > /etc/network/interfaces it seems that systemd now sometimes removes the
> > configured ip4 and/or ipv6 addresses in the boot process. It also seems
> > to remove routes of network interfaces configured manually or with
> > /etc/network/interfaces if the link state changes.
> > 
> > This seems not only be the case with interfaces configured via
> > /etc/network/ interfaces but with any interface one creates and assigns
> > ip addresses manually.
> > 
> > I tested this with a script:
> > 
> > #!/bin/sh
> > if [ "$1" = start ]; then
> > ip link del TEST >/dev/null 2>&1 || true
> > ip link add name TEST type dummy
> > ip -b - <<"EOF"
> > link set TEST up
> > addr add 10.10.10.10/32 dev TEST nodad
> > addr add 2a01:1:1:1::1/128 dev TEST nodad
> > addr add 2a01:1:1:1::2/128 dev TEST nodad
> > addr add 2a01:1:1:1::3/128 dev TEST nodad
> > addr add 2a01:1:1:1::4/128 dev TEST nodad
> > addr add 2a01:1:1:1::5/128 dev TEST nodad
> > EOF
> > ip addr ls TEST
> > sleep 2
> > elif [ "$1" = stop ]; then
> > ip addr flush dev TEST
> > ip link del TEST
> > fi
> > 
> > which I start with as a systemd oneshot service with
> > 
> >         Before=systemd-networkd.service
> > 
> > I can see in the journal that TEST has all adresses assigned but with
> > 231-6 it looses them again (probably when systemd-networkd.service
> > starts). With 231-5 or earlier this in not the case.
> 
> It appears you are using systemd-networkd. Could you please attach
> your networkd configuration?
> 
> Version 231-6 is built with iptables support, so that may be causing
> an interaction that was not visible before.

I think this is the problem:

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=debian/231-6&id=79e10aaee1cdd412bd42f13f26e558ba1cd2196b

I suppose is that the check for LINK_STATE_UNMANAGED may be racy. The interface may go down and up before LINK_STATE_UNMANAGED is set. Maybe the state is LINK_STATE_PENDING ?

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Message #27 received at 837759@bugs.debian.org (full text, mbox, reply):

From: Felipe Sateler <fsateler@debian.org>

To: Wolfgang Walter <wolfgang.walter@stwm.de>

Cc: 837759@bugs.debian.org

Subject: Re: Bug#837759: network configuration stops working reliably

Date: Thu, 15 Sep 2016 12:36:45 -0300

On 14 September 2016 at 18:34, Wolfgang Walter <wolfgang.walter@stwm.de> wrote:
> On Wednesday, 14 September 2016 10:00:28 CEST Felipe Sateler wrote:
>> Control: tags -1 moreinfo
>>
>> On 14 September 2016 at 06:59, Wolfgang Walter <wolfgang.walter@stwm.de> wrote:
>> > Package: systemd
>> > Version: 231-6
>> > Severity: grave
>> >
>> > Starting with version 231-6 the configuration of network interfaces stops
>> > working reliably when rebooting a system. Downgrading to 231-5 fixes the
>> > problem.
>> >
>> > Symptoms: If a network interface is configured using
>> > /etc/network/interfaces it seems that systemd now sometimes removes the
>> > configured ip4 and/or ipv6 addresses in the boot process. It also seems
>> > to remove routes of network interfaces configured manually or with
>> > /etc/network/interfaces if the link state changes.
>> >
>> > This seems not only be the case with interfaces configured via
>> > /etc/network/ interfaces but with any interface one creates and assigns
>> > ip addresses manually.
>> >
>> > I tested this with a script:
>> >
>> > #!/bin/sh
>> > if [ "$1" = start ]; then
>> > ip link del TEST >/dev/null 2>&1 || true
>> > ip link add name TEST type dummy
>> > ip -b - <<"EOF"
>> > link set TEST up
>> > addr add 10.10.10.10/32 dev TEST nodad
>> > addr add 2a01:1:1:1::1/128 dev TEST nodad
>> > addr add 2a01:1:1:1::2/128 dev TEST nodad
>> > addr add 2a01:1:1:1::3/128 dev TEST nodad
>> > addr add 2a01:1:1:1::4/128 dev TEST nodad
>> > addr add 2a01:1:1:1::5/128 dev TEST nodad
>> > EOF
>> > ip addr ls TEST
>> > sleep 2
>> > elif [ "$1" = stop ]; then
>> > ip addr flush dev TEST
>> > ip link del TEST
>> > fi
>> >
>> > which I start with as a systemd oneshot service with
>> >
>> >         Before=systemd-networkd.service
>> >
>> > I can see in the journal that TEST has all adresses assigned but with
>> > 231-6 it looses them again (probably when systemd-networkd.service
>> > starts). With 231-5 or earlier this in not the case.
>>
>> It appears you are using systemd-networkd. Could you please attach
>> your networkd configuration?
>>
>> Version 231-6 is built with iptables support, so that may be causing
>> an interaction that was not visible before.
>
> I think this is the problem:
>
> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=debian/231-6&id=79e10aaee1cdd412bd42f13f26e558ba1cd2196b
>
> I suppose is that the check for LINK_STATE_UNMANAGED may be racy.
> The interface may go down and up before LINK_STATE_UNMANAGED is set.
> Maybe the state is LINK_STATE_PENDING ?

Interesting. Did you test with that patch disabled? (sorry, I have not
had time to test).

-- 

Saludos,
Felipe Sateler

Message #32 received at 837759@bugs.debian.org (full text, mbox, reply):

From: Felipe Sateler <fsateler@debian.org>

To: Wolfgang Walter <wolfgang.walter@stwm.de>

Cc: 837759@bugs.debian.org

Subject: Re: Bug#837759: network configuration stops working reliably

Date: Sat, 17 Sep 2016 13:51:28 -0300

On 15 September 2016 at 12:36, Felipe Sateler <fsateler@debian.org> wrote:
> On 14 September 2016 at 18:34, Wolfgang Walter <wolfgang.walter@stwm.de> wrote:
>> On Wednesday, 14 September 2016 10:00:28 CEST Felipe Sateler wrote:
>>> Control: tags -1 moreinfo
>>>
>>> On 14 September 2016 at 06:59, Wolfgang Walter <wolfgang.walter@stwm.de> wrote:
>>> > Package: systemd
>>> > Version: 231-6
>>> > Severity: grave
>>> >
>>> > Starting with version 231-6 the configuration of network interfaces stops
>>> > working reliably when rebooting a system. Downgrading to 231-5 fixes the
>>> > problem.
>>> >
>>> > Symptoms: If a network interface is configured using
>>> > /etc/network/interfaces it seems that systemd now sometimes removes the
>>> > configured ip4 and/or ipv6 addresses in the boot process. It also seems
>>> > to remove routes of network interfaces configured manually or with
>>> > /etc/network/interfaces if the link state changes.
>>> >
>>> > This seems not only be the case with interfaces configured via
>>> > /etc/network/ interfaces but with any interface one creates and assigns
>>> > ip addresses manually.
>>> >
>>> > I tested this with a script:
>>> >
>>> > #!/bin/sh
>>> > if [ "$1" = start ]; then
>>> > ip link del TEST >/dev/null 2>&1 || true
>>> > ip link add name TEST type dummy
>>> > ip -b - <<"EOF"
>>> > link set TEST up
>>> > addr add 10.10.10.10/32 dev TEST nodad
>>> > addr add 2a01:1:1:1::1/128 dev TEST nodad
>>> > addr add 2a01:1:1:1::2/128 dev TEST nodad
>>> > addr add 2a01:1:1:1::3/128 dev TEST nodad
>>> > addr add 2a01:1:1:1::4/128 dev TEST nodad
>>> > addr add 2a01:1:1:1::5/128 dev TEST nodad
>>> > EOF
>>> > ip addr ls TEST
>>> > sleep 2
>>> > elif [ "$1" = stop ]; then
>>> > ip addr flush dev TEST
>>> > ip link del TEST
>>> > fi
>>> >
>>> > which I start with as a systemd oneshot service with
>>> >
>>> >         Before=systemd-networkd.service
>>> >
>>> > I can see in the journal that TEST has all adresses assigned but with
>>> > 231-6 it looses them again (probably when systemd-networkd.service
>>> > starts). With 231-5 or earlier this in not the case.
>>>
>>> It appears you are using systemd-networkd. Could you please attach
>>> your networkd configuration?
>>>
>>> Version 231-6 is built with iptables support, so that may be causing
>>> an interaction that was not visible before.
>>
>> I think this is the problem:
>>
>> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=debian/231-6&id=79e10aaee1cdd412bd42f13f26e558ba1cd2196b
>>
>> I suppose is that the check for LINK_STATE_UNMANAGED may be racy.
>> The interface may go down and up before LINK_STATE_UNMANAGED is set.
>> Maybe the state is LINK_STATE_PENDING ?
>
> Interesting. Did you test with that patch disabled? (sorry, I have not
> had time to test).

BTW, I have tested manually on my system during runtime and cannot
reproduce. If this is a race maybe my laptop while idle managed to
configure faster than networkd managed to react.

-- 

Saludos,
Felipe Sateler

Message #37 received at 837759@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Wolfgang Walter <wolfgang.walter@stwm.de>, 837759@bugs.debian.org

Cc: Felipe Sateler <fsateler@debian.org>

Subject: Re: Bug#837759: network configuration stops working reliably

Date: Mon, 19 Sep 2016 11:02:08 +0200

Hello Wolfgang,

Wolfgang Walter [2016-09-14 23:34 +0200]:
> > > I tested this with a script:

FTR, I tried this as welll, and I cannot reproduce the bug either.

Wolfgang Walter [2016-09-14 17:56 +0200]:
> Yes, systemd-networkd ist active. But on most machines I only have *.link
> entries, usually one to name the device:

*.link entries are handled by udev, not networkd. So if you can
reproduce this on a machine with only has files like

> ======================
> [Match]
> MACAddress=11:22:33:44:55:66
> 
> [Link]
> Name=net
> WakeOnLan=off
> ======================

then can you please "systemctl disable --now systemd-networkd" and
check if the problem still happens? I suppose not, but if so, this
tells us that this is being done through udev.

If networkd itself is really the culprit, can you please try the
following:

 * Keep it disabled, run your test.sh to set up the dummy interface,
   and run

     SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

  (as root). Does this now cause the addresses to be removed? This
  will run much later than test.sh, so this will tell us if this is a
  principal logic error or a race condition, i. e. only happens if
  networkd starts at the right time after test.sh.

 * Enable networkd again, and boot with "debug" in the kernel command
   line. Does this still reproduce the bug?

   If so, please attach the output of "journalctl -b".

   If not, just enable debugging for networkd with

   mkdir -p /etc/systemd/system/systemd-networkd.service.d/
   printf '[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug' > /etc/systemd/system/systemd-networkd.service.d/debug.conf

   and reboot. If you catch the bug, please attach "journalctl -b".

Thanks,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Message #42 received at 837759@bugs.debian.org (full text, mbox, reply):

From: Wolfgang Walter <wolfgang.walter@stwm.de>

To: Martin Pitt <mpitt@debian.org>

Cc: 837759@bugs.debian.org, Felipe Sateler <fsateler@debian.org>

Subject: Re: Bug#837759: network configuration stops working reliably

Date: Mon, 19 Sep 2016 12:30:33 +0200

Hello Martin,

On Monday, 19 September 2016 11:02:08 CEST Martin Pitt wrote:
> Hello Wolfgang,
> 
> Wolfgang Walter [2016-09-14 23:34 +0200]:
> > > > I tested this with a script:
> FTR, I tried this as welll, and I cannot reproduce the bug either.
> 
> Wolfgang Walter [2016-09-14 17:56 +0200]:
> > Yes, systemd-networkd ist active. But on most machines I only have *.link
> 
> > entries, usually one to name the device:
> *.link entries are handled by udev, not networkd. So if you can
> reproduce this on a machine with only has files like
> 
> > ======================
> > [Match]
> > MACAddress=11:22:33:44:55:66
> > 
> > [Link]
> > Name=net
> > WakeOnLan=off
> > ======================
> 
> then can you please "systemctl disable --now systemd-networkd" and
> check if the problem still happens? I suppose not, but if so, this
> tells us that this is being done through udev.

When I disable systemd-networkd the problem disappears.

The reason I think it is a race is because it depends on how many interfaces you set up, if you use systemd-networkd to setup some interfaces and the number of ip-addresses and things you do in /etc/network/interfaces.

For example on that simple machines where I only have *.link and don't use systemd-networkd: sometimes (maybe 2 out of 10) it works, but most of the time I loose some or all ip-adresses.

Here is the log (without) debugging: in this case the interface only kept the IPv6 addresses and lost its ipv4 address, all set up in /etc/network/interfaces.

Sep 19 11:33:25 maiskolben systemd[1]: Starting Raise network interfaces...
Sep 19 11:33:25 maiskolben systemd[1]: Starting Network Service...
Sep 19 11:33:26 maiskolben systemd-networkd[480]: Enumeration completed
Sep 19 11:33:26 maiskolben systemd-networkd[480]: net: Lost carrier
Sep 19 11:33:26 maiskolben systemd-networkd[480]: net: Gained carrier
Sep 19 11:33:26 maiskolben systemd[1]: Started Network Service.
Sep 19 11:33:27 maiskolben systemd-networkd[480]: net: Gained IPv6LL
Sep 19 11:33:27 maiskolben ifup[352]: Waiting for DAD... Done
Sep 19 11:33:27 maiskolben systemd[1]: Started Raise network interfaces.

But there is nothing special about ipv4-addresses. With more interfaces one may loose some or all of the ipv6 adresses, too.

I think the crucial point is that systemd-networkd may declares the interface "net" unamanaged AFTER "net: Lost carrier" so that all addresses confgured until that point are ripped off.

This " Lost carrier" is always there on startup, don't know if this is caused by udev when it detects the interface on startup.


Here is the log with systemd-networkd disabled:

Sep 19 11:37:20 maiskolben systemd[1]: Starting Raise network interfaces...
Sep 19 11:37:22 maiskolben ifup[400]: Waiting for DAD... Done
Sep 19 11:37:23 maiskolben systemd[1]: Started Raise network interfaces.


> 
> If networkd itself is really the culprit, can you please try the
> following:
> 
>  * Keep it disabled, run your test.sh to set up the dummy interface,
>    and run
> 
>      SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
> 
>   (as root). Does this now cause the addresses to be removed? This
>   will run much later than test.sh, so this will tell us if this is a
>   principal logic error or a race condition, i. e. only happens if
>   networkd starts at the right time after test.sh.

No, I don't loose any addresses then. But as you see there is no such "net: Lost carrier" or "TEST: Lost carrier" and so on.

SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
Found container virtualization none
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a
Got message type=method_return sender=org.freedesktop.DBus destination=:1.3 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch cookie=2 reply_cookie=0 error=n/a
Got message type=method_return sender=org.freedesktop.DBus destination=:1.3 object=n/a interface=n/a member=n/a cookie=3 reply_cookie=2 error=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RequestName cookie=3 reply_cookie=0 error=n/a
Got message type=method_return sender=org.freedesktop.DBus destination=:1.3 object=n/a interface=n/a member=n/a cookie=5 reply_cookie=3 error=n/a
Failed to open configuration file '/etc/systemd/networkd.conf': No such file or directory
timestamp of '/etc/systemd/network' changed
timestamp of '/lib/systemd/network' changed
TEST: Flags change: +UP +LOWER_UP +RUNNING +BROADCAST +NOARP
Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/network1/link/_34 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=4 reply_cookie=0 error=n/a
TEST: Link 4 added
TEST: udev initialized link
TEST: Saved original MTU: 1500
dummy0: Flags change: +BROADCAST +NOARP
dummy0: Link 3 added
dummy0: udev initialized link
dummy0: Saved original MTU: 1500
net: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST
Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=5 reply_cookie=0 error=n/a
net: Link 2 added
net: udev initialized link
net: Saved original MTU: 1500
lo: Flags change: +LOOPBACK +UP +LOWER_UP +RUNNING
Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/network1/link/_31 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=6 reply_cookie=0 error=n/a
lo: Link 1 added
lo: udev initialized link
lo: Saved original MTU: 0
TEST: Adding address: fe80::28c4:17ff:fe97:8db8/64 (valid forever)
Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/network1/link/_34 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7 reply_cookie=0 error=n/a
TEST: Gained IPv6LL
TEST: Adding address: 2a01:1:1:1::1/128 (valid forever)
Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/network1/link/_34 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=8 reply_cookie=0 error=n/a
TEST: Adding address: 2a01:1:1:1::2/128 (valid forever)
TEST: Adding address: 2a01:1:1:1::3/128 (valid forever)
TEST: Adding address: 2a01:1:1:1::4/128 (valid forever)
TEST: Adding address: 2a01:1:1:1::5/128 (valid forever)
net: Adding address: fe80::b06f:8519:f172:52ef/64 (valid forever)
Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=9 reply_cookie=0 error=n/a
net: Gained IPv6LL
net: Adding address:2a01:1:2:3::1/125 (valid forever)
Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=10 reply_cookie=0 error=n/a
lo: Adding address: ::1/128 (valid forever)
TEST: Adding address: 10.10.10.10/32 (valid forever)
net: Adding address: 10.251.17.66/29 (valid forever)
lo: Adding address: 127.0.0.1/8 (valid forever)
Enumeration completed
Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/network1 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=11 reply_cookie=0 error=n/a
TEST: Link state is up-to-date
Virtualization QEMU found in DMI (/sys/class/dmi/id/sys_vendor)
Found VM virtualization qemu
TEST: Unmanaged
Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/network1/link/_34 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=12 reply_cookie=0 error=n/a
dummy0: Link state is up-to-date
dummy0: Unmanaged
Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/network1/link/_33 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=13 reply_cookie=0 error=n/a
net: Link state is up-to-date
net: Unmanaged
Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=14 reply_cookie=0 error=n/a
lo: Link state is up-to-date
lo: Unmanaged
Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/network1/link/_31 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=15 reply_cookie=0 error=n/a
Got message type=signal sender=org.freedesktop.DBus destination=:1.3 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a
Got message type=signal sender=org.freedesktop.DBus destination=:1.3 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=4 reply_cookie=0 error=n/a


> 
>  * Enable networkd again, and boot with "debug" in the kernel command
>    line. Does this still reproduce the bug?

Will do that tonight.

> 
>    If so, please attach the output of "journalctl -b".
> 
>    If not, just enable debugging for networkd with
> 
>    mkdir -p /etc/systemd/system/systemd-networkd.service.d/
>    printf '[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug' >
> /etc/systemd/system/systemd-networkd.service.d/debug.conf
> 
>    and reboot. If you catch the bug, please attach "journalctl -b".
> 
> Thanks,
> 
> Martin


Regards
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Message #47 received at 837759@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Wolfgang Walter <wolfgang.walter@stwm.de>, 837759@bugs.debian.org

Subject: Re: Bug#837759: network configuration stops working reliably

Date: Mon, 19 Sep 2016 16:24:12 +0200

Control: severity -1 important
Contro: tag -1 unreproducible

In accordance with the severity definitions [1] I downgrade this to
"important". It does not completely break systemd, we don't enable
networkd by default, and it does not affect every installation (it's
not reproducible on our side yet).

Don't worry, I'm still eager to find out what's happening here; I'll
look at your logs as soon as possible.

Martin

[1] https://www.debian.org/Bugs/Developer#severities

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Message #54 received at 837759@bugs.debian.org (full text, mbox, reply):

From: Wolfgang Walter <wolfgang.walter@stwm.de>

To: Martin Pitt <mpitt@debian.org>

Cc: 837759@bugs.debian.org

Subject: Re: Bug#837759: network configuration stops working reliably

Date: Mon, 19 Sep 2016 21:45:59 +0200

[Message part 1 (text/plain, inline)]

Hello Martin,

On Monday, 19 September 2016 16:24:12 CEST Martin Pitt wrote:
> Control: severity -1 important
> Contro: tag -1 unreproducible
> 
> In accordance with the severity definitions [1] I downgrade this to
> "important". It does not completely break systemd, we don't enable
> networkd by default, and it does not affect every installation (it's
> not reproducible on our side yet).
> 
> Don't worry, I'm still eager to find out what's happening here; I'll
> look at your logs as soon as possible.
> 
> Martin
> 
> [1] https://www.debian.org/Bugs/Developer#severities

Ok, here as attachment is the log with debugging enabled for systemd-networkd.

In this boot net and TEST have lost all there ip-adresses. The logs shows that 
it is systemd-networkd which removes them.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

[journal_with_sn_enabled_with-debug.txt (text/plain, attachment)]

Message #59 received at 837759@bugs.debian.org (full text, mbox, reply):

From: Felipe Sateler <fsateler@debian.org>

To: Martin Pitt <mpitt@debian.org>, 837759@bugs.debian.org

Cc: Wolfgang Walter <wolfgang.walter@stwm.de>

Subject: Re: Bug#837759: network configuration stops working reliably

Date: Mon, 19 Sep 2016 20:39:16 -0300

Control: tags -1 - unreproducible

On 19 September 2016 at 11:24, Martin Pitt <mpitt@debian.org> wrote:
> Control: severity -1 important
> Contro: tag -1 unreproducible
>
> In accordance with the severity definitions [1] I downgrade this to
> "important". It does not completely break systemd, we don't enable
> networkd by default, and it does not affect every installation (it's
> not reproducible on our side yet).

I managed to reproduce. Interestingly, this appears to occur only
during boot, but not if networkd is restarted after the boot. To
reproduce I created a bootable debian raw image with mkosi, and
configured as follows:

0. Install $EDITOR
1. Enable networkd (and add a config for ens* with dhcp)
2. Install iproute2
3. Add the service as described in the first post (make sure to add
DefaultDependencies=no to the unit).

After a reboot, I could see that TEST has no addresses.

Use the following to boot the image:
qemu-system-x86_64 -m 512 -vga virtio -bios /usr/share/ovmf/OVMF.fd \
--enable-kvm -drive file=image.raw,format=raw

-- 

Saludos,
Felipe Sateler

Message #64 received at 837759@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Wolfgang Walter <wolfgang.walter@stwm.de>

Cc: 837759@bugs.debian.org

Subject: Re: Bug#837759: network configuration stops working reliably

Date: Tue, 20 Sep 2016 11:07:52 +0200

[Message part 1 (text/plain, inline)]

Control: tag -1 confirmed upstream pending -moreinfo
Control: forwarded -1 https://github.com/systemd/systemd/issues/4186

Hello Wolfgang,

thanks for the further information. I can reproduce the problem now
and forwarded it upstream.

I dropped the patches from current packaging git, so -7 will fix this
again.

Thanks!

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[signature.asc (application/pgp-signature, inline)]

Message #75 received at 837759-close@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: 837759-close@bugs.debian.org

Subject: Bug#837759: fixed in systemd 231-7

Date: Tue, 20 Sep 2016 16:45:46 +0000

Source: systemd
Source-Version: 231-7

We believe that the bug you reported is fixed in the latest version of
systemd, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 837759@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Martin Pitt <mpitt@debian.org> (supplier of updated systemd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 20 Sep 2016 15:03:06 +0200
Source: systemd
Binary: systemd systemd-sysv systemd-container systemd-journal-remote systemd-coredump libpam-systemd libnss-myhostname libnss-mymachines libnss-resolve libsystemd0 libsystemd-dev udev libudev1 libudev-dev udev-udeb libudev1-udeb
Architecture: source amd64
Version: 231-7
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>
Changed-By: Martin Pitt <mpitt@debian.org>
Description:
 libnss-myhostname - nss module providing fallback resolution for the current hostname
 libnss-mymachines - nss module to resolve hostnames for local container instances
 libnss-resolve - nss module to resolve names via systemd-resolved
 libpam-systemd - system and service manager - PAM module
 libsystemd-dev - systemd utility library - development files
 libsystemd0 - systemd utility library
 libudev-dev - libudev development files
 libudev1   - libudev shared library
 libudev1-udeb - libudev shared library (udeb)
 systemd    - system and service manager
 systemd-container - systemd container/nspawn tools
 systemd-coredump - tools for storing and retrieving coredumps
 systemd-journal-remote - tools for sending and receiving remote journal logs
 systemd-sysv - system and service manager - SysV links
 udev       - /dev/ and hotplug management daemon
 udev-udeb  - /dev/ and hotplug management daemon (udeb)
Closes: 788050 837759
Changes:
 systemd (231-7) unstable; urgency=medium
 .
   [ Michael Biebl ]
   * fsckd: Do not exit on idle timeout if there are still clients connected
     (Closes: #788050, LP: #1547844)
 .
   [ Martin Pitt ]
   * 73-usb-net-by-mac.rules: Split kernel command line import line.
     Reportedly this makes the rule actually work on some platforms. Thanks Alp
     Toker! (LP: #1593379)
   * debian/tests/boot-smoke: Only run 5 iterations
   * systemd.postinst: Drop obsolete setcap call for systemd-detect-virt.
     Drop corresponding libcap2-bin dependency.
   * debian/tests/systemd-fsckd: Robustify check for "unit was running"
     (LP: #1624406)
   * debian/extra/set-cpufreq: Use powersave with intel_pstate.
     This is what we did on xenial, and apparently powersave is still actually
     better than performance. Thanks to Doug Smythies for the measurements!
     (LP: #1579278)
   * Ubuntu: Move ondemand.service from static to runtime enablement.
     This makes it easier to keep performance, by disabling ondemand.service.
     Side issue in LP: #1579278
   * Revert "networkd: remove route if carrier is lost"
     This causes networkd to drop addresses from unmanaged interfaces in some
     cases. (Closes: #837759)
   * debian/tests/storage: Avoid stderr output of stopping systemd-cryptsetup@.service
   * libnss-*.prerm: Remove possible [key=value] options from NSS modules as well.
     (LP: #1625584)
Checksums-Sha1:
 adba3c8dbe82a7416dbd773233f07d2acfb5d13c 4443 systemd_231-7.dsc
 ae40eee5c14e2ec3f205ec0c90acae0ace0e020c 140600 systemd_231-7.debian.tar.xz
 c5a3d37ae2d98d28b848a96397b58d83e562044d 87248 libnss-myhostname-dbgsym_231-7_amd64.deb
 b56d3515090dbf94d189596982bd055462819070 94738 libnss-myhostname_231-7_amd64.deb
 fc6b241c19210bc30ac798589e9a539124c78c4b 430976 libnss-mymachines-dbgsym_231-7_amd64.deb
 a21e9c6c0dc4c6e54d84eb5238ac8b27421009ad 176006 libnss-mymachines_231-7_amd64.deb
 6f2273fe465e8ca6e1da40af647afe85ce5ccdf7 425658 libnss-resolve-dbgsym_231-7_amd64.deb
 e5fd4b7e9f4d110cec794e02bf3b732b42bd4ee7 175394 libnss-resolve_231-7_amd64.deb
 8325aa505a3ef3b29c1da0513363f6ac0e269962 419136 libpam-systemd-dbgsym_231-7_amd64.deb
 21c1f5c5e01e8c967339588c22d6c2c0134e8221 176930 libpam-systemd_231-7_amd64.deb
 59e49762e22c99cc34d3d0d53701e0f2879d36fe 224858 libsystemd-dev_231-7_amd64.deb
 41f1d7cc725c21ab716bea16c99f02ba8640bcbe 659234 libsystemd0-dbgsym_231-7_amd64.deb
 887c46a76e42d88a8282ccc5facf3fa36999fd93 268376 libsystemd0_231-7_amd64.deb
 4ab145a79aa881a188420dd135274e9e4b611e97 510316 libudev-dev-dbgsym_231-7_amd64.deb
 2d8aa6acb6d8e8330ff684739ca4cffa493b2130 249578 libudev-dev_231-7_amd64.deb
 dd5463dd7d92ab8566cb3dc067885bf02d18824b 157186 libudev1-dbgsym_231-7_amd64.deb
 8d4c5dd87c948d892bcafdd47ce67dfcc8235b4d 48324 libudev1-udeb_231-7_amd64.udeb
 725ed901e97f65de8254dc5a5ddcd1a8cff8b5fb 114144 libudev1_231-7_amd64.deb
 d69b3a14f34673029c281ce6cf797b545b7aca81 471678 systemd-container-dbgsym_231-7_amd64.deb
 7d28f8a9a600e8ee88ee5ea91e93f08523cea4f6 274506 systemd-container_231-7_amd64.deb
 bb12899fb06f2cd09e644c4514b79ce8289f5878 66738 systemd-coredump-dbgsym_231-7_amd64.deb
 2447e049ad735d9feb4a7d5ad6cd46425981f3e8 98128 systemd-coredump_231-7_amd64.deb
 aef9136580945eed351843942b2615dad5be2c7b 5758618 systemd-dbgsym_231-7_amd64.deb
 bf92863701e64eb6b357362cf9e10cbbd7d0659c 110038 systemd-journal-remote-dbgsym_231-7_amd64.deb
 f200bcafb6f89f682ebec8a57192f1a1f2927ecc 117402 systemd-journal-remote_231-7_amd64.deb
 b5fe55acbcaabc16af7f814cadbefecf2337bbac 70948 systemd-sysv_231-7_amd64.deb
 01bd5f0d961cc9e32e28f3e23601acdc8846fa66 2364264 systemd_231-7_amd64.deb
 745059ddfd32f6b76934e2082bc566c931236f18 1311886 udev-dbgsym_231-7_amd64.deb
 1d39bb6caff2dda1797e663f97e6a54a647919b1 272588 udev-udeb_231-7_amd64.udeb
 609bb9bdfa95973df8f3763230110deccd78eb0b 1079270 udev_231-7_amd64.deb
Checksums-Sha256:
 07e3648b6505a9d9cbcabf7565d1240d72f8de8eb407b8def2e5976782f509b1 4443 systemd_231-7.dsc
 c540c392ac83bc6378490b5441d766a2b46aa7e27d04fffe7a77a8d5d1364bb4 140600 systemd_231-7.debian.tar.xz
 52b26777210cf26f3b6579bf227c97d06cc99fadad894d555187ed2a9b9ebc65 87248 libnss-myhostname-dbgsym_231-7_amd64.deb
 486e310dc4eb020b46519dab1cf5dabe4a14e551cf88412de3c22dd53a49e13e 94738 libnss-myhostname_231-7_amd64.deb
 c0d912e2eb25da4a8bf5c0e998eb726c768473863374794ce1eb006b768fe16c 430976 libnss-mymachines-dbgsym_231-7_amd64.deb
 086b18e53977e0f98d6cac0a1d761003c2b1d8cf87d550892e4f7c4b3f2bd693 176006 libnss-mymachines_231-7_amd64.deb
 6a3d34fe4cb3a730a5f836482700d60ec82e6c75de107901a10c2e09eff1d739 425658 libnss-resolve-dbgsym_231-7_amd64.deb
 1f2139cfa7bddfd0365dfc29fb034a15bd3ee38c41a24244a23aba78d878447e 175394 libnss-resolve_231-7_amd64.deb
 48c7f3af7f48d65255f3d97eb4b685dc39426d2ec5bb621883840d34d0cf8c62 419136 libpam-systemd-dbgsym_231-7_amd64.deb
 a3c07868fd8d44e90de0a6c6b79058011c6f27e406259f681708871951da726f 176930 libpam-systemd_231-7_amd64.deb
 b664bfe4c5edc5bc8c72ee6818d363acec237deb61e7c888e6561b2721b6c2d2 224858 libsystemd-dev_231-7_amd64.deb
 15c4261c6ddadc430489f03eab464ced5374d66e8a09de72514bc4635d90bd53 659234 libsystemd0-dbgsym_231-7_amd64.deb
 9ad84f611778730ddb9072640b1514a6571732dce12b9c778f54661293d2ed07 268376 libsystemd0_231-7_amd64.deb
 95aff5ce5a621fc18aeb728a21bd2f8c926c29981911b8d1ac149a7e78dae867 510316 libudev-dev-dbgsym_231-7_amd64.deb
 659ef824f1611188deaeb19ce804557f5340253d6512efe02a0c9d92e549a44c 249578 libudev-dev_231-7_amd64.deb
 a3d9677173f61f32410c5693af167ab7d88a6a0db253f8cfac57c30125e1e0b9 157186 libudev1-dbgsym_231-7_amd64.deb
 7839e218686be53fdc63a177119c1c986ee6563c5da2f9d5e3df8f7cf1ba29b5 48324 libudev1-udeb_231-7_amd64.udeb
 8ddfd105f96632de8e76600a3ec897acb743cdd76ef5577805e56882bf1588ac 114144 libudev1_231-7_amd64.deb
 412db6cea9bbf01a915d28b4746950c98eb3e045cd452b5af3df3c368bac64f2 471678 systemd-container-dbgsym_231-7_amd64.deb
 e670b491cc7288fa0ddd303594d156d63ee584606226ab238bc3be0cd00a5d29 274506 systemd-container_231-7_amd64.deb
 883d087151eebd367691ae361dc97a59c8b9f03711c4d3a657764af8b2b1cebb 66738 systemd-coredump-dbgsym_231-7_amd64.deb
 eab671ac8039df8aa800db7a0687d5e0f470e68b22e4ab52192aaa1a129e6a60 98128 systemd-coredump_231-7_amd64.deb
 dd4f339558d11801c37ffd8390cb694ace7c5c618b0c044d5616a913b7ae4762 5758618 systemd-dbgsym_231-7_amd64.deb
 4e99e3a70ac687b410afb49e737c0cf92d1a7710d5fc04b4a536d091d5da5d88 110038 systemd-journal-remote-dbgsym_231-7_amd64.deb
 68b43e13f674220ee87484d47c6d95cff567b4f7d79eb17ee7b446849a01cebf 117402 systemd-journal-remote_231-7_amd64.deb
 1c800b4e353e09a5fdedb36b965d0fb38d768bb19034d5b56a55a5f581ab8da8 70948 systemd-sysv_231-7_amd64.deb
 91e8fbf83639f7ea60162e7b99980b21b311dadf1823c07ea762bfc9204227d6 2364264 systemd_231-7_amd64.deb
 da06de39e446344d0e12a9e684a36f4c771ab808a4c4732b5675c7b9575148a1 1311886 udev-dbgsym_231-7_amd64.deb
 f1ae3b0d9c0eee0c2ec23d4725a3f8cd7515fb3aef8b6da4b93de8873ba988d0 272588 udev-udeb_231-7_amd64.udeb
 bf6c12fc46c34cd1ab735d69dbd7f57a180d96a2d06843763ff95a1a3050954b 1079270 udev_231-7_amd64.deb
Files:
 38deb05af6ba19ff48c7b004305891c1 4443 admin optional systemd_231-7.dsc
 997e4e1968609c3f6bbdee48bb9068f0 140600 admin optional systemd_231-7.debian.tar.xz
 a16ebad89a4b6996bba4673c0a7b1cc3 87248 debug extra libnss-myhostname-dbgsym_231-7_amd64.deb
 f727457c5c4de1e69079b7d620074ad2 94738 admin extra libnss-myhostname_231-7_amd64.deb
 90af84c37e94e9a38e062a9f43ece236 430976 debug extra libnss-mymachines-dbgsym_231-7_amd64.deb
 9c0e7d3b4ac1d2278b3d4ef34a4d1422 176006 admin extra libnss-mymachines_231-7_amd64.deb
 2efb14cbb59d5764b425b4cc768675ce 425658 debug extra libnss-resolve-dbgsym_231-7_amd64.deb
 5c83296a329274e8b8e5045a501fc5f1 175394 admin extra libnss-resolve_231-7_amd64.deb
 bb6312cbce2024070c92e21851f94bcb 419136 debug extra libpam-systemd-dbgsym_231-7_amd64.deb
 2cae0ba70fdb92943e4f54ba5c65b243 176930 admin optional libpam-systemd_231-7_amd64.deb
 f874d4535e5e09ffa72ba686c2616d2c 224858 libdevel optional libsystemd-dev_231-7_amd64.deb
 2c4cd09d7fb9b078fe1b18c8b17d4b42 659234 debug extra libsystemd0-dbgsym_231-7_amd64.deb
 7eab1e3b88ade336f5abb1811bb3c0e3 268376 libs optional libsystemd0_231-7_amd64.deb
 fac0fa5888bdd3e5968dc2ead6a7b717 510316 debug extra libudev-dev-dbgsym_231-7_amd64.deb
 40c0478aa5b60acbe3f4610ebdf11d4d 249578 libdevel optional libudev-dev_231-7_amd64.deb
 b19ea3b834fc7ff73f78f808baa5bbbb 157186 debug extra libudev1-dbgsym_231-7_amd64.deb
 2dcefa8d6fd511cba7ac42e82a8d75c3 48324 debian-installer optional libudev1-udeb_231-7_amd64.udeb
 8c23e62fb6ae0e0b2290e74ce7425f19 114144 libs important libudev1_231-7_amd64.deb
 319ebe48c8fbdebb402315abd1bc7e57 471678 debug extra systemd-container-dbgsym_231-7_amd64.deb
 8ca16b0df6d103237923dd3a7a8718a1 274506 admin optional systemd-container_231-7_amd64.deb
 e496eab0604aa285857fb5e092c82f14 66738 debug extra systemd-coredump-dbgsym_231-7_amd64.deb
 35152b0fed614a640361574f1865c95e 98128 admin optional systemd-coredump_231-7_amd64.deb
 e3ccadf1ec7059e7eb28dedbe17ec830 5758618 debug extra systemd-dbgsym_231-7_amd64.deb
 5946b6d9442f60f34ad1749525c54505 110038 debug extra systemd-journal-remote-dbgsym_231-7_amd64.deb
 0f11fbbf921f161538b459f1331effdd 117402 admin optional systemd-journal-remote_231-7_amd64.deb
 a4d574f3cc369d004ec786eff50194c9 70948 admin important systemd-sysv_231-7_amd64.deb
 0a978faa747a9913c20c94716bf4236d 2364264 admin important systemd_231-7_amd64.deb
 f6f2a89262b71ed7b6ba51feeb86f279 1311886 debug extra udev-dbgsym_231-7_amd64.deb
 fc05e0b97bd09df8b9714a8f31e4898d 272588 debian-installer optional udev-udeb_231-7_amd64.udeb
 0ab84fe67ff84d5fa4a84bc5ece405fb 1079270 admin important udev_231-7_amd64.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJX4UPxAAoJENFO8V2v4RNH6skQAKoNs/kSmoJdiKIJ1KrgUFyX
2JoIy6kM4Z5DK71tGQC9VMdTVYWEYHbOzAglHSFbaRJ0tivLmqRpaIl3E3c8XbAV
qoR4GL9rD3txQ7M/d0GPC1v6J9IW3wssAND3wlyJLTKdjIzLJv6OVrk951ILWU9+
EZTUjfy4qZ9LzcaAsr3rkegyxXRc13V8NJeknuC9BLMvnaq2ErMV2X3oIw1ydmb5
hfwwkRnSRJufR+prmI4nn47f1IAwnNYIURC1sfs0YhKYVnkCiy4azgG3u9BmC/yH
3ZuZeZ+MH7JyXwH2zPLM3zw5Prj3yFEkq9W9KpdMhNU/ALsSzz1/UxNZGflcsjSB
jA+/P7yM7eHVkFEeAOaSvn92vEwPiSx3tgXmhJagyPzETlTixdmm8VHPA4bFkEux
utR+9kigU70XaJ5jt3IaFAea6Pmrgbw5JwopzbxU0/V7wNjRiKaDwZadVwekVml+
ACCFBRj8ZugPMwIpp62zJMmS3BU0UGgQiJaDW5eVr9hJefNIV0vNMhNYE+xnWPEQ
sMZI3CA+BeC22ntqVUfx1yGi4WnlZPLkCFkWHkBUzuwvSDveuQvpC03apc/o4dCP
ccSlcBku5Nfq8leELOfn2ZcZWvJhzAMPxKGagyyi99TIQqYjcGy/571fgkyXJaay
BoEHudAnfEGkmcZO9t8D
=d8aG
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.