Comment 2 for bug 1830913

Hmm, indeed. Looks like with commit 35fd01f05ca2932a0174c8f7c35cb7e8625c58d5 the order was changed and my older comment in the other bug is no longer valid (sorry about that):

- byid_keys = ['ID_SERIAL', 'ID_WWN_WITH_EXTENSION']
+ byid_keys = ['ID_WWN_WITH_EXTENSION', 'ID_WWN',
+ 'ID_SERIAL', 'ID_SERIAL_SHORT']

cat /etc/udev/rules.d/nvme0n1-renamed.rules
# Written by curtin
SUBSYSTEM=="block", ACTION=="add|change", ENV{DEVTYPE}=="disk", ENV{ID_WWN}=="nvme.8086-6e766d656330-51454d55204e564d65204374726c-00000001", ENV{ID_SERIAL}=="QEMU NVMe Ctrl_nvmec0", ENV{ID_SERIAL_SHORT}=="nvmec0", SYMLINK+="disk/by-dname/nvme0n1-renamed"

udevadm info -q all -n /dev/nvme0n1

https://paste.ubuntu.com/p/x6x2vRJXJ2/

E: ID_SERIAL=QEMU NVMe Ctrl_nvmec1
E: ID_SERIAL_SHORT=nvmec1
E: ID_WWN=nvme.8086-6e766d656331-51454d55204e564d65204374726c-00000001

> Is this related at all to the request?

Yes, I think this may be the only thing for multi-path then: when we are matching a device against a set of parameters in a uevent, we currently have a requirement for ID_WWN, ID_SERIAL and ID_SERIAL_SHORT to match. The latter two seem to contain controller-related information while in the multi-path case accessing a namespace is possible through any controller.

I will ask for a full `udevadm info -q all -n /dev/nvme0n1` output tomorrow so that we can see which values are present there for a namespace in the multipath case.