Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

Thorsten Glaser t.glaser at tarent.de
Tue Aug 13 15:46:32 BST 2019


On Sun, 11 Aug 2019, Simon McVittie wrote:

> 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.

> 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

Interesting. But this probably happens before the preinst of
libelogind0 and does prevent its installation, which is not
something easily circumvented.

>   (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.

> 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.

> 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…

> 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?

… just like this one, both won’t _really_ work: they’d 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…
see below.


> 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.

Hmm, interesting… had not thought of that (you’d probably have 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 “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).

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
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander 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 Kontakt.

**********




More information about the Debian-init-diversity mailing list