Successfully switched to sysvinit on buster/Xfce with selected packages from unstable/experimental

[Jacob Nevins]

Ian Jackson writes:
> I saw #925489.  I think it would be possible to make an argument to
> unblock it on the grounds that it won't affect anyone but non-systemd
> users, and it purely helps those users.
> 
> To make that argument it wouidl be good to test it and I think that is
> one of the things Jacob is trying to do...

Indeed it is.

With hints from this thread and friends, I have succeeded in converting
my laptop Buster install from systemd to sysvinit, and all of the
desktop-y laptop-y things I have tried still seem to work. \o/

It was a bit of a bumpy ride, but with some foresight some of the bumps
I encountered could be avoided.

I hope this will let us make an argument to unblock relevant things from
buster, and/or write working instructions for buster users (which I'll
talk about in a followup mail).


The key insight was the need for libpam-elogind-compat/experimental,
which I had missed.

(I have more console logs, if anyone wants them, but this mail is long
enough as it is.)

Having added sources and pin for experimental as well as unstable,
here is the command I ran (however DO NOT RUN THIS YOURSELF; you will
probably regret it):

apt install sysvinit-core elogind/unstable libelogind0/unstable libelogind0:i386/unstable libpam-elogind/unstable libpam-elogind-compat/experimental

These are the significant changes apt wanted to make:

The following packages will be REMOVED:
  dbus-user-session iio-sensor-proxy libnss-systemd libpam-systemd libsystemd0
  libsystemd0:i386 plymouth plymouth-label systemd systemd-sysv
The following NEW packages will be installed:
  elogind initscripts insserv libelogind0 libelogind0:i386 libpam-elogind
  libpam-elogind-compat psmisc startpar sysv-rc sysvinit-core

