Discussion:
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Add Reply
Simon McVittie
2019-08-11 14:40:01 UTC
Reply
Permalink
Package: libelogind0
Version: 241-7
Severity: important

Found while preparing a test VM to test #923240. Please raise this to
RC severity if you think it is justified - I don't want to create the
impression that I'm using RC bugs as a way to push an agenda, but I think
this might deserve critical severity, since it breaks the most obvious
migration path from systemd-logind to elogind, in a way that makes it
hard to recover.

Preconditions:

* A relatively minimal VM where libpam-systemd was installed
by autopkgtest's /usr/share/autopkgtest/setup-commands/setup-testbed,
resembling the result of autopkgtest-build-qemu(1) (I also installed
sudo and openssh-server but they shouldn't be relevant here)

Steps to reproduce:

* apt install sysvinit-core elogind libelogind0
(I had to list all of these packages explicitly for apt to find a
solution, but I don't think that's a bug. Nobody should be switching
from the default logind to elogind without making it clear that they
specifically want that.)

Expected result:

* systemd-sysv is removed
* sysvinit-core and elogind are installed
* the system continues to work
* after a reboot, the system comes up with sysvinit as pid 1, after which
I can remove the systemd package if I want to

Actual result (transcript below):

* systemd-sysv is removed
* sysvinit-core is unpacked
* systemd is also removed
* systemd's prerm fails because it is still the active init system
(this check is present since Debian systemd commit c3f5f249 in 44-6,
released in 2012 - it appears the intention is that anyone wishing to
switch from systemd to sysvinit should replace systemd-sysv with
sysvinit-core, then reboot into sysvinit, and only (auto)remove
systemd after that reboot)
* libsystemd0 is removed anyway
* libelogind0 is not installed yet
* libsystemd.so.0 does not exist
* executables with DT_NEEDED on libsystemd.so.0, notably apt, cannot run
* recovering from this situation is not straightforward

Possible solutions:

(I don't know which of these would be helpful, I'm just speculating...)

Maybe libelogind0 and elogind would be better off having Breaks (inverse
Depends) relationships with their systemd equivalents, instead of
Conflicts (inverse Pre-Depends) which are maybe too strong?

Maybe libelogind0 should install into a different directory, and use
maintainer scripts (perhaps involving dpkg-divert) to get itself to be
loaded instead of libsystemd, so that it doesn't have to have file-level
conflicts with libsystemd at all?

Maybe libelogind0 should have (Conflicts or) Breaks on libpam-systemd and
systemd-sysv, but not on systemd, because packages that depend on a
working systemd-logind are meant to depend on libpam-systemd and not just
systemd?

Some coordination with the systemd maintainers is likely to be necessary
to make sure this works as gracefully as possible, does not leave the
system in a broken state if the migration fails, and does not result in
unsupportable combinations of packages (like libpam-systemd + libelogind0)
being installable.

Regards,
smcv

***@host:~# dpkg-query -W | grep systemd
libnss-systemd:amd64 241-7
libpam-systemd:amd64 241-7
libsystemd0:amd64 241-7
systemd 241-7
systemd-sysv 241-7
***@host:~# apt install sysvinit-core elogind libelogind0
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
initscripts insserv psmisc startpar sysv-rc
Suggested packages:
bootchart2 bootlogd
Recommended packages:
policykit-1
The following packages will be REMOVED:
libnss-systemd libpam-systemd libsystemd0 systemd systemd-sysv
The following NEW packages will be installed:
elogind initscripts insserv libelogind0 psmisc startpar sysv-rc
sysvinit-core
0 upgraded, 8 newly installed, 5 to remove and 9 not upgraded.
Need to get 1461 kB of archives.
After this operation, 11.3 MB disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian sid/main amd64 insserv amd64 1.20.0-2 [68.5 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 startpar amd64 0.63-1 [22.3 kB]
Get:3 http://deb.debian.org/debian sid/main amd64 sysv-rc all 2.95-4 [71.4 kB]
Get:4 http://deb.debian.org/debian sid/main amd64 initscripts amd64 2.95-4 [96.0 kB]
Get:5 http://deb.debian.org/debian sid/main amd64 sysvinit-core amd64 2.95-4 [151 kB]
Get:6 http://deb.debian.org/debian sid/main amd64 libelogind0 amd64 241.3-1+debian1 [224 kB]
Get:7 http://deb.debian.org/debian sid/main amd64 elogind amd64 241.3-1+debian1 [701 kB]
Get:8 http://deb.debian.org/debian sid/main amd64 psmisc amd64 23.2-1+b1 [126 kB]
Fetched 1461 kB in 1s (2056 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_GB.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Preconfiguring packages ...
(Reading database ... 17961 files and directories currently installed.)
Removing libnss-systemd:amd64 (241-7) ...
Checking NSS setup...
Removing libpam-systemd:amd64 (241-7) ...
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Selecting previously unselected package insserv.
(Reading database ... 17948 files and directories currently installed.)
Preparing to unpack .../insserv_1.20.0-2_amd64.deb ...
Unpacking insserv (1.20.0-2) ...
Selecting previously unselected package startpar.
Preparing to unpack .../startpar_0.63-1_amd64.deb ...
Unpacking startpar (0.63-1) ...
Selecting previously unselected package sysv-rc.
Preparing to unpack .../sysv-rc_2.95-4_all.deb ...
Unpacking sysv-rc (2.95-4) ...
Selecting previously unselected package initscripts.
Preparing to unpack .../initscripts_2.95-4_amd64.deb ...
Unpacking initscripts (2.95-4) ...
dpkg: systemd-sysv: dependency problems, but removing anyway as you requested:
init depends on systemd-sysv | sysvinit-core; however:
Package systemd-sysv is to be removed.
Package sysvinit-core is not installed.

(Reading database ... 18050 files and directories currently installed.)
Removing systemd-sysv (241-7) ...
Selecting previously unselected package sysvinit-core.
(Reading database ... 18033 files and directories currently installed.)
Preparing to unpack .../sysvinit-core_2.95-4_amd64.deb ...
Unpacking sysvinit-core (2.95-4) ...
(Reading database ... 18056 files and directories currently installed.)
Removing systemd (241-7) ...
systemd is the active init system, please switch to another before removing systemd.
dpkg: error processing package systemd (--remove):
installed systemd package pre-removal script subprocess returned error exit status 1
dpkg: libsystemd0:amd64: dependency problems, but removing anyway as you requested:
util-linux depends on libsystemd0.
systemd depends on libsystemd0 (= 241-7).
rsyslog depends on libsystemd0 (>= 209).
openssh-server depends on libsystemd0.
libprocps7:amd64 depends on libsystemd0 (>= 209).
libdbus-1-3:amd64 depends on libsystemd0.
libapt-pkg5.0:amd64 depends on libsystemd0 (>= 221).
dbus depends on libsystemd0.
bsdutils depends on libsystemd0.

Removing libsystemd0:amd64 (241-7) ...
Errors were encountered while processing:
systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)
***@host:~# apt
apt: error while loading shared libraries: libsystemd.so.0: cannot open shared object file: No such file or directory
Mark Hindley
2019-08-11 16:20:01 UTC
Reply
Permalink
Simon,

Thanks for this.

I was aware of this in the sense that I know systemd can't be uninstalled whilst
it is PID 1. Most recently this was discussed in #930105 and tagged wontfix.

The only way I have managed to migrate systems reasonably cleanly is to boot
with init=/bin/sh, replace systemd with whatever else and then reboot again. But
as you point out, that is not the obvious migration route that a normal sysadmin
might take.

The problem is that the route recommended in #930105 (et al.) is to first
install sysvinit-core, reboot and then remove systemd. The first step of this
will require removal of almost the entire GUI environment -- something few would
persist with even though it could all be reinstalled later.
Post by Simon McVittie
(I don't know which of these would be helpful, I'm just speculating...)
These are useful, thank you. I will experiment and see.

Mark
Thorsten Glaser
2019-08-13 14:50:03 UTC
Reply
Permalink
Post by Simon McVittie
Found while preparing a test VM to test #923240. Please raise this to
RC severity if you think it is justified - I don't want to create the
I don=E2=80=99t think it=E2=80=99s RC in any of the involved packages (elog=
ind,
systemd (shock!), apt) because it=E2=80=99s really a whole-system / package
management issue.
Post by Simon McVittie
=20
* systemd-sysv is removed
* sysvinit-core is unpacked
* systemd is also removed
* systemd's prerm fails because it is still the active init system
Interesting. But this probably happens before the preinst of
libelogind0 and does prevent its installation, which is not
something easily circumvented.
Post by Simon McVittie
(this check is present since Debian systemd commit c3f5f249 in 44-6,
released in 2012 - it appears the intention is that anyone wishing to
switch from systemd to sysvinit should replace systemd-sysv with
sysvinit-core, then reboot into sysvinit, and only (auto)remove
systemd after that reboot)
Yes but see below.
Post by Simon McVittie
Maybe libelogind0 and elogind would be better off having Breaks (inverse
Depends) relationships with their systemd equivalents, instead of
Conflicts (inverse Pre-Depends) which are maybe too strong?
Conflicts is needed since there are file-level conflicts; otherwise,
the files from libelogind0 would vanish.
Post by Simon McVittie
Maybe libelogind0 should install into a different directory, and use
maintainer scripts (perhaps involving dpkg-divert) to get itself to be
loaded instead of libsystemd, so that it doesn't have to have file-level
conflicts with libsystemd at all?
Might be a path worth looking at, but=E2=80=A6
Post by Simon McVittie
Maybe libelogind0 should have (Conflicts or) Breaks on libpam-systemd and
systemd-sysv, but not on systemd, because packages that depend on a
working systemd-logind are meant to depend on libpam-systemd and not just
systemd?
=E2=80=A6 just like this one, both won=E2=80=99t _really_ work: they=E2=80=
=99d allow the
installation to continue, but the system is not rebootable afterwards
either.

We cannot even use a Pre-Depends on a non-systemd init, because=E2=80=A6
see below.
Post by Simon McVittie
The only way I have managed to migrate systems reasonably cleanly is to b=
oot
Post by Simon McVittie
with init=3D/bin/sh, replace systemd with whatever else and then reboot a=
gain. But
Post by Simon McVittie
as you point out, that is not the obvious migration route that a normal s=
ysadmin
Post by Simon McVittie
might take.
=20
The problem is that the route recommended in #930105 (et al.) is to first
install sysvinit-core, reboot and then remove systemd. The first step of =
this
Post by Simon McVittie
will require removal of almost the entire GUI environment -- something fe=
w would
Post by Simon McVittie
persist with even though it could all be reinstalled later.
Hmm, interesting=E2=80=A6 had not thought of that (you=E2=80=99d probably h=
ave to
do that on systems before installing anything desktop-y, or use my
unofficial packages in the middle).

But TTBOMK it is possible to install sysvinit alongside systemd,
then reboot and select sysvinit as =E2=80=9Calternative=E2=80=9D init from =
the
GRUB menu, then remove everything else. Now that I see /sbin/init
is part of sysvinit-core, I wonder if this is really possible any
more and, if not, why not=E2=80=A6 packages are not supposed to depend on
systemd-sysv=E2=80=A6 (but, ouch, libpam-systemd does).

On the other hand, libpam-systemd Provides logind, so I guess it
is one of the packages replaced by elogind. So some kind of
transition and cross-package/maintainerscript communication is
needed. And no matter what route is chosen, something will always
break in an intermediate state (even the Depends from libpam-systemd
on systemd-sysv will not ensure that systemd is actually the init
system currently running, or used at next boot).

This bears more thought.

bye,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg

**********

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontak=
t.

**********
Mark Hindley
2019-08-13 19:10:01 UTC
Reply
Permalink
Thorsten,

Thanks for this.
Post by Simon McVittie
Found while preparing a test VM to test #923240. Please raise this to
RC severity if you think it is justified - I don't want to create the
I don’t think it’s RC in any of the involved packages (elogind,
systemd (shock!), apt) because it’s really a whole-system / package
management issue.
Yes, that is my conclusion after 2 days of trying different things. Certainly
systemd's prerm failure is pretty brutal. But this happens before any of the
src:elogind preinsts run, so I can't see a way around it. If anything, it is a
limitation in apt (although I am not trying to pass the buck here).
Post by Simon McVittie
* systemd-sysv is removed
* sysvinit-core is unpacked
* systemd is also removed
* systemd's prerm fails because it is still the active init system
Interesting. But this probably happens before the preinst of
libelogind0 and does prevent its installation, which is not
something easily circumvented.
systemd depends on a specific pacakged version of libsystemd0 (currently 241-7
in sid) whilst all other packages at most depend on a particular src version
(eg. >= 213). libelogind Provides libsystemd0 (= ${source:Upstream-Version}) so
the attempted removal of systemd is not triggered by any Conflict with
libelogind, but by the removal of libsystemd0 *before* replacing it with
libelogind0.

So far, I haven't discovered a way to mitigate or preempt that.

I would also add that it surprises me that apt requires symbols from
libsystemd.so. I haven't yet investigated what functionality that is. But that
is a side issue.

Mark
Simon McVittie
2019-08-13 20:20:01 UTC
Reply
Permalink
Post by Mark Hindley
systemd depends on a specific pacakged version of libsystemd0 (currently 241-7
in sid) whilst all other packages at most depend on a particular src version
(eg. >= 213).
Ah, that's a major constraint on finding a correct solution here. systemd
is from the same source package as libsystemd0, so I think it's
reasonable for them to be in lockstep: systemd executables could well be
using private symbols or relying on specific behaviour beyond what the
stable public API guarantees. (dbus-daemon and libdbus have a similar
relationship.)
Post by Mark Hindley
I would also add that it surprises me that apt requires symbols from
libsystemd.so.
libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one
provided by libelogind), to tell systemd-logind (or elogind) not to
shut down while an apt frontend is still installing packages.

If apt wants to talk to D-Bus, sd-bus is certainly not a terrible choice:
newer D-Bus implementations like GDBus and sd-bus have had the opportunity
to learn from libdbus' mistakes.

smcv
Adam Borowski
2019-08-13 20:30:02 UTC
Reply
Permalink
Post by Simon McVittie
Post by Mark Hindley
I would also add that it surprises me that apt requires symbols from
libsystemd.so.
libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one
provided by libelogind), to tell systemd-logind (or elogind) not to
shut down while an apt frontend is still installing packages.
newer D-Bus implementations like GDBus and sd-bus have had the opportunity
to learn from libdbus' mistakes.
Because of consequences of apt failing to run, perhaps this could be ldopened
instead?


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family. Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄⠀⠀⠀⠀
Thorsten Glaser
2019-08-13 20:40:02 UTC
Reply
Permalink
Post by Simon McVittie
Ah, that's a major constraint on finding a correct solution here. systemd
is from the same source package as libsystemd0, so I think it's
reasonable for them to be in lockstep: systemd executables could well be
using private symbols or relying on specific behaviour beyond what the
Indeed.
Post by Simon McVittie
Post by Mark Hindley
I would also add that it surprises me that apt requires symbols from
libsystemd.so.
=20
libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one
provided by libelogind), to tell systemd-logind (or elogind) not to
shut down while an apt frontend is still installing packages.
Ah.

