[Feature request] Support for UUID in addition to /dev device names

[Cavallo Federico]

Hi,

I am trying to automate partition to partition clone with a grub entry, using ocs-onthefly with fixed parameters.

I am facing the problem of block devices, on physically different drives, assigned random from boot to boot.

A solution I ask you to evaluate is to support also UUIDs to address partitions (I think PARTUUID could be suitable, because it should not change even after a partition to partition copy).

/dev devices could be specified using the (not common, but supported) following notation:

-f /dev/disk/by-partuuid/(source PARTUUID) -d /dev/disk/by-partuuid/(target PARTUUID)

in addition for example to the usual:

-f /dev/sda1 -d /dev/sdb1

Of course I also listen to suggestions to go around this problem. The best I was able to do is to create a few files containing the actual block device name, in the following way:

menuentry "Clone sda1 to sdb1" {
...
set source_UUID="dec660c1-788a-4125-b08a-f5c4b9c1f844"
...
ocs_prerun01="blkid | grep ${source_UUID} | cut -c1-9 > /tmp/source_DEV" \

but I am blocked at using the contents of file /tmp/source_DEV as ocs-onthefly parameter -f , and so on.

I am really interested in your thinking!

Thank you very much,
Cavallo Federico

[Steven Shiau]

Somehow we missed this request...
Definitely this can be done. However, UUID is only when the file system exists. PartUUID is only when partition exists. Hence it only works for partition to partition, not disk to disk.
We will think about implement this in the future for partition to partition cloning.

Steven

[Jeremy Boden]

This would be great to have - especially for disk -> disk and disk -> image.
Couldn't the disk be identified by by using the output of:-

ls -l /dev/disk/by-id

This lists the model number + serial number of each disk + all partitions, together with a section for "world wide name" - wwn. As a rather lengthy (but edited) example

ata-Samsung_SSD_870_QVO_1TB_S5SVNG0N955653H -> ../../sdb
ata-Samsung_SSD_870_QVO_1TB_S5SVNG0N955653H-part1 -> ../../sdb1
ata-Samsung_SSD_870_QVO_1TB_S5SVNG0N955653H-part2 -> ../../sdb2
ata-Samsung_SSD_870_QVO_1TB_S5SVNG0N955653H-part3 -> ../../sdb3
ata-Samsung_SSD_870_QVO_1TB_S5SVNG0N955653H-part4 -> ../../sdb4
ata-Samsung_SSD_870_QVO_1TB_S5SVNG0NB22319L -> ../../sda
ata-Samsung_SSD_870_QVO_1TB_S5SVNG0NB22319L-part4 -> ../../sda4
ata-Samsung_SSD_870_QVO_1TB_S5SVNG0NB22319L-part5 -> ../../sda5
nvme-256GB_PCS_PCIe_M.2_SSD_AA202011017000059045 -> ../../nvme0n1
nvme-256GB_PCS_PCIe_M.2_SSD_AA202011017000059045_1 -> ../../nvme0n1
nvme-256GB_PCS_PCIe_M.2_SSD_AA202011017000059045_1-part1 -> ../../nvme0n1p1
nvme-256GB_PCS_PCIe_M.2_SSD_AA202011017000059045_1-part2 -> ../../nvme0n1p2
nvme-256GB_PCS_PCIe_M.2_SSD_AA202011017000059045_1-part3 -> ../../nvme0n1p3
...

[Cavallo Federico]

Hi Steven,
Unfortunately I missed your answer too :-(
Yes, need this feature for already existing file systems and partitions.

Anyway I can tell you that the problem of randomly assigned block devices at startup, for me was solved a few months ago from release 3.2.1-18 and boot parameter "ocs_1_cpu_udev":

• Added a mechanism to mitigate the random order of block devices. It can be enabled by adding the boot parameter "ocs_1_cpu_udev", i.e., when udev is started in initramfs, only 1 CPU is online. After that, all CPUs will be enabled.

But I don't trust yet 100% this workaround so I put a pause in grub menu, so in case block devices are scrambled, user should check order and stop cloning (ctrl-c).

I think using PARTUUID should be 100% safe.

Thank you very much!
Cavallo Federico