systemd-remount-fs.service & multipathd.socket failing on clean install

[fliespl]

I have noticed it in other thread that it should be fixed, but that happens on clean install with WSL2 + Ubuntu 20.04.

systemd-remount-fs
Feb 14 19:38:24 flies-pc-wsl systemd-remount-fs[61]: mount: /: can't find LABEL=cloudimg-rootfs.

multipathd:
Feb 14 19:36:02 flies-pc-wsl systemd[1]: Condition check resulted in Device-Mapper Multipath Device Controller being skipped.

Any ideas how to "fix it" instead of simply masking and disabling those services?

[cerebrate]

On the former, that's because systemd-remount-fs is trying to remount the root partition to make sure that it has the options configured in /etc/fstab; and the Ubuntu default /etc/fstab assumes that the root partition is labeled "cloudimg-rootfs". This isn't the case under WSL (the root partition is one of its .vhdx files), so the remount fails. (This isn't strictly a problem with the service - you'd get the same error if you tried to remount / manually.)

There are two ways to solve this one: either find the device the root partition is mounted from (probably /dev/sdb, but check first), and label it appropriately:

sudo e2label /dev/sdb cloudimg-rootfs

or, if you're happy with the existing mount options for your root filesystem, simply delete the line for / from /etc/fstab entirely. WSL mounts it for you automatically and with reasonable options when starting up the distro, so unless you know that you need something different, there's not actually any point in having it there.

[cerebrate]

On the latter, I don't know a solution to make multipathd work, but what I do know is that multipathd is designed to let you combine multiple physical connections (on a SAN) into a single virtual device. Since WSL doesn't support arbitrary block devices at the moment, if it ever will, multipathd serves no purpose under WSL. That one, you might as well just disable.

[fliespl]

Thank you very much! All makes sense now :)

[gbraad]

This issue does not only affect Ubuntu, but also Fedora; on a basic setup the multipathd.service will not run. However, when the multi-user.target is used, this service will fail. There is no support for this.

It is best to use:

$ sudo systemctl mask multipathd.service

to prevent it from starting

[gbraad]

@cerebrate better to document this in a more generic way?

[cerebrate]

It's the sort of thing that should probably go on the repo wiki.

(As a side note, custom kernels with multipath support let this work fine, not that there's any particular point to compiling a custom kernel with multipath support under most circumstances.)