Can that be moved into a separate subprocess (does sd-bus have
a command-line interface) or, if not, dlopen() so it can be
downgraded to a Recommends? (libsystemd0 is still quasi-Essential
as most d=C3=A6mons also Depend on it, but this would make apt at
least work.)

Thanks for the explanation,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg

**********

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontak=
t.

**********
Adam Borowski
2019-08-13 20:50:01 UTC
Reply
Permalink
Post by Thorsten Glaser
Post by Simon McVittie
Post by Mark Hindley
I would also add that it surprises me that apt requires symbols from
libsystemd.so.
libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one
provided by libelogind), to tell systemd-logind (or elogind) not to
shut down while an apt frontend is still installing packages.
Ah.
Can that be moved into a separate subprocess (does sd-bus have
a command-line interface) or, if not, dlopen() so it can be
downgraded to a Recommends? (libsystemd0 is still quasi-Essential
as most dæmons also Depend on it, but this would make apt at
least work.)
The use is contained to a single function (apt-pkg/contrib/fileutl.cc
Inhibit()) thus implementing dlopen() should be easy.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family. Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄⠀⠀⠀⠀
Adam Borowski
2019-08-13 20:30:02 UTC
Reply
Permalink
Post by Mark Hindley
Post by Simon McVittie
Found while preparing a test VM to test #923240. Please raise this to
RC severity if you think it is justified - I don't want to create the
I don’t think it’s RC in any of the involved packages (elogind,
systemd (shock!), apt) because it’s really a whole-system / package
management issue.
Yes, that is my conclusion after 2 days of trying different things. Certainly
systemd's prerm failure is pretty brutal. But this happens before any of the
src:elogind preinsts run, so I can't see a way around it.
The prerm also makes systemd non-removable without uninstalling most packages,
rebooting, then installing anew. Requiring such a reinstall is pretty much
RC in by book.

