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)
