Bug#814240: systemd triggers break upgrades within unstable

[Manuel A. Fernandez Montecelo]

Control: reassign -1 apt


2016-03-01 18:01 To Zack Weinberg:

Hi Zack,

2016-03-01 17:27 Zack Weinberg:

On Mon, Feb 29, 2016 at 12:18 PM, Manuel A. Fernandez Montecelo wrote:



DPkg::NoTriggers "true";
DPkg::ConfigurePending "true";
DPkg::TriggersPending "true";



After talking about this bug a few days ago with APT Deities (David
Kalnischkies, in this case), he told me that apt doesn't use "dpkg
--triggers-only" by default.

He believes that apt /could/ issue that command when
"DPkg::TriggersPending" or "DPkg::ConfigurePending" are enabled, and
possibly other similar ones (he didn't mention the specifics).

Such options as marked as experimental and dangerous (man apt.conf) so
maybe they are better left disabled unless there's a specific need to
use them.


On the system with the problem, that setting comes from a file named
/etc/apt/apt.conf.d/triggers, whose entire contents are

# cat /etc/apt/apt.conf.d/triggers
DPkg::NoTriggers "true";
PackageManager::Configure "smart";
DPkg::ConfigurePending "true";
DPkg::TriggersPending "true";

It was last modified in 2011.  I have no memory of having created this
file, but it doesn't belong to any package either.  Searching the 'net
for that combination of options brings me to
https://raphaelhertzog.com/2011/05/30/trying-to-make-dpkg-triggers-more-useful-and-less-painful/
and bug #626599.  It is probable that I saw Raphael's blog post go by
and decided to try it out.


I guessed that it would be something like that that triggered (pun maybe
intended) people to use such options.



I have another computer that runs unstable, and which had not yet
received the systemd 229-2 update; I verified that it does *not* have
any of these settings and then ran the update.  It went through with
no problems.

So that's a pretty strong indicator that this non-default mode is the
cause of the problem.  And it's corroborated by the dpkg/apt logs on
the computer that didn't have these settings, which show no sign of
the problem in the past, as far as I can tell.  But just to make sure,
I would like to leave this bug open until another systemd update comes
along and I can confirm that disabling these settings addresses the
problem on the computer that definitely did have it.


Good, please do inform when that happens.


I suppose that APT folks will want to reassign/clone the bug to
themselves, and either fix the problem or remove the use of these
variables.


Reassigning to apt after speaking to the developers.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#814240: systemd triggers break upgrades within unstable

[Manuel A. Fernandez Montecelo]

Hi Zack,

2016-03-01 17:27 Zack Weinberg:

On Mon, Feb 29, 2016 at 12:18 PM, Manuel A. Fernandez Montecelo wrote:



DPkg::NoTriggers "true";
DPkg::ConfigurePending "true";
DPkg::TriggersPending "true";



After talking about this bug a few days ago with APT Deities (David
Kalnischkies, in this case), he told me that apt doesn't use "dpkg
--triggers-only" by default.

He believes that apt /could/ issue that command when
"DPkg::TriggersPending" or "DPkg::ConfigurePending" are enabled, and
possibly other similar ones (he didn't mention the specifics).

Such options as marked as experimental and dangerous (man apt.conf) so
maybe they are better left disabled unless there's a specific need to
use them.


On the system with the problem, that setting comes from a file named
/etc/apt/apt.conf.d/triggers, whose entire contents are

# cat /etc/apt/apt.conf.d/triggers
DPkg::NoTriggers "true";
PackageManager::Configure "smart";
DPkg::ConfigurePending "true";
DPkg::TriggersPending "true";

It was last modified in 2011.  I have no memory of having created this
file, but it doesn't belong to any package either.  Searching the 'net
for that combination of options brings me to
https://raphaelhertzog.com/2011/05/30/trying-to-make-dpkg-triggers-more-useful-and-less-painful/
and bug #626599.  It is probable that I saw Raphael's blog post go by
and decided to try it out.


I guessed that it would be something like that that triggered (pun maybe
intended) people to use such options.



I have another computer that runs unstable, and which had not yet
received the systemd 229-2 update; I verified that it does *not* have
any of these settings and then ran the update.  It went through with
no problems.

So that's a pretty strong indicator that this non-default mode is the
cause of the problem.  And it's corroborated by the dpkg/apt logs on
the computer that didn't have these settings, which show no sign of
the problem in the past, as far as I can tell.  But just to make sure,
I would like to leave this bug open until another systemd update comes
along and I can confirm that disabling these settings addresses the
problem on the computer that definitely did have it.


Good, please do inform when that happens.


I suppose that APT folks will want to reassign/clone the bug to
themselves, and either fix the problem or remove the use of these
variables.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#814240: systemd triggers break upgrades within unstable

[Zack Weinberg]

On Mon, Feb 29, 2016 at 12:18 PM, Manuel A. Fernandez Montecelo wrote:
>
>> DPkg::NoTriggers "true";
>> DPkg::ConfigurePending "true";
>> DPkg::TriggersPending "true";
>
>
> After talking about this bug a few days ago with APT Deities (David
> Kalnischkies, in this case), he told me that apt doesn't use "dpkg
> --triggers-only" by default.
>
> He believes that apt /could/ issue that command when
> "DPkg::TriggersPending" or "DPkg::ConfigurePending" are enabled, and
> possibly other similar ones (he didn't mention the specifics).
>
> Such options as marked as experimental and dangerous (man apt.conf) so
> maybe they are better left disabled unless there's a specific need to
> use them.

On the system with the problem, that setting comes from a file named
/etc/apt/apt.conf.d/triggers, whose entire contents are

# cat /etc/apt/apt.conf.d/triggers
DPkg::NoTriggers "true";
PackageManager::Configure "smart";
DPkg::ConfigurePending "true";
DPkg::TriggersPending "true";

It was last modified in 2011.  I have no memory of having created this
file, but it doesn't belong to any package either.  Searching the 'net
for that combination of options brings me to
https://raphaelhertzog.com/2011/05/30/trying-to-make-dpkg-triggers-more-useful-and-less-painful/
and bug #626599.  It is probable that I saw Raphael's blog post go by
and decided to try it out.

I have another computer that runs unstable, and which had not yet
received the systemd 229-2 update; I verified that it does *not* have
any of these settings and then ran the update.  It went through with
no problems.

So that's a pretty strong indicator that this non-default mode is the
cause of the problem.  And it's corroborated by the dpkg/apt logs on
the computer that didn't have these settings, which show no sign of
the problem in the past, as far as I can tell.  But just to make sure,
I would like to leave this bug open until another systemd update comes
along and I can confirm that disabling these settings addresses the
problem on the computer that definitely did have it.

zw

Bug#814240: systemd triggers break upgrades within unstable

[Manuel A. Fernandez Montecelo]

Hi again,

2016-02-29 13:17 Zack Weinberg:

On Tue, Feb 23, 2016 at 8:44 AM, Manuel A. Fernandez Montecelo
 wrote:


Thanks for the report.  Do you have the logs around for those
installations attempts, of aptitude (the relevant section in
/var/log/aptitude*), apt (same for /var/log/apt/*) and dpkg
(/var/log/dpkg.log)?


Attached.  I was having trouble finding the right bit of the logs, but
conveniently the problem happened again this morning.  The logs start
immediately after upgrading aptitude to 0.7.6-1, which I did
separately from everything else.


Also, please attach the result of:

apt-config dump


Ok.


Thanks for providing the information.



DPkg::NoTriggers "true";
DPkg::ConfigurePending "true";
DPkg::TriggersPending "true";


After talking about this bug a few days ago with APT Deities (David
Kalnischkies, in this case), he told me that apt doesn't use "dpkg
--triggers-only" by default.

He believes that apt /could/ issue that command when
"DPkg::TriggersPending" or "DPkg::ConfigurePending" are enabled, and
possibly other similar ones (he didn't mention the specifics).

Such options as marked as experimental and dangerous (man apt.conf) so
maybe they are better left disabled unless there's a specific need to
use them.

If you disable and things keep working normally, please report back to
this bug.


Other than that, I am running this reply through deity@ so APT folks can
take a look, give further insight/recommendations, reassign/clone the
bug to src:apt if they want to follow-up, etc.

In principle, there is nothing that aptitude can do about this (other
than disabling the options behind the user's back), so if there's no
input after some time I will close the bug.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#814240: systemd triggers break upgrades within unstable

[Manuel A. Fernandez Montecelo]

(Copying to the bug address now, but no reply in this message.  Will
reply shortly).


2016-02-29 13:17 Zack Weinberg:

On Tue, Feb 23, 2016 at 8:44 AM, Manuel A. Fernandez Montecelo
 wrote:


Thanks for the report.  Do you have the logs around for those
installations attempts, of aptitude (the relevant section in
/var/log/aptitude*), apt (same for /var/log/apt/*) and dpkg
(/var/log/dpkg.log)?


Attached.  I was having trouble finding the right bit of the logs, but
conveniently the problem happened again this morning.  The logs start
immediately after upgrading aptitude to 0.7.6-1, which I did
separately from everything else.


Also, please attach the result of:

apt-config dump


Ok.

zw



APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.4\.0-1-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S 
/var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit 
--object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged 
cache-update > /dev/null; /bin/echo > /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a -e 
/usr/bin/appstreamcli; then appstreamcli refresh > /dev/null; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";

Bug#814240: systemd triggers break upgrades within unstable

[Manuel A. Fernandez Montecelo]

2016-02-23 13:44 To Zack Weinberg:

Hi Zack,

2016-02-15 14:29 Zack Weinberg:

Control: found -1 aptitude/0.7.5-3

On Mon, Feb 15, 2016 at 8:41 AM, Michael Biebl  wrote:


Zack, I guess the aptitude maintainers will want to know which aptitude
version you are using.


I know I've seen this with the version currently in unstable, which is
0.7.5-3. It seems likely to affect older versions as well, though.
Complete output of /usr/share/bug/aptitude is appended.


Thanks for the report.  Do you have the logs around for those
installations attempts, of aptitude (the relevant section in
/var/log/aptitude*), apt (same for /var/log/apt/*) and dpkg
(/var/log/dpkg.log)?

It reminds me a bit of this one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809655

Since aptitude doesn't do the low level operations, e.g. tell dpkg to
unpack, but instead these actions are achieved by instructing apt what
to do with packages in a more abstract way (upgrade, install, remove), I
am bit puzzled.


Also, please attach the result of:

 apt-config dump


--
Manuel A. Fernandez Montecelo 

Bug#814240: systemd triggers break upgrades within unstable

[Manuel A. Fernandez Montecelo]

Hi Zack,

2016-02-15 14:29 Zack Weinberg:

Control: found -1 aptitude/0.7.5-3

On Mon, Feb 15, 2016 at 8:41 AM, Michael Biebl  wrote:


Zack, I guess the aptitude maintainers will want to know which aptitude
version you are using.


I know I've seen this with the version currently in unstable, which is
0.7.5-3. It seems likely to affect older versions as well, though.
Complete output of /usr/share/bug/aptitude is appended.


Thanks for the report.  Do you have the logs around for those
installations attempts, of aptitude (the relevant section in
/var/log/aptitude*), apt (same for /var/log/apt/*) and dpkg
(/var/log/dpkg.log)?

It reminds me a bit of this one:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809655

Since aptitude doesn't do the low level operations, e.g. tell dpkg to
unpack, but instead these actions are achieved by instructing apt what
to do with packages in a more abstract way (upgrade, install, remove), I
am bit puzzled.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#814240: systemd triggers break upgrades within unstable

[Zack Weinberg]

Control: found -1 aptitude/0.7.5-3

On Mon, Feb 15, 2016 at 8:41 AM, Michael Biebl  wrote:
>
> Zack, I guess the aptitude maintainers will want to know which aptitude
> version you are using.

I know I've seen this with the version currently in unstable, which is
0.7.5-3. It seems likely to affect older versions as well, though.
Complete output of /usr/share/bug/aptitude is appended.

zw


$ sh /usr/share/bug/aptitude 3>&1
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.7.5
Compiler: g++ 5.3.1 20151207
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.6.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20151024
  cwidget version: 0.5.17
  Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7fff7e677000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
(0x7f0e19941000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5
(0x7f0e19711000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f0e194e6000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x7f0e192e)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3
(0x7f0e18fe3000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7f0e18d0c000)
libboost_iostreams.so.1.58.0 =>
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0
(0x7f0e18af2000)
libboost_filesystem.so.1.58.0 =>
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0
(0x7f0e188d9000)
libboost_system.so.1.58.0 =>
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0
(0x7f0e186d4000)
libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22
(0x7f0e182d)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f0e180b3000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f0e17d37000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f0e17a32000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f0e1781c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0e17477000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f0e17274000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0e1707)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f0e16e58000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f0e16c3d000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f0e16a2d000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f0e16809000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f0e165f7000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f0e163ee000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f0e161e9000)
/lib64/ld-linux-x86-64.so.2 (0x55ae6e5e4000)

Bug#814240: systemd triggers break upgrades within unstable

[Michael Biebl]

Control: reassign -1 aptitude

Thanks for the feedback, Guillem.
Reassigning to aptitude.

Zack, I guess the aptitude maintainers will want to know which aptitude
version you are using.

Regards,
Michael

Am 15.02.2016 um 10:48 schrieb Guillem Jover:
> Hi!
> 
> On Thu, 2016-02-11 at 00:08:12 +0100, Michael Biebl wrote:
>> Somehow this looks like an issue in dpkg, if it triggers a package which
>> is in an inconsistent state.
> 
> After a very quick look it does not seem to me to be an issue in either
> systemd nor dpkg, see below.
> 
>> But maybe we just made a mistake in our use of triggers in systemd:
>>  
>> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.triggers
>>  
>> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.postinst#n15
> 
> These look fine.
> 
>> Am 09.02.2016 um 14:12 schrieb Zack Weinberg:
>>> Package: systemd
>>> Version: 228-6
>>> Severity: normal
>>>
>>> libpam-systemd, systemd, and libsystemd0 have = dependencies on each
>>> other.  This invariant can be temporarily violated in the middle of a
>>> large upgrade, and AIUI that is normal and to be expected.  However,
>>> systemd has several dpkg triggers that can fire while the = dependencies
>>> are violated, and when this happens, the entire upgrade bombs out.
>>> Worse, one of those triggers seems to be armed and immediately fired *by
>>> upgrading libsystemd0*, before dpkg has had a chance to upgrade systemd
>>> proper, so this is guaranteed to happen any time the systemd packages
>>> are upgraded.
>>>
>>> It's possible to recover by manually installing the new versions of
>>> libpam-systemd, systemd, and libsystemd0, but there's got to be some
>>> way to make apt do the Right Thing, right?  (I don't really understand
>>> triggers.  I thought they were supposed to postpone work until the *end*
>>> of a large upgrade, but they seem to go off all the time in the middle.)
>>>
>>> Example upgrade transcript:
>>>
>>> # aptitude safe-upgrade
>>> [...]
>>> Extracting templates from packages: 100%
>>> Preconfiguring packages ...
>>> [...snip...]
>>> (Reading database ... 289818 files and directories currently installed.)
>>> Preparing to unpack .../linux-image-4.3.0-1-amd64_4.3.5-1_amd64.deb ...
>>> Unpacking linux-image-4.3.0-1-amd64 (4.3.5-1) over (4.3.3-7) ...
>>> Preparing to unpack .../archives/udev_228-6_amd64.deb ...
>>> Unpacking udev (228-6) over (228-5) ...
>>> Preparing to unpack .../libpam-systemd_228-6_amd64.deb ...
>>> Unpacking libpam-systemd:amd64 (228-6) over (228-5) ...
>>> Preparing to unpack .../libsystemd0_228-6_amd64.deb ...
>>> Unpacking libsystemd0:amd64 (228-6) over (228-5) ...
>>> Setting up libsystemd0:amd64 (228-6) ...
>>> Processing triggers for libc-bin (2.21-7) ...
>>> dpkg: dependency problems prevent processing triggers for systemd:
>>>  systemd depends on libsystemd0 (= 228-5); however:
>>>   Version of libsystemd0:amd64 on system is 228-6.
>>>
>>> dpkg: error processing package systemd (--triggers-only):
>>>  dependency problems - leaving triggers unprocessed
>>> Processing triggers for man-db (2.7.5-1) ...
>>> Errors were encountered while processing:
>>>  systemd
>>> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> Well it does not seem like aptitude even tried to unpack systemd
> itself. And then it was requested via --triggers-only to process
> triggers, so any attempt to get the dependencies sorted out will fail.
> 
>>> Failed to perform requested operation on package.  Trying to recover:
>>> Setting up libquadmath0:amd64 (5.3.1-8) ...
>>> Setting up linux-image-4.3.0-1-amd64 (4.3.5-1) ...
>>> [...snip...]
>>> Setting up libobjc4:amd64 (5.3.1-8) ...
>>> dpkg: dependency problems prevent configuration of libpam-systemd:amd64:
>>>  libpam-systemd:amd64 depends on systemd (= 228-6); however:
>>>   Version of systemd on system is 228-5.
>>>
>>> dpkg: error processing package libpam-systemd:amd64 (--configure):
>>>  dependency problems - leaving unconfigured
>>> Setting up libx32gcc1 (1:5.3.1-8) ...
>>> [...snip...]
>>> Setting up udev (228-6) ...
>>> addgroup: The group `input' already exists as a system group. Exiting.
>>> update-initramfs: deferring update (trigger activated)
>>> dpkg: dependency problems prevent processing triggers for systemd:
>>>  systemd depends on libsystemd0 (= 228-5); however:
>>>   Version of libsystemd0:amd64 on system is 228-6.
>>>
>>> dpkg: error processing package systemd (--configure):
>>>  dependency problems - leaving triggers unprocessed
>>> Setting up libx32asan2 (5.3.1-8) ...
>>> [..snip...]
>>> Processing triggers for libc-bin (2.21-7) ...
>>> Processing triggers for initramfs-tools (0.122) ...
>>> update-initramfs: Generating /boot/initrd.img-4.3.0-1-amd64
>>> Errors were encountered while processing:
>>>  libpam-systemd:amd64
>>>  systemd
>>> Press Return to continue.
>>>
>>> # aptitude safe-upgrade
>>> Performing actions...
>>> Reading changelogs... Done
>>> Extracting templates from packages: 

Bug#814240: systemd triggers break upgrades within unstable

[Guillem Jover]

Hi!

On Thu, 2016-02-11 at 00:08:12 +0100, Michael Biebl wrote:
> Somehow this looks like an issue in dpkg, if it triggers a package which
> is in an inconsistent state.

After a very quick look it does not seem to me to be an issue in either
systemd nor dpkg, see below.

> But maybe we just made a mistake in our use of triggers in systemd:
>  
> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.triggers
>  
> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.postinst#n15

These look fine.

> Am 09.02.2016 um 14:12 schrieb Zack Weinberg:
> > Package: systemd
> > Version: 228-6
> > Severity: normal
> > 
> > libpam-systemd, systemd, and libsystemd0 have = dependencies on each
> > other.  This invariant can be temporarily violated in the middle of a
> > large upgrade, and AIUI that is normal and to be expected.  However,
> > systemd has several dpkg triggers that can fire while the = dependencies
> > are violated, and when this happens, the entire upgrade bombs out.
> > Worse, one of those triggers seems to be armed and immediately fired *by
> > upgrading libsystemd0*, before dpkg has had a chance to upgrade systemd
> > proper, so this is guaranteed to happen any time the systemd packages
> > are upgraded.
> > 
> > It's possible to recover by manually installing the new versions of
> > libpam-systemd, systemd, and libsystemd0, but there's got to be some
> > way to make apt do the Right Thing, right?  (I don't really understand
> > triggers.  I thought they were supposed to postpone work until the *end*
> > of a large upgrade, but they seem to go off all the time in the middle.)
> > 
> > Example upgrade transcript:
> > 
> > # aptitude safe-upgrade
> > [...]
> > Extracting templates from packages: 100%
> > Preconfiguring packages ...
> > [...snip...]
> > (Reading database ... 289818 files and directories currently installed.)
> > Preparing to unpack .../linux-image-4.3.0-1-amd64_4.3.5-1_amd64.deb ...
> > Unpacking linux-image-4.3.0-1-amd64 (4.3.5-1) over (4.3.3-7) ...
> > Preparing to unpack .../archives/udev_228-6_amd64.deb ...
> > Unpacking udev (228-6) over (228-5) ...
> > Preparing to unpack .../libpam-systemd_228-6_amd64.deb ...
> > Unpacking libpam-systemd:amd64 (228-6) over (228-5) ...
> > Preparing to unpack .../libsystemd0_228-6_amd64.deb ...
> > Unpacking libsystemd0:amd64 (228-6) over (228-5) ...
> > Setting up libsystemd0:amd64 (228-6) ...
> > Processing triggers for libc-bin (2.21-7) ...
> > dpkg: dependency problems prevent processing triggers for systemd:
> >  systemd depends on libsystemd0 (= 228-5); however:
> >   Version of libsystemd0:amd64 on system is 228-6.
> > 
> > dpkg: error processing package systemd (--triggers-only):
> >  dependency problems - leaving triggers unprocessed
> > Processing triggers for man-db (2.7.5-1) ...
> > Errors were encountered while processing:
> >  systemd
> > E: Sub-process /usr/bin/dpkg returned an error code (1)

Well it does not seem like aptitude even tried to unpack systemd
itself. And then it was requested via --triggers-only to process
triggers, so any attempt to get the dependencies sorted out will fail.

> > Failed to perform requested operation on package.  Trying to recover:
> > Setting up libquadmath0:amd64 (5.3.1-8) ...
> > Setting up linux-image-4.3.0-1-amd64 (4.3.5-1) ...
> > [...snip...]
> > Setting up libobjc4:amd64 (5.3.1-8) ...
> > dpkg: dependency problems prevent configuration of libpam-systemd:amd64:
> >  libpam-systemd:amd64 depends on systemd (= 228-6); however:
> >   Version of systemd on system is 228-5.
> > 
> > dpkg: error processing package libpam-systemd:amd64 (--configure):
> >  dependency problems - leaving unconfigured
> > Setting up libx32gcc1 (1:5.3.1-8) ...
> > [...snip...]
> > Setting up udev (228-6) ...
> > addgroup: The group `input' already exists as a system group. Exiting.
> > update-initramfs: deferring update (trigger activated)
> > dpkg: dependency problems prevent processing triggers for systemd:
> >  systemd depends on libsystemd0 (= 228-5); however:
> >   Version of libsystemd0:amd64 on system is 228-6.
> > 
> > dpkg: error processing package systemd (--configure):
> >  dependency problems - leaving triggers unprocessed
> > Setting up libx32asan2 (5.3.1-8) ...
> > [..snip...]
> > Processing triggers for libc-bin (2.21-7) ...
> > Processing triggers for initramfs-tools (0.122) ...
> > update-initramfs: Generating /boot/initrd.img-4.3.0-1-amd64
> > Errors were encountered while processing:
> >  libpam-systemd:amd64
> >  systemd
> > Press Return to continue.
> > 
> > # aptitude safe-upgrade
> > Performing actions...
> > Reading changelogs... Done
> > Extracting templates from packages: 100%
> > Preconfiguring packages ...
> > (Reading database ... 289818 files and directories currently installed.)
> > Preparing to unpack .../acl_2.2.52-3_amd64.deb ...
> > Unpacking acl (2.2.52-3) over (2.2.52-2) ...
> > Preparing to unpack .../libacl1_2.2.52-3_amd64.deb ...
> > 

Bug#814240: systemd triggers break upgrades within unstable

[Michael Biebl]

Hi Guillem,

could you have a look at this bug report, please?
Somehow this looks like an issue in dpkg, if it triggers a package which
is in an inconsistent state.

But maybe we just made a mistake in our use of triggers in systemd:
 
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.triggers
 
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.postinst#n15

In any case, your input would be very much appreciated.

Michael

Am 09.02.2016 um 14:12 schrieb Zack Weinberg:
> Package: systemd
> Version: 228-6
> Severity: normal
> 
> libpam-systemd, systemd, and libsystemd0 have = dependencies on each
> other.  This invariant can be temporarily violated in the middle of a
> large upgrade, and AIUI that is normal and to be expected.  However,
> systemd has several dpkg triggers that can fire while the = dependencies
> are violated, and when this happens, the entire upgrade bombs out.
> Worse, one of those triggers seems to be armed and immediately fired *by
> upgrading libsystemd0*, before dpkg has had a chance to upgrade systemd
> proper, so this is guaranteed to happen any time the systemd packages
> are upgraded.
> 
> It's possible to recover by manually installing the new versions of
> libpam-systemd, systemd, and libsystemd0, but there's got to be some
> way to make apt do the Right Thing, right?  (I don't really understand
> triggers.  I thought they were supposed to postpone work until the *end*
> of a large upgrade, but they seem to go off all the time in the middle.)
> 
> Example upgrade transcript:
> 
> # aptitude safe-upgrade
> [...]
> Extracting templates from packages: 100%
> Preconfiguring packages ...
> [...snip...]
> (Reading database ... 289818 files and directories currently installed.)
> Preparing to unpack .../linux-image-4.3.0-1-amd64_4.3.5-1_amd64.deb ...
> Unpacking linux-image-4.3.0-1-amd64 (4.3.5-1) over (4.3.3-7) ...
> Preparing to unpack .../archives/udev_228-6_amd64.deb ...
> Unpacking udev (228-6) over (228-5) ...
> Preparing to unpack .../libpam-systemd_228-6_amd64.deb ...
> Unpacking libpam-systemd:amd64 (228-6) over (228-5) ...
> Preparing to unpack .../libsystemd0_228-6_amd64.deb ...
> Unpacking libsystemd0:amd64 (228-6) over (228-5) ...
> Setting up libsystemd0:amd64 (228-6) ...
> Processing triggers for libc-bin (2.21-7) ...
> dpkg: dependency problems prevent processing triggers for systemd:
>  systemd depends on libsystemd0 (= 228-5); however:
>   Version of libsystemd0:amd64 on system is 228-6.
> 
> dpkg: error processing package systemd (--triggers-only):
>  dependency problems - leaving triggers unprocessed
> Processing triggers for man-db (2.7.5-1) ...
> Errors were encountered while processing:
>  systemd
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Failed to perform requested operation on package.  Trying to recover:
> Setting up libquadmath0:amd64 (5.3.1-8) ...
> Setting up linux-image-4.3.0-1-amd64 (4.3.5-1) ...
> [...snip...]
> Setting up libobjc4:amd64 (5.3.1-8) ...
> dpkg: dependency problems prevent configuration of libpam-systemd:amd64:
>  libpam-systemd:amd64 depends on systemd (= 228-6); however:
>   Version of systemd on system is 228-5.
> 
> dpkg: error processing package libpam-systemd:amd64 (--configure):
>  dependency problems - leaving unconfigured
> Setting up libx32gcc1 (1:5.3.1-8) ...
> [...snip...]
> Setting up udev (228-6) ...
> addgroup: The group `input' already exists as a system group. Exiting.
> update-initramfs: deferring update (trigger activated)
> dpkg: dependency problems prevent processing triggers for systemd:
>  systemd depends on libsystemd0 (= 228-5); however:
>   Version of libsystemd0:amd64 on system is 228-6.
> 
> dpkg: error processing package systemd (--configure):
>  dependency problems - leaving triggers unprocessed
> Setting up libx32asan2 (5.3.1-8) ...
> [..snip...]
> Processing triggers for libc-bin (2.21-7) ...
> Processing triggers for initramfs-tools (0.122) ...
> update-initramfs: Generating /boot/initrd.img-4.3.0-1-amd64
> Errors were encountered while processing:
>  libpam-systemd:amd64
>  systemd
> Press Return to continue.
> 
> # aptitude safe-upgrade
> Performing actions...
> Reading changelogs... Done
> Extracting templates from packages: 100%
> Preconfiguring packages ...
> (Reading database ... 289818 files and directories currently installed.)
> Preparing to unpack .../acl_2.2.52-3_amd64.deb ...
> Unpacking acl (2.2.52-3) over (2.2.52-2) ...
> Preparing to unpack .../libacl1_2.2.52-3_amd64.deb ...
> Unpacking libacl1:amd64 (2.2.52-3) over (2.2.52-2) ...
> Setting up libacl1:amd64 (2.2.52-3) ...
> Processing triggers for libc-bin (2.21-7) ...
> dpkg: dependency problems prevent processing triggers for systemd:
>  systemd depends on libsystemd0 (= 228-5); however:
>   Version of libsystemd0:amd64 on system is 228-6.
> 
> dpkg: error processing package systemd (--triggers-only):
>  dependency problems - leaving triggers unprocessed
> Processing 

Bug#814240: systemd triggers break upgrades within unstable

[Michael Biebl]

Am 09.02.2016 um 14:12 schrieb Zack Weinberg:
> Package: systemd
> Version: 228-6
> Severity: normal
> 
> libpam-systemd, systemd, and libsystemd0 have = dependencies on each
> other.  This invariant can be temporarily violated in the middle of a
> large upgrade, and AIUI that is normal and to be expected.  However,
> systemd has several dpkg triggers that can fire while the = dependencies
> are violated, and when this happens, the entire upgrade bombs out.
> Worse, one of those triggers seems to be armed and immediately fired *by
> upgrading libsystemd0*, before dpkg has had a chance to upgrade systemd
> proper, so this is guaranteed to happen any time the systemd packages
> are upgraded.
> 
> It's possible to recover by manually installing the new versions of
> libpam-systemd, systemd, and libsystemd0, but there's got to be some
> way to make apt do the Right Thing, right?  (I don't really understand
> triggers.  I thought they were supposed to postpone work until the *end*
> of a large upgrade, but they seem to go off all the time in the middle.)
> 

This looks like something which needs to be fixed in either dpkg or
aptitude.

Fwiw, I've never seen such a problem using apt.

Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#814240: systemd triggers break upgrades within unstable

[Zack Weinberg]

Package: systemd
Version: 228-6
Severity: normal

libpam-systemd, systemd, and libsystemd0 have = dependencies on each
other.  This invariant can be temporarily violated in the middle of a
large upgrade, and AIUI that is normal and to be expected.  However,
systemd has several dpkg triggers that can fire while the = dependencies
are violated, and when this happens, the entire upgrade bombs out.
Worse, one of those triggers seems to be armed and immediately fired *by
upgrading libsystemd0*, before dpkg has had a chance to upgrade systemd
proper, so this is guaranteed to happen any time the systemd packages
are upgraded.

It's possible to recover by manually installing the new versions of
libpam-systemd, systemd, and libsystemd0, but there's got to be some
way to make apt do the Right Thing, right?  (I don't really understand
triggers.  I thought they were supposed to postpone work until the *end*
of a large upgrade, but they seem to go off all the time in the middle.)

Example upgrade transcript:

# aptitude safe-upgrade
[...]
Extracting templates from packages: 100%
Preconfiguring packages ...
[...snip...]
(Reading database ... 289818 files and directories currently installed.)
Preparing to unpack .../linux-image-4.3.0-1-amd64_4.3.5-1_amd64.deb ...
Unpacking linux-image-4.3.0-1-amd64 (4.3.5-1) over (4.3.3-7) ...
Preparing to unpack .../archives/udev_228-6_amd64.deb ...
Unpacking udev (228-6) over (228-5) ...
Preparing to unpack .../libpam-systemd_228-6_amd64.deb ...
Unpacking libpam-systemd:amd64 (228-6) over (228-5) ...
Preparing to unpack .../libsystemd0_228-6_amd64.deb ...
Unpacking libsystemd0:amd64 (228-6) over (228-5) ...
Setting up libsystemd0:amd64 (228-6) ...
Processing triggers for libc-bin (2.21-7) ...
dpkg: dependency problems prevent processing triggers for systemd:
 systemd depends on libsystemd0 (= 228-5); however:
  Version of libsystemd0:amd64 on system is 228-6.

dpkg: error processing package systemd (--triggers-only):
 dependency problems - leaving triggers unprocessed
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
Setting up libquadmath0:amd64 (5.3.1-8) ...
Setting up linux-image-4.3.0-1-amd64 (4.3.5-1) ...
[...snip...]
Setting up libobjc4:amd64 (5.3.1-8) ...
dpkg: dependency problems prevent configuration of libpam-systemd:amd64:
 libpam-systemd:amd64 depends on systemd (= 228-6); however:
  Version of systemd on system is 228-5.

dpkg: error processing package libpam-systemd:amd64 (--configure):
 dependency problems - leaving unconfigured
Setting up libx32gcc1 (1:5.3.1-8) ...
[...snip...]
Setting up udev (228-6) ...
addgroup: The group `input' already exists as a system group. Exiting.
update-initramfs: deferring update (trigger activated)
dpkg: dependency problems prevent processing triggers for systemd:
 systemd depends on libsystemd0 (= 228-5); however:
  Version of libsystemd0:amd64 on system is 228-6.

dpkg: error processing package systemd (--configure):
 dependency problems - leaving triggers unprocessed
Setting up libx32asan2 (5.3.1-8) ...
[..snip...]
Processing triggers for libc-bin (2.21-7) ...
Processing triggers for initramfs-tools (0.122) ...
update-initramfs: Generating /boot/initrd.img-4.3.0-1-amd64
Errors were encountered while processing:
 libpam-systemd:amd64
 systemd
Press Return to continue.

# aptitude safe-upgrade
Performing actions...
Reading changelogs... Done
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 289818 files and directories currently installed.)
Preparing to unpack .../acl_2.2.52-3_amd64.deb ...
Unpacking acl (2.2.52-3) over (2.2.52-2) ...
Preparing to unpack .../libacl1_2.2.52-3_amd64.deb ...
Unpacking libacl1:amd64 (2.2.52-3) over (2.2.52-2) ...
Setting up libacl1:amd64 (2.2.52-3) ...
Processing triggers for libc-bin (2.21-7) ...
dpkg: dependency problems prevent processing triggers for systemd:
 systemd depends on libsystemd0 (= 228-5); however:
  Version of libsystemd0:amd64 on system is 228-6.

dpkg: error processing package systemd (--triggers-only):
 dependency problems - leaving triggers unprocessed
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
dpkg: dependency problems prevent configuration of libpam-systemd:amd64:
 libpam-systemd:amd64 depends on systemd (= 228-6); however:
  Version of systemd on system is 228-5.

dpkg: error processing package libpam-systemd:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent processing triggers for systemd:
 systemd depends on libsystemd0 (= 228-5); however:
  Version of libsystemd0:amd64 on system is 228-6.

dpkg: error processing package systemd (--configure):
 

Bug#814240: systemd triggers break upgrades within unstable

[Zack Weinberg]

On Tue, Feb 9, 2016 at 9:46 AM, Michael Biebl  wrote:
>>
>> It's possible to recover by manually installing the new versions of
>> libpam-systemd, systemd, and libsystemd0, but there's got to be some
>> way to make apt do the Right Thing, right?  (I don't really understand
>> triggers.  I thought they were supposed to postpone work until the *end*
>> of a large upgrade, but they seem to go off all the time in the middle.)
>>
>
> This looks like something which needs to be fixed in either dpkg or
> aptitude.
>
> Fwiw, I've never seen such a problem using apt.

I do not have either the time or the skills to dig into this any
further, but I suggest you reassign the bug to dpkg and maybe they can
do something with it?

zw