I've reported this before as #930105 but this got insta-closed+downgraded by
mbiebl. On the other hand, mbiebl routinely does this (or reports RC bugs
on perfectly working packages without naming a reason), thus the closure
might have not been related to merits or lack thereof.


[I'm in Sao Paulo airport, after a day of travel and about to embark again,
thus I can't investigate yet. Not before going home then around a week of
sleep.]

Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family. Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄⠀⠀⠀⠀
Thorsten Glaser
2019-08-13 20:50:01 UTC
Reply
Permalink
The prerm also makes systemd non-removable without uninstalling most pack=
ages,
rebooting, then installing anew. Requiring such a reinstall is pretty mu=
ch
RC in by book.
=20
I've reported this before as #930105 but this got insta-closed+downgraded=
by

Hm =E2=98=B9 but I just had this crazy idea:

1. Merge elogind into libpam-elogind (not the other way round),
as elogind without libpam-elogind is apparently (see the
other thread) not useful in any way.

2. Make libpam-elogind (which apparently Provides logind) work with
libsystemd0 and not Conflict with systemd, only systemd-sysv.
This means code changes (so it works with either library) and
packaging changes: Depends: libelogind0 (>=3D =E2=80=A6) | libsystemd0 (=
=3D =E2=80=A6)
(note libelogind0 is first, for fresh installs)

