Add support to /dev/disk/by-path device reference

[fgiudici]

When using the /dev/disk/by-path symlinks device reference, the partition names there get a "-part${NUM}" suffix.
Same for the /dev/disk/by-id symlinks.

Fixes: rancher/elemental#1140

[davidcassany]

I am not sure about this approach, at least this is not what I imagined.

/dev/disk/by-path/pci-0000:0a:00.0-nvme-1 is a symlink to an actual device under /dev. I was thinking on simply resolving such a symlink. So in a KVM env this could be resolved to something like /dev/vda and, from there, track partitions as /dev/vda1, etc.

I imagined adding something like (could be added in install action constructor)

spec.Target, _ = utils.ResolveLink(cfg.Fs, spec.Target, "/", constants.MaxLinkDepth)

to actually prevent the use of the symlinks when manipulating devices. This would prevent having to code additional name cases and also not relay on udev daemon creating the links and directly use the device named by the kernel. I'd say the less we have to manipulate the name the better. No strong opinion though.

Thoughts about this?

[fgiudici]

I am not sure about this approach, at least this is not what I imagined.

/dev/disk/by-path/pci-0000:0a:00.0-nvme-1 is a symlink to an actual device under /dev. I was thinking on simply resolving such a symlink. So in a KVM env this could be resolved to something like /dev/vda and, from there, track partitions as /dev/vda1, etc.

I imagined adding something like (could be added in install action constructor)

spec.Target, _ = utils.ResolveLink(cfg.Fs, spec.Target, "/", constants.MaxLinkDepth)

to actually prevent the use of the symlinks when manipulating devices. This would prevent having to code additional name cases and also not relay on udev daemon creating the links and directly use the device named by the kernel. I'd say the less we have to manipulate the name the better. No strong opinion though.

Thoughts about this?

Makes sense, resolving the symlink is a better option.

[davidcassany]

LGTM 👍