Strange new error: Failed to start Device-Mapper Multipath Device Controller.

Hi,
I'm not exactly sure what this is, but here is an explanation of what it is. It doesn't sound like you'll need it on a virtual machine, from what little I read, especially if you're using a basic setup. If everything is working normally, you could probably uninstall the multipath-tools and multipath-tools-boot packages without any problems. If any package you have on the system depends on those packages for some reason, you'll have to check and see if you need those dependencies, but apt should warn you of this.

Good luck.

Blake

I can't figure out why all of a sudden I'm throwing this error. Beyond standard apt update / upgrade I've made no changes.

If you reboot from the Linode manager is there any way to see he process? Perhaps that will tell me something?

You'll need to reboot from Lish or Glish to see the full boot process, you won't see anything if you reboot from the cloud manager without either Lish or Glish open on your Linode.

The Linux boot log is located in /var/log/boot.log. You can view it with less/more once the system is running.

-- sw

Same error on Ubuntu 22.04.1 LTS.

multipathd.service: Failed with result 'exit-code'.
Failed to start Device-Mapper Multipath Device Controller.

I have the same issue on Ubuntu 20.04.5 LTS.
I even tried setting up an Ubuntu Pro account, to see if those repos had a never version of the package to fix it, but alas that was not the case.

Maybe it's related to the custom kernel Linode Ubuntu servers run (just guessing here), as I recall that causing some hiccups for me a couple of years ago. Back then it was resolved in some update in a couple of days, and a simple apt upgrade fixed it for me then (as the new update became available).

Regarding the package itself, it cannot be safely removed as ubuntu-server-* is depending on it. (You'd likely uninstall most of your server that way, don't try it without a fresh backup)

Regarding the package itself, it cannot be safely removed as ubuntu-server-* is depending on it.

You can tell systemd to not start the service at boot time:

sudo systemctl disable multipathd.service

-- sw

Same issue here on two different Ubuntu 20.04 instances that I just tried to run apt update/upgrade on. The error occurs during apt upgrade, at this step:

Setting up multipath-tools (0.8.3-1ubuntu2.1)

I removed the multipath-tools program.

I tried apt update this afternoon and sure enough there were a bunch of new updates for me. I ran the apt upgrade and it did not try to run the multipath-tools program like before so maybe I'm done with that.

I still get these ERROR/WARNINGS:

Setting up linux-firmware (1.187.35) …
update-initramfs: Generating /boot/initrd.img-5.4.0-132-generic
cryptsetup: ERROR: Couldn't resolve device /dev/root
cryptsetup: WARNING: Couldn't determine root device
update-initramfs: Generating /boot/initrd.img-5.4.0-131-generic
cryptsetup: ERROR: Couldn't resolve device /dev/root
cryptsetup: WARNING: Couldn't determine root device

… but it just pauses the process for a short while.

A 9 year old post say that I should run:

    sudo apt-get remove cryptsetup
    # it's better to update and reinstall GRUB before rebooting
    sudo update-grub
    sudo grub-install /dev/sda
    sudo reboot

But I'm afraid I might hose the entire system by messing with the boot loader.

Will I?