3. Create a new package elogind which Depends on libelogind0 and
libpam-elogind and Conflicts with systemd, to finish the install.
It probably belongs into Section metapackages and has no content
and can use dh_installdocs --link-doc=3Dlibpam-elogind so even its
/usr/share/doc/elogind is just a symlink.

This way, a sequence would look like:

- apt-get install libpam-elogind
=E2=87=92 removes libpam-systemd and systemd-sysv
=E2=87=92 installs libpam-elogind and sysvinit-core
- reboot
- apt-get install elogind
=E2=87=92 removes systemd
=E2=87=92 replaces libsystemd0 with libelogind0

If this is not suitable I=E2=80=99m blaming the beer I=E2=80=99ve had with =
supper.

bye,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg

**********

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontak=
t.

**********
Adam Borowski
2019-08-13 21:00:02 UTC
Reply
Permalink
Post by Thorsten Glaser
Post by Adam Borowski
The prerm also makes systemd non-removable without uninstalling most packages,
rebooting, then installing anew. Requiring such a reinstall is pretty much
RC in by book.
I've reported this before as #930105 but this got insta-closed+downgraded by
1. Merge elogind into libpam-elogind (not the other way round),
as elogind without libpam-elogind is apparently (see the
other thread) not useful in any way.
I don't think it's reasonable to have the daemon in a library package.

