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

Loading...