This seemed acceptable to me (many fewer removals than before). Some
analysis of the removals:
 - systemd-sysv: since this provides /sbin/init, it obviously has to go?
 - systemd: I gather this would ideally be co-installable with
   sysvinit-core? However, in practice elogind conflicts with it.
 - libsystemd0 libsystemd0:i386 libnss-systemd libpam-systemd:
   not surprising that these have to go
 - plymouth plymouth-label: chat on IRC suggests that perhaps ideally
   these would stay? But plymouth has a direct dependency on systemd.
 - dbus-user-session: direct dependency on systemd
 - iio-sensor-proxy: another direct dependency on systemd.
   <https://bugs.debian.org/901187> says it oughtn't to.
   (I think this got pulled in by redshift via a Recommends from
   geoclue-2.0; doesn't look important so I just let it go.)

For completeness, I sought aptitude's analysis of why these removals:
  systemd-sysv conflicts with sysvinit-core
    libpam-systemd depends upon systemd-sysv
  elogind conflicts with systemd
    libnss-systemd depends upon systemd
    plymouth depends upon systemd (>= 232-8~)
      plymouth-label depends upon plymouth (= 0.9.4-1.1)
    dbus-user-session depends upon systemd
    iio-sensor-proxy depends upon systemd
  libelogind0 conflicts with libsystemd0
  libelogind0 conflicts with libsystemd0:i386
  "Leave the following recommendations unresolved:"
    xfce4-session recommends systemd-sysv | systemd-shim
    pulseaudio recommends dbus-user-session
    pinentry-gnome3 recommends dbus-user-session
    geoclue-2.0 recommends iio-sensor-proxy
    desktop-base recommends plymouth-label
    dbus-user-session recommends systemd-sysv


However, when I ran this command, the systemd package's prerm refused to
let systemd be uninstalled:

  Removing systemd (241-3) ...
  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

This left the system in an amusing state halfway through apt's work,
with lots of unconfigured packages and unsatisfied dependencies.
Notably, neither of the packages providing libsystemd0.so.0 was
installed at this point, leading to fun like:

  # vi /etc/whatever
  vi: error while loading shared libraries: libsystemd.so.0: cannot open shared object file: No such file or directory

(Fortunately, 'nano' still worked.)
A lot of important binaries need a libsystemd0! E.g., util-linux,
bsdutils, lvm2 (see below).

systemd-sysv, which actually provides /sbin/init, had already gone
without a whimper, and sysvinit-core was already unpacked and providing
a new /sbin/init. I guess the logic for systemd's prerm check is that
without /bin/systemctl (provided by systemd), the system can't shut down
daemons cleanly, which is true.

I resolved this by hand-editing /var/lib/dpkg/info/systemd.prerm to
comment out the "active init system" check (and resigning myself to an
unclean shutdown -- indeed, when I came to reboot, "poweroff" and
"shutdown" had no effect) and then doing 'dpkg -r systemd' by hand.

I think if I had edited the prerm before running 'apt install', it might
have gone much more smoothly. As it was, I had to do a bunch of recovery
with dpkg and apt.

I did have trouble with various package maintainer scripts (such as
elogind's) trying to run systemctl after it had gone away. So perhaps
even with the prerm hack, I would still have had to defer their
configure steps until a reboot into single-user mode with sysvinit.


When I did reboot, it turned out I had contrived to end up with an
initramfs without a libsystemd0 from either of its possible providers,
and the 'lvm' binary needs it, so my system was unbootable (since its
filesystems use LUKS and LVM):

  Begin: Running /scripts/local-block ... lvm: error while loading shared libraries: libsystemd.so.0: cannot open shared object file: No such file or directory
  [...]
  (initramfs) _

I recovered from this by booting the target with a buster d-i RC1 USB
stick in rescue mode, and doing 'dpkg-reconfigure initramfs-tools'; this
created an initrd with libsystemd.so.0.
(I considered doing this before rebooting out of systemd, but had been
spooked by the systemctl trouble. This whole bump seems like it would be
avoidable with foresight.)

The new initramfs got my system bootable again, so that I could finish
the cleanup from my previous woes with 'dpkg --configure --pending' in
single-user mode (which no longer tried to invoke systemctl), then
reboot into normal mode.


On the resulting system, all the things I thought might be broken seem
to more or less just work as well as they did with systemd!
 - graphical login screen with X.org and lightdm
 - Xfce desktop
 - Wi-Fi via network-manager, including changing networks with GUI
 - Wi-Fi on/off hotkey
 - brightness keys
 - volume keys (no on-screen display, but that was true with systemd as
   well)
 - suspend via GUI
   - This basically works, but has the only slight regression I've noticed:
     Suspend is quick. Resume quickly shows my desktop contents (which
     ought to be hidden), although it doesn't obviously let me type at
     them. After a second or two it belatedly displays a lock screen
     instead. With systemd, it was slow to show me the lock screen but
     it didn't show my desktop.
 - suspend via lid close
 - (I can't test hibernation due to encrypted swap)
 - power manager GUI seems to notice AC adapter plug/unplug

I had various systemd packages in config-files state. I purged these.
Also, psmisc was supposed to be installed via Recommends and got lost in
the shuffle; I fixed that. None of that seemed to break anything.

At the end of the day, these are the only packages I have installed that
don't come from buster/testing:

$ apt-show-versions | egrep '/unstable|/experimental'
elogind:amd64/unstable 241.1-1+debian1 uptodate
libelogind0:amd64/unstable 241.1-1+debian1 uptodate
libelogind0:i386/unstable 241.1-1+debian1 uptodate
libpam-elogind:amd64/unstable 241.1-1+debian1 uptodate
libpam-elogind-compat:amd64/experimental 1.3 uptodate

I don't think I have any half-configured or broken packages or local
tweaks or anything on the system.

Since I have a pin in place, I don't expect further uploads to unstable
or experimental to affect my installation, although I guess they would
mean anyone trying to replicate it might have to resort to
snapshot.debian.org. I expect to be able to take most security updates
from buster without trouble.
I'm not sure whether future security updates to systemd in testing /
stable will cause any trouble for me? Would those necessitate new
(possibly backported) elogind packages?


I'm pretty happy with the result, and will keep this installation on my
laptop and see how it goes.