There's also multiarch to think about:
foo:pdp11 Depends libpam-systemd:pdp11
Post by Thorsten Glaser
If this is not suitable I’m blaming the beer I’ve had with supper.
[The queue to board is almost over...]
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family. Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄⠀⠀⠀⠀
Thorsten Glaser
2019-08-13 20:40:01 UTC
Reply
Permalink
Post by Mark Hindley
I would also add that it surprises me that apt requires symbols from
libsystemd.so. I haven't yet investigated what functionality that is. But=
that
Post by Mark Hindley
is a side issue.
Probably for =E2=80=9Cmodern Poett^WLinux desktop=E2=80=9D logging, or some=
such.

bye,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg

**********

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontak=
t.

**********
Mark Hindley
2019-08-14 18:50:02 UTC
Reply
Permalink
Post by Mark Hindley
Thorsten,
Thanks for this.
Post by Simon McVittie
Found while preparing a test VM to test #923240. Please raise this to
RC severity if you think it is justified - I don't want to create the
I don’t think it’s RC in any of the involved packages (elogind,
systemd (shock!), apt) because it’s really a whole-system / package
management issue.
Yes, that is my conclusion after 2 days of trying different things. Certainly
systemd's prerm failure is pretty brutal. But this happens before any of the
src:elogind preinsts run, so I can't see a way around it. If anything, it is a
limitation in apt (although I am not trying to pass the buck here).
I have managed to work around this today. It requires circumventing the systemd
prerm failure. I am not recommending that as a final solution, but maybe we can
have another go at asking the systemd maintainers to review it?

What works for me on a sid VM:

1) rmdir /run/systemd/system

This is the directory that the systemd prerm checks for.

2) apt install libpam-elogind systemd-

3) Immediate reboot with shutdown -r -n

Although systemd as PID 1 no longer functions, all processes are sent
SIGTERM, filesystems are synced and unmounted.

I realise this is not graceful or elegant and I am unsure how safe it is.

Comments?

Perhaps we could ask that the systemd prerm no longer fails but instead prints a
message saying immediate reboot is required and how to achieve it?

Mark
Simon McVittie
2019-08-14 19:10:03 UTC
Reply
Permalink
Post by Mark Hindley
I have managed to work around this today. It requires circumventing the systemd
prerm failure. I am not recommending that as a final solution, but maybe we can
have another go at asking the systemd maintainers to review it?
Please do; they might have a better idea of how this can work, and
it's them that you'll need to coordinate with for the libsystemd0 and
libelogind0 providers of libsystemd.so.0 to not fight (more than they
have to) anyway.

smcv
Mark Hindley
2019-08-15 09:50:01 UTC
Reply
Permalink
Post by Thorsten Glaser
But TTBOMK it is possible to install sysvinit alongside systemd,
then reboot and select sysvinit as “alternative” init from the
GRUB menu, then remove everything else. Now that I see /sbin/init
is part of sysvinit-core, I wonder if this is really possible any
more and, if not, why not… packages are not supposed to depend on
systemd-sysv… (but, ouch, libpam-systemd does).
Can you point me to any official documentation that says packages should not
depend on systemd-sysv?

Thanks.

Mark
Thorsten Glaser
2019-08-15 16:40:01 UTC
Reply
Permalink
Post by Mark Hindley
Can you point me to any official documentation that says packages
should not depend on systemd-sysv?
No, but why should they? It=E2=80=99s an almost empty package, and it
can be fulfilled by just depending on systemd.

It does not guarantee that systemd is the currently-running init,
nor that this will be so at the next boot.

bye,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg

**********

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontak=
t.

**********
Simon McVittie
2019-08-15 19:10:02 UTC
Reply
Permalink
Post by Thorsten Glaser
Post by Mark Hindley
Can you point me to any official documentation that says packages
should not depend on systemd-sysv?
No, but why should they?
For documentation value, if nothing else: it's a way to say "this package
genuinely does need systemd as pid 1, and won't work without it".
Post by Thorsten Glaser
It does not guarantee that systemd is the currently-running init,
nor that this will be so at the next boot.
No, and it's imperfect for those reasons; but for this not to be the
case, you have to override the init system in ways that you will hopefully
remember that you have done.

