10.10.9 aborts in presence of a backup whose rootfs is on a "missing" disk

[ydirson]

My recently-merged "tui: show the disk on which an existing installation or backup is found" patch reveals an old issue.

In a nested BIOS install a backup detected as <XenServerBackup: XCP-ng 8.3 (8.3.0-cloud) on /dev/sda2>, where the PRIMARY_DISK is /dev/disk/by-id/nvme-QEMU_NVMe_Ctrl_nvme0 (denoting that backup was originally installed as UEFI), is presented to the user as a valid choice to restore from.

However, since 10.10.9 we now display more detailed entries, and this causes a exception, as:

• getDiskDeviceSize("/dev/disk/by-id/nvme-QEMU_NVMe_Ctrl_nvme0") returns None because of a missing else: branch (dev = "disk!by-id!nvme-QEMU_NVMe_Ctrl_nvme0" founds nothing matching /sys/block/%s/device/block/size or /sys/block/%s/size)
• getExtendedDiskInfo() attempts to divide None / 2048, which causes the installer to abort

No such problem when booting the installer from UEFI, the backup entry succeeds in getting formatted.

The disk!by-id!nvme-QEMU_NVMe_Ctrl_nvme0 string, where in UEFI boot /sys/block/ contains nvme0n1 makes me suspecting we're trying to find a non-existent device, do not catch the failure to get its realpath, and go on using the bad device path.

This issue is linked to #11, in that a UEFI backup should be considered invalid on a BIOS install, and not proposed.
Note that in theory any PRIMARY_DISK pointing to a "missing disk" would lead to this, this could e.g. also happen if in a future platform udev rules change the /disk/by-id/ link.