Bug#930105: systemd: prerm fail breaks apt and renders system hard to recover

[Adam Borowski]

Source: systemd
Version: 241-5
Severity: critical
Justification: breaks the whole system


When trying to switch to any other init system (and d-i offers no way to
start with anything but systemd), prerm refuses to uninstall _in the middle
of the apt run_.  This leaves the system in a broken state, with a good part
of tools refusing to start (including apt itself), and for obvious reasons
unbootable.  Anyone without a good knowledge of dpkg's internals would be
unable to recover the system at all.  To even attempt recovery, one has to
rm -rf /run/systemd or otherwise neuter the prerm script.

Thus, what's even the point of this prerm check?  The way dependencies
between systemd components are written, getting apt to even attempt removing
systemd requires a pretty deliberate action.  If, unlike other init systems,
systemd can't cleanly shut down, it's a problem but for any remotely
adequate modern piece of software not a fatal one: any filesystem from this
millenium won't corrupt data on an unexpected power loss, any database
worth its salt won't corrupt data without intentionally defeating fsync, and
so on.   Ie, without the prerm check you may need a SysRq-B or power cycle,
with it you currently end with up with system that can't even run apt.


-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-5-arm64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)