Comment 4 for bug 2000186

Thanks for flagging this Paride; my guess is this would have happened even for something trivial like a changelog-only update.

The default in Debian, for better or for worse, is to enable all services during installation. The default dh_installinit action appears to be failure if the service can't start.

There's a lot of frustrating things here:

- The Debian default feels like it made sense in 1997. I'm not sure it still does.

- dh_installinit probably shouldn't default to failing an installation if the service doesn't run. Recovering a broken apt is difficult for most people and frustrating for everyone. Recovering a broken service is no big deal, especially if you don't care about it.

- The Ubuntu server seed should not include multipathd: I have no firm numbers but I'd easily wager less than 1% of our ubuntu-server users can use it. It's wasted disk space, wasted memory, wasted startup time.

- The systemd service file went to great lengths to try to keep it running only where it might be useful, and prevent problems exactly like this one, but the systemd service language can't select for the things that actually matter: (a) does the kernel support the necessary interfaces (b) does the running system have hardware that can benefit from multipath.

- Perhaps an unconfigured or default configured daemon shouldn't fall over violently when there's nothing to actually multipath.

Linode users can add multipath=off to their kernel command line to instruct the systemd service to not try.
Linode users can mask multipathd.service.
Linode can add multipath=off to their default kernel command line.
Linode can mask multipathd.service.
Linode can add a policy-rc.d file to disable this service in their images. (I assume. I haven't tested that this ancient thing still works in a systemd world.)

Users stuck with this can probably use:
sudo dpkg --configure -a
sudo apt install -f

to try to unwedge apt after taking one of the above steps to disable the service.

Thanks