Debian Bug report logs - #801389
systemd: postinst may not have run correctly on upgrades (from jessie) due bug in dpkg

Display info messages

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

From: Yuri D'Elia <wavexx@thregr.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Disabling timedatectl/NTP across package upgrades

Date: Fri, 09 Oct 2015 15:11:45 +0200

Package: systemd
Version: 227-1
Severity: normal

I'm trying to disable time syncronization, but I've found two issues happening
during upgrades:

- Disabling systemd-timesyncd.service is not enough.
  systemd-timesyncd.service gets automatically re-enabled on upgrade.

  Is this intended? I would argue that a disabled service should stay disabled
  on upgrades.

- I tried using timedatectl instead, even though I see no reason to use the
  timesyncd service at all.

  But "timedatectl set-ntp false" also got reset on package upgrades.
  The manual page of timedatectl gives no information on where this setting is
  actually stored.

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

From: Martin Pitt <mpitt@debian.org>

To: Yuri D'Elia <wavexx@thregr.org>, 801389@bugs.debian.org

Subject: Re: Bug#801389: Disabling timedatectl/NTP across package upgrades

Date: Fri, 9 Oct 2015 15:23:25 +0200

Control: tag -1 moreinfo

Hello Yuri,

Yuri D'Elia [2015-10-09 15:11 +0200]:
> Version: 227-1
> 
> I'm trying to disable time syncronization, but I've found two issues happening
> during upgrades:
> 
> - Disabling systemd-timesyncd.service is not enough.
>   systemd-timesyncd.service gets automatically re-enabled on upgrade.
> 
>   Is this intended? I would argue that a disabled service should stay disabled
>   on upgrades.

No, this isn't intended. The postinst does

   if dpkg --compare-versions "$2" lt "218-11~"; then
       systemctl enable systemd-timesyncd.service || true
   fi

i. e. it only gets enabled once on a fresh install, or when you
upgrade from jessie. But not e. g. from 226-1 to 227-1. Which version
did you upgrade from?

I can't reproduce this by upgrading from 226 to 227.

> - I tried using timedatectl instead, even though I see no reason to use the
>   timesyncd service at all.
> 
>   But "timedatectl set-ntp false" also got reset on package upgrades.
>   The manual page of timedatectl gives no information on where this setting is
>   actually stored.

It kind of does: "This command is hence mostly equivalent to:
systemctl enable --now systemd-timesyncd.service and systemctl disable
--now systemd-timesyncd.service, but is protected by a different
access policy." -- I. e. it is stored as the symlink
/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service .

So this indeed is just a variant of what you see above with disabling
with systemctl.

Thanks,

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

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

From: Michael Biebl <biebl@debian.org>

To: Yuri D'Elia <wavexx@thregr.org>, 801389@bugs.debian.org

Subject: Re: Bug#801389: Disabling timedatectl/NTP across package upgrades

Date: Fri, 9 Oct 2015 15:24:50 +0200

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

Control: tags -1 moreinfo unreproducible

Am 09.10.2015 um 15:11 schrieb Yuri D'Elia:
> Package: systemd
> Version: 227-1
> Severity: normal
> 
> I'm trying to disable time syncronization, but I've found two issues happening
> during upgrades:
> 
> - Disabling systemd-timesyncd.service is not enough.
>   systemd-timesyncd.service gets automatically re-enabled on upgrade.
> 
>   Is this intended? I would argue that a disabled service should stay disabled
>   on upgrades.

No, this is not intended.
I can not reproduce the problem:

> root@pluto:/# systemctl is-enabled systemd-timesyncd
> enabled
> root@pluto:/# systemctl disable systemd-timesyncd
> Removed symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service.
> root@pluto:/# systemctl is-enabled systemd-timesyncd
> disabled
> root@pluto:/# apt-get install --reinstall systemd
> Reading package lists... Done
> Building dependency tree       
> Reading state information... Done
> 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
> Need to get 0 B/3500 kB of archives.
> After this operation, 0 B of additional disk space will be used.
> debconf: delaying package configuration, since apt-utils is not installed
> (Reading database ... 12074 files and directories currently installed.)
> Preparing to unpack .../systemd_227-1_amd64.deb ...
> Unpacking systemd (227-1) over (227-1) ...
> Setting up systemd (227-1) ...
> addgroup: The group `systemd-journal' already exists as a system group. Exiting.
> root@pluto:/# systemctl is-enabled systemd-timesyncd
> disabled

What commands did you use exactly to disable the service?

Do you have a /run/systemd/was-enabled file?
Could you attach that, please.

Michael


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

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

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

From: Yuri D'Elia <wavexx@thregr.org>

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

Subject: Re: Bug#801389: Disabling timedatectl/NTP across package upgrades

Date: Fri, 9 Oct 2015 15:56:03 +0200

On 09/10/15 15:23, Martin Pitt wrote:
> i. e. it only gets enabled once on a fresh install, or when you
> upgrade from jessie. But not e. g. from 226-1 to 227-1. Which version
> did you upgrade from?

I'm following unstable on a KVM instance where I explicitly do not want
time sync, so I'm unsure on which version this got re-enabled.

I noticed this issue some months ago, where I disabled the service on
two occasions, then tried using timedatectl, and noticed today that the
service got re-enabled again just before reporting the issue.

I'm sure the service was disabled correctly on all occasions, but it got
re-enabled by was I assumed to be package upgrades.

Was the systemctl check always into place, or was it added just
recently? (just so I can avoid scavenging through log files).

> It kind of does: "This command is hence mostly equivalent to:
> systemctl enable --now systemd-timesyncd.service and systemctl disable
> --now systemd-timesyncd.service, but is protected by a different
> access policy." -- I. e. it is stored as the symlink
> /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service .
> 
> So this indeed is just a variant of what you see above with disabling
> with systemctl.

Which method is recommended then? Both should survive through package
updates I guess.

Also, responding in-line to Michael:

> root@pluto:/# systemctl is-enabled systemd-timesyncd
> disabled
>
> What commands did you use exactly to disable the service?

Simply:

systemctl disable --now systemd-timesyncd

and

timedatectl set-ntp false

> Do you have a /run/systemd/was-enabled file?
> Could you attach that, please.

The system got rebooted a couple of times.
was-enabled is missing right now.

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

From: Michael Biebl <biebl@debian.org>

To: Yuri D'Elia <wavexx@thregr.org>, 801389@bugs.debian.org

Subject: Re: Bug#801389: Disabling timedatectl/NTP across package upgrades

Date: Fri, 9 Oct 2015 16:08:53 +0200

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

Am 09.10.2015 um 15:56 schrieb Yuri D'Elia:
> On 09/10/15 15:23, Martin Pitt wrote:
>> i. e. it only gets enabled once on a fresh install, or when you
>> upgrade from jessie. But not e. g. from 226-1 to 227-1. Which version
>> did you upgrade from?
> 
> I'm following unstable on a KVM instance where I explicitly do not want
> time sync, so I'm unsure on which version this got re-enabled.
> 
> I noticed this issue some months ago, where I disabled the service on
> two occasions, then tried using timedatectl, and noticed today that the
> service got re-enabled again just before reporting the issue.

You are saying that the service was disabled before the 227-1 update and
re-enabled after the 227-1 update?
How do you know it was disabled before the update?

> I'm sure the service was disabled correctly on all occasions, but it got
> re-enabled by was I assumed to be package upgrades.
> 
> Was the systemctl check always into place, or was it added just
> recently? (just so I can avoid scavenging through log files).

Yes, for systemd-timesyncd it was always there.
We started enabled timesyncd by default in 219-1 and the code to not
re-enable services on upgrades was added way before in 214-1

Please double check if it's really the systemd upgrade which re-enables
the service.

If you do the steps I posted, is the service re-enabled for you?

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

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

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

From: Yuri D'Elia <wavexx@thregr.org>

To: Michael Biebl <biebl@debian.org>, 801389@bugs.debian.org

Subject: Re: Bug#801389: Disabling timedatectl/NTP across package upgrades

Date: Fri, 9 Oct 2015 16:57:05 +0200

On 09/10/15 16:08, Michael Biebl wrote:
>> I'm following unstable on a KVM instance where I explicitly do not want
>> time sync, so I'm unsure on which version this got re-enabled.
>>
>> I noticed this issue some months ago, where I disabled the service on
>> two occasions, then tried using timedatectl, and noticed today that the
>> service got re-enabled again just before reporting the issue.
> 
> You are saying that the service was disabled before the 227-1 update and
> re-enabled after the 227-1 update?
> How do you know it was disabled before the update?

I know it was disabled only before the 226-1 upgrade. I cannot be sure
if that's the package upgrade process that enabled the service again though.

> Yes, for systemd-timesyncd it was always there.
> We started enabled timesyncd by default in 219-1 and the code to not
> re-enable services on upgrades was added way before in 214-1
> 
> Please double check if it's really the systemd upgrade which re-enables
> the service.

I'll have a closer look at the logs and see if I can find what enabled
it again.

> If you do the steps I posted, is the service re-enabled for you?

No it's not, as expected.

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

From: Yuri D'Elia <wavexx@thregr.org>

To: Michael Biebl <biebl@debian.org>, 801389@bugs.debian.org

Subject: Re: Bug#801389: Disabling timedatectl/NTP across package upgrades

Date: Fri, 9 Oct 2015 18:27:02 +0200

On 09/10/15 16:57, Yuri D'Elia wrote:
>> If you do the steps I posted, is the service re-enabled for you?
> 
> No it's not, as expected.

Ok, just updated from 227-1 to 227-2 using aptitude:

Performing actions...
Preconfiguring packages ...
(Reading database ... 35322 files and directories currently installed.)
Preparing to unpack .../archives/udev_227-2_i386.deb ...
Unpacking udev (227-2) over (227-1) ...
Preparing to unpack .../libudev1_227-2_i386.deb ...
Unpacking libudev1:i386 (227-2) over (227-1) ...
<snip>
Processing triggers for man-db (2.7.4-1) ...
Processing triggers for libc-bin (2.19-22) ...
Setting up libsystemd0:i386 (227-2) ...
Setting up udev (227-2) ...
addgroup: The group `input' already exists as a system group. Exiting.
Setting up systemd (227-2) ...
Created symlink from
/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service to
/lib/systemd/system/systemd-timesyncd.service.
addgroup: The group `systemd-journal' already exists as a system group.
Exiting.
Setting up systemd-sysv (227-2) ...
Setting up libpam-systemd:i386 (227-2) ...
Processing triggers for dbus (1.10.0-3) ...
Processing triggers for libc-bin (2.19-22) ...
Press Return to continue.

# systemctl is-enabled systemd-timesyncd.service
enabled

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

From: Michael Biebl <biebl@debian.org>

To: Yuri D'Elia <wavexx@thregr.org>, 801389@bugs.debian.org

Subject: Re: Bug#801389: Disabling timedatectl/NTP across package upgrades

Date: Fri, 9 Oct 2015 19:15:27 +0200

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

Am 09.10.2015 um 18:27 schrieb Yuri D'Elia:
> On 09/10/15 16:57, Yuri D'Elia wrote:
>>> If you do the steps I posted, is the service re-enabled for you?
>>
>> No it's not, as expected.
> 
> Ok, just updated from 227-1 to 227-2 using aptitude:
> 
> Performing actions...
> Preconfiguring packages ...
> (Reading database ... 35322 files and directories currently installed.)
> Preparing to unpack .../archives/udev_227-2_i386.deb ...
> Unpacking udev (227-2) over (227-1) ...
> Preparing to unpack .../libudev1_227-2_i386.deb ...
> Unpacking libudev1:i386 (227-2) over (227-1) ...
> <snip>
> Processing triggers for man-db (2.7.4-1) ...
> Processing triggers for libc-bin (2.19-22) ...
> Setting up libsystemd0:i386 (227-2) ...
> Setting up udev (227-2) ...
> addgroup: The group `input' already exists as a system group. Exiting.
> Setting up systemd (227-2) ...
> Created symlink from
> /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service to
> /lib/systemd/system/systemd-timesyncd.service.
> addgroup: The group `systemd-journal' already exists as a system group.
> Exiting.
> Setting up systemd-sysv (227-2) ...
> Setting up libpam-systemd:i386 (227-2) ...
> Processing triggers for dbus (1.10.0-3) ...
> Processing triggers for libc-bin (2.19-22) ...
> Press Return to continue.
> 
> # systemctl is-enabled systemd-timesyncd.service
> enabled
> 

Can you provide the full log?

Also, the contents of /run/systemd/was-enabled would be helpful.

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

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

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

From: Yuri D'Elia <wavexx@thregr.org>

To: Michael Biebl <biebl@debian.org>, 801389@bugs.debian.org

Subject: Re: Bug#801389: Disabling timedatectl/NTP across package upgrades

Date: Fri, 9 Oct 2015 19:25:21 +0200

On 09/10/15 19:15, Michael Biebl wrote:
>> # systemctl is-enabled systemd-timesyncd.service
>> enabled
> 
> Can you provide the full log?

I closed the terminal already [heh], but there was nothing interesting
in replacing the other systemd packages. I pasted the entire contents of
the post-install triggers. The only useful message is the creation of
the symlink related to systemd-timesyncd, which I do remember noticing
in the past.

The contents of dpkg.log look uninteresting as they do not contain much
detail, same for syslog.

Simply re-installing 227-2 does not re-enable the service.

I could try to downgrade to 227-1 and upgrade again.
Any log/detail you want me to explicitly log?

> Also, the contents of /run/systemd/was-enabled would be helpful.

# cat /run/systemd/was-enabled
getty@tty1.service
remote-fs.target
tmp.mount

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

From: Michael Biebl <biebl@debian.org>

To: Yuri D'Elia <wavexx@thregr.org>, 801389@bugs.debian.org

Subject: Re: Bug#801389: Disabling timedatectl/NTP across package upgrades

Date: Fri, 9 Oct 2015 19:33:12 +0200

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

Am 09.10.2015 um 19:25 schrieb Yuri D'Elia:
> On 09/10/15 19:15, Michael Biebl wrote:
>>> # systemctl is-enabled systemd-timesyncd.service
>>> enabled
>>
>> Can you provide the full log?
> 
> I closed the terminal already [heh], but there was nothing interesting
> in replacing the other systemd packages. I pasted the entire contents of
> the post-install triggers. The only useful message is the creation of
> the symlink related to systemd-timesyncd, which I do remember noticing
> in the past.
> 
> The contents of dpkg.log look uninteresting as they do not contain much
> detail, same for syslog.
> 
> Simply re-installing 227-2 does not re-enable the service.
> 
> I could try to downgrade to 227-1 and upgrade again.
> Any log/detail you want me to explicitly log?
> 

The complete log dpkg log from the upgrade.
Also make sure to disable the service (again) before doing the tests.

We basically have two places in systemd.postinst, where the service can
be enabled:
The one which reads the entries from /run/systemd/was-enabled (which is
created in preinst) which doesn't seem to happen in your case.

and

if dpkg --compare-versions "$2" lt "218-11~"; then
    systemctl enable systemd-timesyncd.service || true
fi

The latter should only be run from upgrades older then 218-11 or on new
installs.


So for some reason "$2" (the old version) was either empty or lower then
218-11.

That's why I want the complete dpkg log.

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

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

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

From: Yuri D'Elia <wavexx@thregr.org>

To: Michael Biebl <biebl@debian.org>, 801389@bugs.debian.org

Subject: Re: Bug#801389: Disabling timedatectl/NTP across package upgrades

Date: Mon, 12 Oct 2015 13:10:41 +0200

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

On 09/10/15 19:33, Michael Biebl wrote:
> The complete log dpkg log from the upgrade.

I didn't have time to try and replicate the issue with the
downgrade/upgrade again yet.

Attached there's the dpkg.log of the previous update (227-1 -> 227-2).

[dpkg.log (text/x-log, attachment)]

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

From: Michael Biebl <biebl@debian.org>

To: Yuri D'Elia <wavexx@thregr.org>, 801389@bugs.debian.org

Subject: Re: Bug#801389: Disabling timedatectl/NTP across package upgrades

Date: Wed, 21 Oct 2015 01:38:28 +0200

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

Am 09.10.2015 um 19:33 schrieb Michael Biebl:
> if dpkg --compare-versions "$2" lt "218-11~"; then
>     systemctl enable systemd-timesyncd.service || true
> fi
> 
> The latter should only be run from upgrades older then 218-11 or on new
> installs.
> 
> 
> So for some reason "$2" (the old version) was either empty or lower then
> 218-11.

The root cause for this might be a bug in dpkg:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801156

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

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

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

From: Martin Pitt <mpitt@debian.org>

To: 802545-close@bugs.debian.org

Subject: Bug#802545: fixed in systemd 228-5

Date: Wed, 03 Feb 2016 10:28:36 +0000

Source: systemd
Source-Version: 228-5

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 802545@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: Wed, 03 Feb 2016 10:09:46 +0100
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 systemd-dbg
Architecture: source amd64
Version: 228-5
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-dbg - system and service manager (debug symbols)
 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: 765586 800947 802545 805617 807462 808222 808237 810367 810748 812522 812928
Changes:
 systemd (228-5) unstable; urgency=medium
 .
   [ Martin Pitt ]
   * Drop systemd-vconsole-setup.service: It has never been installed/used in
     Debian and is not necessary for Ubuntu any more.
   * Drop halt-local.service. This has never been documented/used in Debian.
     (LP: #1532553)
   * debian/extra/initramfs-tools/scripts/init-bottom/udev: Prefer "nuke"
     again, it comes from klibc-utils. But fall back to "rm" if it does not
     exist.
   * systemd-timesyncd.service.d/disable-with-time-daemon.conf: Also don't run
     if /usr/sbin/VBoxService exists, as virtualbox-guest-utils already
     provides time synchronization with the host. (Closes: #812522)
   * Drop Michael Stapelberg from Uploaders:, he stopped maintenance long ago.
     Thanks Michael for your great work in the past!
   * Replace "sysv-rc" dependency with Conflicts: openrc, file-rc. The
     rationale from #739679 still applies, but with the moving of
     {invoke,update}-rc.d to init-system-helpers we don't actually need
     anything from sysv-rc any more other than the assumption that SysV init
     scripts are enabled in /etc/rc?.d/ for the SysV generator to work (and
     file-rc and openrc don't do that).
   * debian/tests/timedated: Verify /etc/localtime symlink. Skip verifying the
     /etc/timezone file (which is Debian specific) if $TEST_UPSTREAM is set.
   * debian/tests/localed-locale: Check /etc/locale.conf if $TEST_UPSTREAM is
     set.
   * debian/tests/localed-x11-keymap: Test /etc/X11/xorg.conf.d/00-keyboard.conf
     if $TEST_UPSTREAM is set.
   * debian/tests/boot-and-services: Check for reaching graphical.target
     instead of default.target, as the latter is a session systemd state only.
   * debian/tests/boot-and-services: Skip tests which are known to fail/not
     applicable with testing upstream builds.
   * Drop Fix-up-tmpfiles.d-permissions-properly.patch:
     - /run/lock is already created differently by
       Make-run-lock-tmpfs-an-API-fs.patch, and contradicts to that.
     - /run/lock/lockdev/ isn't being used anywhere and got dropped
       upstream; backport the patch (tmpfiles-drop-run-lock-lockdev.patch).
     - Move dropping of "group:wheel" (which has never existed in Debian) into
       debian/rules, to also catch occurrences in other parts of the file which
       the static patch would overlook.
   * Shorten persistent identifier for CCW network interfaces (on s390x only).
     (LP: #1526808)
   * debian/rules: If $TEST_UPSTREAM is set (when building/testing upstream
     master instead of distro packages), don't fail on non-installed new files
     or new library symbols.
   * Add systemd-sysv conflict to upstart-sysv, and version the upstart
     conflict. This works with both Debian's and Ubuntu's upstart packages.
 .
   [ Michael Biebl ]
   * Drop support for the /etc/udev/disabled flag file. This was a workaround
     for udev failing to install with debootstrap because it didn't use
     invoke-rc.d and therefor was not compliant with policy-rc.d. See #520742
     for further details. This is no longer the case, so supporting that file
     only leads to confusion about its purpose.
   * Retrigger cleanup of org.freedesktop.machine1.conf and
     hwclock-save.service now that dpkg has been fixed to correctly pass the
     old version to postinst on upgrade. (Closes: #802545)
   * Only ship *.link files as part of the udev package. The *.network files
     are solely used by systemd-networkd and should therefor be shipped by the
     systemd package. (Closes: #808237)
   * Cherry-pick a few fixes from upstream:
     - Fix unaligned access in initialize_srand(). (Closes: #812928)
     - Don't run kmod-static-nodes.service if module list is empty. This
       requires kmod v23. (Closes: #810367)
     - Fix typo in systemctl(1). (Closes: #807462)
     - Fix systemd-nspawn --link-journal=host to not fail if the directory
       already exists. (Closes: #808222)
     - Fix a typo in logind-dbus.c. The polkit action is named
       org.freedesktop.login1.power-off, not org.freedesktop.login1.poweroff.
     - Don't log an EIO error in gpt-auto-generator if blkid finds something
       which is not a partition table. (Closes: #765586)
     - Apply ACLs to /var/log/journal and also set them explicitly for
       system.journal.
   * Only skip the filesystem check for /usr if the /run/initramfs/fsck-usr
     flag file exists. Otherwise we break booting with dracut which uses
     systemd inside the initramfs. (Closes: #810748)
   * Update the instructions in README.Debian for creating /var/log/journal.
     They are now in line with the documentation in the systemd-journald(8) man
     page and ensure that ACLs and group permissions are properly set.
     (Closes: #800947, #805617)
   * Drop "systemctl daemon-reload" from lsb init-functions hook. This is no
     longer necessary as invoke-rc.d and init-system-helpers take care of this
     nowadays.
Checksums-Sha1:
 5bbb0e9b5ef0aa7b445565913bed026e5a3b4a50 4051 systemd_228-5.dsc
 d6814c992b46981970961b04c962ec3cca60c7cf 148564 systemd_228-5.debian.tar.xz
 7666bdfcbd8e30580906d65b1c35b6c1f16f2dd8 82136 libnss-myhostname_228-5_amd64.deb
 ac5dc2a3fb899088fb5ed0bd322ac969d7d4ff22 161088 libnss-mymachines_228-5_amd64.deb
 d05894afab60d20d80b97e39643e9efa00a0fe75 160922 libnss-resolve_228-5_amd64.deb
 8ad4267d87ee18874b5aee5e76437b7643e8733b 164208 libpam-systemd_228-5_amd64.deb
 3dca791b90b860bfc8e01d24876cc383fda2a8e8 181290 libsystemd-dev_228-5_amd64.deb
 795b8d009e6a54ad26b38b3b1efa70a790df999d 248500 libsystemd0_228-5_amd64.deb
 a424c1a189150bcc76f3f887caa58500e65806bc 69682 libudev-dev_228-5_amd64.deb
 b1108adaa508718823627516a3af36acfda5683f 46826 libudev1-udeb_228-5_amd64.udeb
 71091022425d81f40da496e88b42e7d9bbfab3a0 101372 libudev1_228-5_amd64.deb
 ed7d37d4d4526f65a5af2e7b84059ab8049a1053 705206 systemd-container_228-5_amd64.deb
 cff00b9f768ec4accbd8c37256d8d0618bca66bb 148558 systemd-coredump_228-5_amd64.deb
 1fe3e31dea2ff5516600f06e73d769f17e84cfa1 27558288 systemd-dbg_228-5_amd64.deb
 2b9295b144dcc4a6686223523c1c138c1220e350 309926 systemd-journal-remote_228-5_amd64.deb
 24d755c6f18e0b1af67779781323a93d06319c8d 59828 systemd-sysv_228-5_amd64.deb
 e5d9d2a433fc803c78f1a5a7bb5a5b51a36322f9 3541806 systemd_228-5_amd64.deb
 d890336a991595a0d89701be25bb16febc92086b 265018 udev-udeb_228-5_amd64.udeb
 d89ebb7e86ff17592b62bdce73eb86c2c616611e 1048086 udev_228-5_amd64.deb
Checksums-Sha256:
 4186bb6cec11de36f6dc339b14ea75a388b6a22a6eab76a1386de9046f2d7950 4051 systemd_228-5.dsc
 3246a25bc9a45e3d495c1e0adcdcfb500099c4620f5e63729f9c1582c5913118 148564 systemd_228-5.debian.tar.xz
 c088ed31dc166021f99c7e5eb203953b188f7e76e821e246cc35248a5cae3e9d 82136 libnss-myhostname_228-5_amd64.deb
 1f332b7f0281768428fa6bfee8d8526dfc1fe9fa247921ca7f4925e7f430150d 161088 libnss-mymachines_228-5_amd64.deb
 aa20654fbbdffdda8b5e2e01bb36bf38b1a20061c3784bd43670cc3355a8c826 160922 libnss-resolve_228-5_amd64.deb
 edb592e475032e784c7eb8544c1c90012fd3250748a3f219f11dae2a5be0ece3 164208 libpam-systemd_228-5_amd64.deb
 4e51635b79d7e8ecc2f593ddac7daa03810ddcfb34484f143e48e01ca3e57810 181290 libsystemd-dev_228-5_amd64.deb
 3095765b5a0401f7b00fcd0bfa15f134b59ff823ff1ff1f9e6bffc7152bab9c8 248500 libsystemd0_228-5_amd64.deb
 bed562a0fd634a1778ac019722ccbc6b1acba814ea7423ef457d351086c7a7a4 69682 libudev-dev_228-5_amd64.deb
 00cc7e0d2116766c68b65469cb6b2d1137a8325a9db91d13e62ab9f4b9eeb49f 46826 libudev1-udeb_228-5_amd64.udeb
 cc3a0f11b0e492f1d8b3242943d24a7e872c7e69553e53ea4ffd83d02bb417f8 101372 libudev1_228-5_amd64.deb
 c5a29707fcdafab03a35d0479d82823ab0675735ef0237901b47c26657e439a5 705206 systemd-container_228-5_amd64.deb
 a37f0cf8ca2ca78b6b673cac46e30a46608e700f8048437e7599e536c9d7d3ac 148558 systemd-coredump_228-5_amd64.deb
 2f5569b62b9f1fbfa9400706be459d6b90103007cfdfdd65f232ee19368535c1 27558288 systemd-dbg_228-5_amd64.deb
 f9e95038d58edf1136a497ab59ca63b54b2847dd2786d0d113960ded17eddf25 309926 systemd-journal-remote_228-5_amd64.deb
 30458e606e495980b8a6a7e4e7347e85ced69431a2ef5baed74e552f76fe4a7e 59828 systemd-sysv_228-5_amd64.deb
 fa3c34921f82587f4b922f2ed89593d063c1bc895b5f1235508f5992797d770a 3541806 systemd_228-5_amd64.deb
 cb10d8c0312ff5f74c640b743bdcd5ca82072a303c9beaf3987ba7335e951c39 265018 udev-udeb_228-5_amd64.udeb
 cb894b0d949c4671634504cb9739bc4c75c0fa224d99f04e9db473bd5942fc5b 1048086 udev_228-5_amd64.deb
Files:
 eeab5f306d525271d39739b65e76037c 4051 admin optional systemd_228-5.dsc
 afb94e5a0c89f86838211c09412eef4f 148564 admin optional systemd_228-5.debian.tar.xz
 c816e12ee84e9b167b32fc7dc3a07d6d 82136 admin extra libnss-myhostname_228-5_amd64.deb
 1e394601ac885d139c94fc5142732b93 161088 admin extra libnss-mymachines_228-5_amd64.deb
 99fd1b3bdd633d3e5472e235d9b2c2bc 160922 admin extra libnss-resolve_228-5_amd64.deb
 4d99b588fa2d5c192bccaad557f90af8 164208 admin optional libpam-systemd_228-5_amd64.deb
 bae6d1a36480d0aad34cc185c8c6d7f3 181290 libdevel optional libsystemd-dev_228-5_amd64.deb
 b297bda75382a448cb52d44d771c9fbb 248500 libs optional libsystemd0_228-5_amd64.deb
 3bd305560a4f1e5f1adbff29a92bc3de 69682 libdevel optional libudev-dev_228-5_amd64.deb
 012a2953d35d178f61406cda2050608e 46826 debian-installer optional libudev1-udeb_228-5_amd64.udeb
 616f48e0744fdf95be9517a6d51b9f00 101372 libs important libudev1_228-5_amd64.deb
 d7c76fac05812582af5b4c86f7929254 705206 admin optional systemd-container_228-5_amd64.deb
 eb2c907e3dafcf99d5932a4e6d41827f 148558 admin optional systemd-coredump_228-5_amd64.deb
 26fd7683ec4afcc1c03a4f151ba9a758 27558288 debug extra systemd-dbg_228-5_amd64.deb
 506244b717331edfd4de15f204a88d2e 309926 admin optional systemd-journal-remote_228-5_amd64.deb
 4d90ec31f9f5f065df4d07733bcaeb27 59828 admin important systemd-sysv_228-5_amd64.deb
 872e72e6af326a0bf93e3324f0b504af 3541806 admin important systemd_228-5_amd64.deb
 c77dc5681f91b5d489bc489ac353e59c 265018 debian-installer optional udev-udeb_228-5_amd64.udeb
 cc8b63a80de7e541717c5a67b9f59cfb 1048086 admin important udev_228-5_amd64.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJWsciOAAoJENFO8V2v4RNHQ5sP/3AT/DzlFeD4XnMm2hpeu9ih
ulIauPklWQrgkZ8uz9JNwtWwSKCWpiAXVdr1/O2TSS4q5bR2IrkWUhuidCCGQdTt
mgZYy5ytKLvAZ4czAQ9yaV1UXmFtQkAIgp7/xYvmNba5qVQOizB77kZCbWNpIyRC
fKZ53/0cTl1VPUfYFonoaYcuz9Rg5gaUGd6Ngvc2tp/F+jbfoMWtK+a50NpiOe2k
CgAudLZBe2mX+4Pq8IzKhjTAdMy007skVYlXM/QYJfGx4gf7EOU7T/g0knJCmqbC
/pZEs0J58Q9E0oR4oHzBy0hOxrBpJwWYxh8jy36pNjNBXI7hG+ilz48FjJ2CEnw0
F68fnvg4AH1f45D0pfms1Bd3BflRueveWLp85QdBI+2YW/Nb4bm2p6nEGkR26+Mo
8hvGIc7sMouPKRyfcfMRDgktDsqkdiCquHGCMVSlrcEh2jneP2E3pHhf00m0uF1u
klF8D5NB4E6lA+SMnd2weIfpgaNJ1VIyA/0SNRrBEtJECBhkBdZsqASbr7kAjCli
88CjbRnvqeGkSLW9+1zkNcuXqOvp4I/BWFWOCZ4g02Hu9h7Ej9bD40GyqHXqXWQi
UfsWS0kF911Q1UDWOfbH760X43vPvX8facWepxoj3jbvt7ibRbqJ9oeBBoLPdaSV
krqM2LIfVDD7QbFRclZb
=VWF9
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.