(I've never rebooted from the terminal? How will I know when it is running again? I just keep trying to connect via SSH?)

(I've never rebooted from the terminal? How will I know when it is running again? I just keep trying to connect via SSH?)

sudo reboot

while logged to a terminal session (either ssh or at the lish console) is a "reboot from the terminal".

If you do this from the lish console, you can watch the boot process. when you see the login: prompt, the system is ready.

I have a couple of systems here at home that don't have a console. I can only log in to them with ssh. Here's what I usually do (hopefully you can follow what's going on here):

stevewi@barney:~ $ sudo reboot
Password:
Connection to barney closed by remote host.
Connection to barney closed.
stevewi:~ $ ping barney
PING barney (<ip redacted>): 56 data bytes
64 bytes from <ip redacted>: icmp_seq=0 ttl=64 time=2.867 ms
64 bytes from <ip redacted>: icmp_seq=1 ttl=64 time=12.134 ms
64 bytes from <ip redacted>: icmp_seq=2 ttl=64 time=2.572 ms
...
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
...
64 bytes from <ip redacted>: icmp_seq=4 ttl=64 time=92.671 ms
64 bytes from <ip redacted>: icmp_seq=5 ttl=64 time=1.869 ms
64 bytes from <ip redacted>: icmp_seq=6 ttl=64 time=8.362 ms
64 bytes from <ip redacted>: icmp_seq=7 ttl=64 time=8.694 ms
...
^C
--- barney ping statistics ---
...
stevewi:~ $ ssh barney
Last login: Tue Nov 29 15:52:58 2022 from <ip redacted>
...
stevewi@barney:~

-- sw

Steve: Thanks for the answer about the reboot.

What about doing this:

    sudo apt-get remove cryptsetup
    # it's better to update and reinstall GRUB before rebooting
    sudo update-grub
    sudo grub-install /dev/sda
    sudo reboot

Will I hose the system?

I checked with lsblk which shows:

sda 8:0 0 159.5G 0 disk /
sdb 8:16 0 512M 0 disk [SWAP]

so \dev\sda is the correct operand for the "grup-install", right? I learned long ago that if you mess with the bootloader you are playing with fire… at least it was with LILO on Slackware!)

@acanton77 a quick FYI: reboot actually shuts down the server on Linode if you're using their Lassie watchdog. Then Lassie will notice and boot the system for you. It usually takes around a minute. So you do get a reboot, it's just slower than you might expect due to this behavior.

You'll also get a notification mail about Lassie starting your server (this one might be configurable)

As for messing with your bootloader I have the same experience as you, (burnt my fingers on it before) so I can't really tell you whether it's safe to attempt removing cryptsetup.
That being said I am curious how you got rid of multipath-tools - didn't apt remove tell you that ubuntu-server-* would be removed as well?

didn't apt remove tell you that ubuntu-server-* would be removed as well?

No, I don't believe so. If it had I for sure would not have continued.

What are the ubuntu-server packages?

What are the ubuntu-server packages?

They're sort of all the basic stuff you need to make a running server: kernel, networking infrastructure, etc.

-- sw

Any news from Linode support on this? The problem still exists for all of my Ubuntu 20.04 servers.

Any news from Linode support on this?

No, but then again I didn't open a support ticket on it. It is not that important since I'm going to dump this Linode AFTER I spin up a new one that will be dedicated and have the new Ubuntu 22.04 LTS.

Update: I took the plunge and apt purged multipath-tools from my linode. Turns out it survived just fine, despite it also removing the ubuntu-server package.

I'm still not sure what's in that package, but it was very small, so probably just some utility tools.

Regardless my server is running fine still and all services it serves are working :-)

Hello - One solution is to change your Linode's kernel to "Grub2".

Newly deployed Linodes currently deploy with Grub 2, but I changed the kernel on an Ubuntu 20.04 Linode to Latest 64 bit (6.0.2-x86_64-linode157) and reproduced the same errors. I didn't have any issues when using Grub 2.

I can confirm that switching to the GRUB 2 kernel fixed my issue.

And what is the command for that? I have been having this issue with no fix.
The sudo apt-get install linux-image-6.0.2-x86_64-linode157
Gives me
```

E: Unable to locate package linux-image-6.0.2-x86_64-linode157

E: Couldn't find any package by glob 'linux-image-6.0.2-x86_64-linode157'

E: Couldn't find any package by regex 'linux-image-6.0.2-x86_64-linode157

'```

I suspect my respiratory is at blame. But I don't want to touch it.

Thank you.

A simple sudo apt remove multipath-tools and sudo apt remove multipath-tools-boot did it for me. This was answered earlier, and I missed it. I hope this helps someone.

More possible details from my friend chat.openai.com.

It looks like you were having an issue with the multipathd service, which is responsible for managing the Device-Mapper Multipath Device Controller. This service failed to start because the necessary kernel modules, dm-multipath, scsi_dh_alua, scsi_dh_emc, and scsi_dh_rdac, were not found.

You tried to install these modules using apt-get install, but the package manager was unable to locate them. It's possible that these modules are not available for your kernel version or that they are not available in the package repository that you are using.

To resolve the issue, you removed the ipath-tools and ipath-tools-boot packages, which seems to have resolved the issue. If you still need the multipath functionality, you may need to find an alternative solution, such as building and installing the necessary kernel modules from source. Alternatively, you may be able to use a different kernel that includes the necessary modules.

I also started having this issue after updating multipath-tools back on November 18. I tracked it down to the Linode latest 64-bit kernel missing certain modules, specifically ndb*. Blacklisting them in the multipath config didn't seem to help.

As others here have pointed out, multipath isn't really necessary for these virtual servers in most use cases. I was afraid to uninstall the package completely, though, as ubuntu-server was dependent upon it. It sounds like ubuntu-server is just a collection of handy packages and safe to remove, but I didn't want to take the chance.

I can confirm changing my Linode boot config to use the GRUB2 kernel on both of my Ubuntu 20.04.5 servers fixed the issue for me. Thanks for the suggestion! It might help Linode Support to bring this issue to their attention.

I submitted a bug report with Ubuntu regarding this. This appears to not be related to any specific update to multipath-tools, but would happen any time dpkg requested it to restart, as linode is missing the necessary kernel modules.

https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/2000186

(I had issues with accessing this community, so haven't been able to leave this comment until now. The ticket is now over a month old.)