smcv
Thorsten Glaser
2019-08-13 21:00:02 UTC
Reply
Permalink
Post by Thorsten Glaser
1. Merge elogind into libpam-elogind (not the other way round),
as elogind without libpam-elogind is apparently (see the
other thread) not useful in any way.
=20
I don't think it's reasonable to have the daemon in a library package.
=20
foo:pdp11 Depends libpam-systemd:pdp11
Not exactly what you wrote, but I see it now (M-A same vs foreign,
even though libpam-elogind is no library package and contains a
conffile additioinally).

There is no libpam-systemd in this equation.

So then, rename elogind to elogind-daemon instead of merging it,
and let libpam-elogind depend on elogind-daemon. The rest still
stands (it is important that installing a package called simply
=E2=80=9Celogind=E2=80=9D is the final step after a potential reboot, for b=
eing
able to tell people to =E2=80=9Cjust install elogind=E2=80=9D).

This would solve two of my confusions.

bye,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg

**********

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontak=
t.

**********
Mark Hindley
2019-08-15 10:20:02 UTC
Reply
Permalink
Thanks for everybody's input with this thorny issue.

I am now wondering if the prime responsibliity for the system breakage here is
down to apt's behaviour.
Post by Simon McVittie
* systemd-sysv is removed
* sysvinit-core is unpacked
* systemd is also removed
* systemd's prerm fails because it is still the active init system
(this check is present since Debian systemd commit c3f5f249 in 44-6,
released in 2012 - it appears the intention is that anyone wishing to
switch from systemd to sysvinit should replace systemd-sysv with
sysvinit-core, then reboot into sysvinit, and only (auto)remove
systemd after that reboot)
At this point apt has failed to remove systemd/241-7 which depends on libsystemd
(=241-7). Surely it should not then go on to try and remove the systemd
dependency? libelogind0 provides libsystemd0 (=241.3) so could never satisfy
that requirement.
Post by Simon McVittie
* libsystemd0 is removed anyway
That is wrong and breaks systemd, never mind apt…

Am I missing something?

Mark
Thorsten Glaser
2019-08-15 16:40:02 UTC
Reply
Permalink
I am now wondering if the prime responsibliity for the system breakage he=
re is
down to apt's behaviour.
[=E2=80=A6]
At this point apt has failed to remove systemd/241-7 which depends on lib=
systemd
(=3D241-7). Surely it should not then go on to try and remove the systemd
dependency?
Unsure if that=E2=80=99s apt or dpkg. Plus, the failing prerm is in systemd=
,
not in libsystemd0.

For dpkg, it makes sense to remove libsystemd0 nevertheless, when
called literally; for apt, it doesn=E2=80=99t. (Interestingly enough,
the dpkg developer has been telling the apt developers for ages
that dpkg now can handle this kind of dependencies, and not to
use the =E2=80=9Cdo what I said and ignore dependencies=E2=80=9D mode any m=
ore.)

It does make sense to bring the developers of both apt and dpkg
into this, irrelevant of where an improvement can be done, unless
my beer-induced idea I already posted works.

bye,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg

**********

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontak=
t.

**********
Simon McVittie
2019-08-15 19:10:01 UTC
Reply
Permalink
Post by Mark Hindley
At this point apt has failed to remove systemd/241-7 which depends on libsystemd
(=241-7). Surely it should not then go on to try and remove the systemd
dependency?
Unsure if that’s apt or dpkg. Plus, the failing prerm is in systemd,
not in libsystemd0.
I think this is probably dpkg, but it's dpkg being told what to do by
apt, so it could be either one causing this. I would have hoped that if
systemd.prerm fails, that's a fairly heavy hint that not only is it not
OK to remove systemd at this time, it's also not OK to remove systemd's
dependencies.

I still wonder whether apt/dpkg are being forced into this by libelogind0
using Conflicts rather than Breaks - Conflicts is a stronger relationship
than Breaks, and forces libsystemd0 to be removed altogether, not just
deconfigured (marked as "broken"), before unpacking libelogind0. That
means there's an unavoidable window during which libsystemd0 no longer
provides libsystemd.so.0, but libelogind0 doesn't provide it yet.

smcv
Thorsten Glaser
2019-08-15 19:30:02 UTC
Reply
Permalink
Post by Simon McVittie
I still wonder whether apt/dpkg are being forced into this by libelogind0
using Conflicts rather than Breaks - Conflicts is a stronger relationship
AFAICT file-level conflicts still need Provides+Conflicts+Replaces,
and these are what we have here.

(Otherwise, we could just have called Breaks Conflicts and dropped
the original latter.)
Post by Simon McVittie
That
means there's an unavoidable window during which libsystemd0 no longer
provides libsystemd.so.0, but libelogind0 doesn't provide it yet.
Sure, but that=E2=80=99s business as usual in many cases.

The dependency of apt on libsystemd.so.0 is unfortunate, but
apparently easy to fix.

bye,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg

