Fix disks order by display string if the size are the same

[KaiChuan-Hsieh]

When the platform has multiple disks in the same type and size, the order is not fixed. It leads the user format unexpected disk without caution.

The display string contains serial for nvme and unique ID for other type. Fix the order by display string if the type and size are the same.

https://bugs.launchpad.net/somerville/+bug/2047010

[KaiChuan-Hsieh]

@CragW

Hello,

I didn't see your comment. Could you help to review it?

[CragW]

@CragW

Hello,

I didn't see your comment. Could you help to review it?

Here you go the link to discussion in launchpad:
https://bugs.launchpad.net/somerville/+bug/2047010/comments/4

[KaiChuan-Hsieh]

Here is the debug output for different boot on the same machine. you can see that order and index is changed.

debug-2.log
debug-1.log

[CragW]

Here is the debug output for different boot on the same machine. you can see that order and index is changed.

It's weird that /dev/nvme0n1 device is being assigned to different disks at runtime, the indexing should be fixed in BIOS.

debug-1: /dev/nvme0n1 = PC SN810 NVMe WDC 512GB 23092V800032
debug-2: /dev/nvme0n1 = PC SN810 NVMe WDC 512GB 23092V800479

Would you please check /sys/class/nvme/nvme0/serial if they are matched between kernel probed one and dell-recovery? And nvme0 does change from time to time in the kernel space?

If the system kernel is offering unfixed number for disk 0 then this issue may impact factory install too.

[KaiChuan-Hsieh]

Would you please check /sys/class/nvme/nvme0/serial if they are matched between kernel probed one and dell-recovery? And nvme0 does change from time to time in the kernel space?

Yes, the userspace reflect sysfs node /sys/class/nvme/nvme0/serial correctly, and the order was changed from time to time.

[CragW]

Yes, the userspace reflect sysfs node /sys/class/nvme/nvme0/serial correctly, and the order was changed from time to time.

In this case, the target disk for OS installation would be unpredicable even a comparison is done with serial number.

I think a Warning Message like "Data on disk will be lost.." in association with the selected disk is the best effort we can do when a partition is seen on the block device.

[CragW]

User needs to determine which drive to be erased for OS installation.

With regarding to nvme index somewhat inconsistent to be default selected, I would recommend to compare the PCI address whereas disk type and disk size are both the same, so as to get the first drive selected.

@KaiChuan-Hsieh woud this work for you? 563222a on wip/cragw/sorting

[KaiChuan-Hsieh]

@KaiChuan-Hsieh woud this work for you? 563222a on wip/cragw/sorting

@CragW

I don't see device address in the disk object, I don't know how can you retrieve it.

[CragW]

I don't see device address in the disk object, I don't know how can you retrieve it.

It's essentially in the Symlinks in the Block object, do you have a similiar output like this?

$ udisksctl info -b /dev/nvme0n1
/org/freedesktop/UDisks2/block_devices/nvme0n1:
  org.freedesktop.UDisks2.Block:
    Device:                 /dev/nvme0n1
    Symlinks:              /dev/disk/by-diskseq/9
                                /dev/disk/by-id/nvme-PC_SN740_NVMe_WD_256GB_23070E803194
                                /dev/disk/by-id/nvme-PC_SN740_NVMe_WD_256GB_23070E803194_1
                                /dev/disk/by-id/nvme-eui.e8238fa6bf530001001b448b4edd46fd
                                /dev/disk/by-path/pci-0000:00:0e.0-pci-10000:e1:00.0-nvme-1

[KaiChuan-Hsieh]

what about the mdraid and mmcblk scenario?

[CragW]

what about the mdraid and mmcblk scenario?

I would expect a PCI slot for mmcblk too, so the pci address logic apply no problem. On the other hand, the mdraid is an abstracation layer from disks so the basic comparison logic takes in place, ultimately 1 returned to sorting.