Multipath in Ubuntu 20.04 not picking up additional drives?

Posted by danj2k@reddit | linuxadmin | View on Reddit | 16 comments

I've just added an additional SAS enclosure to our Ubuntu Linux 20.04 server that we use for our backup repository. Our existing enclosures are picked up by multipath and I assumed the new one would be too, but it isn't.

I've confirmed that both paths to the new enclosure are connected and active. I can see two entries for each of the new drives in lsblk. I've run various multipath commands including:

multipath on its own
multipath -F
multipath -ll
multipath -v2
multipath -v3

There are definitely two entries for the new enclosure in /sys/class/enclosure (I confirmed by checking the ids), so it's definitely connected in a multipath manner, but the new drives aren't being mapped to multipath devices.

I've tried restarting the server but that didn't help either.

Can anyone suggest what the problem might be?

[-]

Tall-Description8165@reddit

Can you check following details :

lsscsi -g >> List SCSI devices and their WWIDs

ls -l /dev/disk/by-id/ >> Check /dev/disk/by-id for WWID links

dmesg | grep sd >> Check kernel messages for the new drives

lspci -nnk | grep -iA3 sas >> Check which driver is handling the SAS HBA

sudo multipath -v3 >> Check multipath status

Updating SAS HBA/enclosure firmware or ensuring drives are presented with valid WWIDs should allow multipath to recognize them.

[-]

danj2k@reddit (OP)

Now that I know what I'm looking for, I found a Github issue that references my exact problem:

https://github.com/opensvc/multipath-tools/issues/56

Unfortunately even if I upgraded to Ubuntu 24.04 LTS, that doesn't appear to have a multipath-tools package this new, how can I get the newest multipath-tools onto my system?

[-]

Tall-Description8165@reddit

Please try enable proposed repo:

#sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu/ noble-proposed main restricted universe multiverse"

#sudo apt update

Install multipath-tools: #sudo apt install multipath-tools

Optional (boot support): #sudo apt install multipath-tools-boot

Disable Proposed repo (after install):

#sudo add-apt-repository -r "deb http://archive.ubuntu.com/ubuntu/ noble-proposed main restricted universe multiverse"

#sudo apt update

[-]

lathiat@reddit

This won’t help. There is no proposed fix for this issue. There is a package in proposed but it only fixes this different bug:

https://bugs.launchpad.net/bugs/2116901

[-]

danj2k@reddit (OP)

I have now tried building multipath-tools from source but while multipath can now see the drives, device maps are not being created, see my edits in the OP for full details.

[-]

lathiat@reddit

Someone would need to backport this fix to older Ubuntu releases. This is called a Stable Release Update.

As you note seems it was fixed in multipath-tools 0.9.5 but even 24.04 has only 0.9.4

It’s not possible to just install a newer version on 22.04/24.04. You need to either upgrade to the non LTS Plucky 25.04 or somehow get the 22.04/24.04 version fixed.

Someone from the community could open a bug on launchpad and propose a fix but the process is not trivial: https://documentation.ubuntu.com/sru/en/latest/howto/standard/

Disclaimer: I work for Canonical/Ubuntu. But you could also request this done if you had paid Ubuntu Pro + Support: https://ubuntu.com/pro

[-]

danj2k@reddit (OP)

Tried building from source, which sort of half worked but did not install its required libraries in the correct places. Multipath does see more info about the drives now but still no new entries in dev mapper

[-]

natebc@reddit

Your "Edit 2" question tells the tail i believe. If multipathd can only see the size and can't otherwise tell these are 2 paths to the same disks. Basically it doesn't have enough info to merge/match on with the path grouping policy.

[-]

Intergalactic_Ass@reddit

Seconded. I don't even know how that would happen but you'd have to classify the devices on something other than the vendor sense data.

OP, maybe you could configure them based on "product" if that's more uniform? I'm overall more concerned with how the hell this could happen though.

[-]

danj2k@reddit (OP)

It does seem likely that additional configuration will be needed in multipath.conf to get it to recognise these drives.

Here's what I tried initially:

devices {
  device {
    vendor                    "        "
    product                   "OOS20000G       "
    path_grouping_policy      multibus
    path_checker              tur
  }
}

Thinking about it I guess I need a different path_checker? Or to specify some custom command that will allow multipath to get the path information?

[-]

Intergalactic_Ass@reddit

What state are the paths in now? multipath -ll

path_checker determines the current state of the path (active/failed). I thought you were having grouping issues.

[-]

danj2k@reddit (OP)

Now that I know what I'm looking for, I found a Github issue that references my exact problem:

https://github.com/opensvc/multipath-tools/issues/56

Unfortunately even if I upgraded to Ubuntu 24.04 LTS, that doesn't appear to have a multipath-tools package this new, how can I get the newest multipath-tools onto my system?

[-]

Einaiden@reddit

Did you add the new drives to wwids? You need to do a multipath -a /dev/sdXY once to add the drive.

[-]

danj2k@reddit (OP)

That gives me a "can't store path info" error.

[-]

Einaiden@reddit

Is there a wwids file in /etc/multipath ? I think there is a multipath option to generate a new one if not.

Another alternative is that the paths are hardcoded in /etc/multipath/multipathd.conf

[-]

danj2k@reddit (OP)

Yes, /etc/multipath/wwids exists. The paths are not hardcoded in the multipath.conf. Though now I do think that some additional configuration will need adding to multipath.conf to get it to recognise this drive type.