**********

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontak=
t.

**********
Mark Hindley
2019-08-15 19:50:01 UTC
Reply
Permalink
Post by Simon McVittie
Post by Mark Hindley
At this point apt has failed to remove systemd/241-7 which depends on libsystemd
(=241-7). Surely it should not then go on to try and remove the systemd
dependency?
Unsure if that’s apt or dpkg. Plus, the failing prerm is in systemd,
not in libsystemd0.
I think this is probably dpkg, but it's dpkg being told what to do by
apt, so it could be either one causing this. I would have hoped that if
systemd.prerm fails, that's a fairly heavy hint that not only is it not
OK to remove systemd at this time, it's also not OK to remove systemd's
dependencies.
Yes, but that appears not to happen.
Post by Simon McVittie
I still wonder whether apt/dpkg are being forced into this by libelogind0
using Conflicts rather than Breaks - Conflicts is a stronger relationship
than Breaks, and forces libsystemd0 to be removed altogether, not just
deconfigured (marked as "broken"), before unpacking libelogind0. That
means there's an unavoidable window during which libsystemd0 no longer
provides libsystemd.so.0, but libelogind0 doesn't provide it yet.
I don't think so because the versions are different. systemd 241-7 Depends on
libsystemd0 =241-7 (= ${binary:Version}). libelogind0 Provides libsystemd0
=241.3 (= ${source:Upstream-Version}. That can never satisfy the systemd
dependency.

I am pretty sure I tried with Breaks and the result was the same.

Mark
Thorsten Glaser
2019-08-15 20:10:02 UTC
Reply
Permalink
I don't think so because the versions are different. systemd 241-7 Depend=
s on
libsystemd0 =3D241-7 (=3D ${binary:Version}). libelogind0 Provides libsys=
temd0
=3D241.3 (=3D ${source:Upstream-Version}. That can never satisfy the syst=
emd
dependency.
The idea here is that systemd depends on implementation details
of its library, whereas libelogind0 stubs only enough to get all
other applications working, so it is not expected to satisfy the
dependency of systemd, rightfully.

bye,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg

**********

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontak=
t.

**********
Mark Hindley
2019-08-27 17:00:01 UTC
Reply
Permalink
Control: block -1 935910
Post by Simon McVittie
Unsure if that’s apt or dpkg. Plus, the failing prerm is in systemd,
not in libsystemd0.
I think this is probably dpkg, but it's dpkg being told what to do by
apt, so it could be either one causing this. I would have hoped that if
systemd.prerm fails, that's a fairly heavy hint that not only is it not
OK to remove systemd at this time, it's also not OK to remove systemd's
dependencies.
Simon,

I think I have finally got to the bottom of this. As you suspected it is apt's
invocation of dpkg. See #935910.

Mark
Thorsten Glaser
2019-08-15 19:10:02 UTC
Reply
Permalink
Post by Thorsten Glaser
Post by Mark Hindley
Can you point me to any official documentation that says packages
should not depend on systemd-sysv?
=20
No, but why should they?
=20
For documentation value, if nothing else: it's a way to say "this package
genuinely does need systemd as pid 1, and won't work without it".
OK, good point.

Back to finding a migration path, then (perhaps even both ways)=E2=80=A6

bye,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg

**********

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontak=
t.

**********
Mark Hindley
2019-09-21 11:10:01 UTC
Reply
Permalink
Control: tags -1 - pending
On irc he also said there was little point in adding the Breaks: as apt doesn't
rexec itself.
Yes, even a Pre-Depends would not achieve anything TTBOMK.
OK. Thanks.

Removing the pending tag as I don't think there is anything for elogind to do to
fix this.

Simon,

Are you happy for me to close this as resolved?

Mark
Cristian Ionescu-Idbohrn
2019-09-21 14:50:01 UTC
Reply
Permalink
Post by Mark Hindley
Removing the pending tag as I don't think there is anything for
elogind to do to fix this.
Hi,

I'm interested in this, but my systems (unstable and testing) are in a
slightly different state. Let's take unstable, for example:

,----
| # apt-cache policy systemd-sysv
| systemd-sysv:
| Installed: (none)
| Candidate: (none)
`----

,----
| # apt-cache policy sysvinit-core
| sysvinit-core:
| Installed: 2.96~beta-1
| Candidate: 2.96~beta-1
`----

,----
| # apt-cache policy systemd
| systemd:
| Installed: 238-5
| Candidate: 238-5
`----

(that is an older version). And that's because i have:

,----
| # cat /etc/apt/preferences.d/no-systemd
| Package: systemd systemd-sysv libsystemd0 libpam-systemd
| Pin: release o=Debian
| Pin-Priority: -1
`----

So, pid 1 is already:

,----
| -rwxr-xr-x 1 root root 53176 Aug 24 16:46 /sbin/init
`----

Systemd stuff was forcibly installed, but systemd is _not_ pid 1.

Attempting to install:

,----
| # apt-get install libpam-elogind elogind libelogind0
`----

gives me a list of:

,----
| 4 upgraded, 3 newly installed, 97 to remove and 146 not upgraded.
`----

Most of the packages to be removed are kde-related:

,----
| The following packages will be REMOVED:
| akonadi-server breeze drkonqi ffmpegthumbs frameworkintegration k3b
| kactivitymanagerd kaffeine kamera kamoso kcachegrind kde-cli-tools
| kde-config-cddb kde-config-screenlocker kde-runtime kde-style-breeze
| kdeconnect kdelibs5-plugins kdesudo kinit kio kmahjongg kmenuedit kommander
| kpat krusader kwin-common kwin-style-breeze libcolorcorrect5 libk3b7
| libkf5akonadicore5abi2 libkf5akonadiwidgets5abi1 libkf5auth5 libkf5authcore5
| libkf5bookmarks5 libkf5cddb5 libkf5configwidgets5 libkf5declarative5
| libkf5iconthemes5 libkf5kcmutils5 libkf5kdegames7 libkf5kdelibs4support5
| libkf5kdelibs4support5-bin libkf5kiocore5 libkf5kiofilewidgets5
| libkf5kiogui5 libkf5kiowidgets5 libkf5kmahjongglib5 libkf5newstuff5
| libkf5newstuffcore5 libkf5notifyconfig5 libkf5parts5 libkf5plasma5
| libkf5plasmaquick5 libkf5purpose-bin libkf5purpose5 libkf5quickaddons5
| libkf5runner5 libkf5sane5 libkf5style5 libkf5texteditor-bin
| libkf5texteditor5 libkf5textwidgets5 libkf5wallet-bin libkf5xmlgui5
| libkf5xmlrpcclient5 libkscreenlocker5 libkwin4-effect-builtins1
| libokular5core8 libpam-systemd libpolkit-backend-1-0 libpolkit-qt-1-1
| libpolkit-qt5-1-1 libprocessui7 libsystemd0 libtaskmanager6 libweather-ion7
| milou okular plasma-desktop plasma-framework plasma-integration
| plasma-workspace polkit-kde-agent-1 qml-module-org-kde-draganddrop
| qml-module-org-kde-kconfig qml-module-org-kde-kcoreaddons
| qml-module-org-kde-kquickcontrols qml-module-org-kde-kquickcontrolsaddons
| qml-module-org-kde-kwindowsystem qml-module-org-kde-purpose
| qml-module-org-kde-qqc2desktopstyle rasdaemon skanlite skrooge systemd
| udisks2
`----

but not only (some *polkit* among them, I guess kde-related). Of
course I could let them be removed and later reinstall them. But
that's not smooth/optimal.

Still:

,----
| The following additional packages will be installed:
| gir1.2-polkit-1.0 libpolkit-agent-1-0 libpolkit-gobject-1-0 policykit-1
`----

Looking deeper I notice both libelogind0 and libpam-elogind provide a
certain version of systemd packages:

,----
| Package: libelogind0
| Provides: libsystemd0 (= 241.3)
`----

,----
| Package: libpam-elogind
| Provides: logind (= 241.3-1+debian1)
`----

but can't help wondering if that is necessary/relevant. Shouldn't
they provide _any_ current version of libsystemd0 and logind and
remove _any_ earlier versions? Isn't installing the current versions
of systemd-related packages an unnecessary step?


Cheers,
--
Cristian
Mark Hindley
2019-09-21 16:30:01 UTC
Reply
Permalink
Cristian,
Post by Cristian Ionescu-Idbohrn
I'm interested in this, but my systems (unstable and testing) are in a
Thanks for this. However, I really don't see it as relating to Simon's original
report.

Would you, please, start a new bug for this unless you really think it is the
same issue (apt being broken by continuing to uninstall libsystemd0 after
systemd prerm fails) and I will be happy to help.

Thanks.

Mark
Cristian Ionescu-Idbohrn
2019-09-22 08:10:01 UTC
Reply
Permalink
Post by Mark Hindley
Would you, please, start a new bug for this unless you really think
it is the same issue (apt being broken by continuing to uninstall
libsystemd0 after systemd prerm fails) and I will be happy to help.
I really don't know what to think, but I do really feel this is not
related to the systemd installed version. Any current systemd version
should be removed without affecting the state. Am I wrong?
I have to admit I am not clear exactly what you see is the problem.
Is it that removing systemd is taking lots of other packages with
it?
Looking at the list of removals I think it is libpolkit-qt-1 that is
taking everything else out becuase it has not been patched to
support the new logind virtual packages. See #925344.
But I still don't think it is the same as Simon's original bug here.
Mark,

I think you're right. I'll wait until the polkit-qt packages are
patched, and if that does not solve my problem I'll submit a bug.


Cheers,
--
Cristian
Loading...