Addressing disk via values in /dev/disk/by-id fails.

[Peter Mattingly]

Hello,

Quoting the documentation [1]:

```
serial: <serial number>

In order to uniquely identify a disk on the system its serial number should be specified. This ensures that even if additional storage devices are added to the system during installation, or udev rules cause the path to a disk to change curtin will still be able to correctly identify the disk it should be operating on using /dev/disk/by-id.

This is the preferred way to identify a disk and should be used in all production environments as it is less likely to point to an incorrect device.
```

However, this approach did not work correctly when attempting to use either serial or path information from `/dev/disk/by-id`. What did work was addressing the disk through its device designation (i.e., /dev/sda). Then also, a serial number that did work appeared to be a part of the SCSI identification information. For example, if the SCSI identification information is:

`scsi-nnn`

Then a working "serial number" that could identify the disk in curtin would be: `nnn`. In addition, `wwn` identification numbers also did not work correctly to uniquely identify the disk. The full disk option:

```
- {ptable: gpt, wipe: superblock-recursive, preserve: false, grub_device: false, layout: false, PATH OR SERIAL, type: disk, id: disk-vgdata}
```

Curtin version being used is 22.1.

Relevant cloud configuration:

```
#cloud-config
# this creates a bios partition, /boot partition, and root(/) lvm volume
storage:
config:
- {ptable: gpt, wipe: superblock-recursive, preserve: false, grub_device: true, wwn: <Redacted>, type: disk, id: disk-sda}
- {type: partition, wipe: superblock-recursive, preserve: false, number: 1, device: disk-sda, flag: bios_grub, size: 1M, id: bios-grub}
- {type: partition, wipe: superblock, preserve: false, number: 2, device: disk-sda, flag: boot, size: 1G, id: sda-boot}
- {type: partition, wipe: superblock, preserve: false, number: 3, device: disk-sda, size: -1 , id: sda-lvm}
- {type: lvm_volgroup, name: vgsys, devices: [sda-lvm], id: vgsys}
- {type: lvm_partition, volgroup: vgsys, id: lvroot, name: lvroot, size: 10G}
- {type: lvm_partition, volgroup: vgsys, id: lvswap, name: lvswap, size: 1G}
- {type: lvm_partition, volgroup: vgsys, id: lvhome, name: lvhome, size: 1G}
- {type: lvm_partition, volgroup: vgsys, id: lvtmp, name: lvtmp, size: 4G}
- {type: lvm_partition, volgroup: vgsys, id: lvopt, name: lvopt, size: 10G}
- {type: lvm_partition, volgroup: vgsys, id: lvvar, name: lvvar, size: 10G}
- {type: format, fstype: ext4, volume: sda-boot, id: sda-boot-fs}
- {type: format, fstype: ext4, volume: lvroot, id: lv-root-fs}
- {type: format, fstype: swap, volume: lvswap, id: lv-swap-fs}
- {type: format, fstype: ext4, volume: lvhome, id: lv-home-fs}
- {type: format, fstype: ext4, volume: lvtmp, id: lv-tmp-fs}
- {type: format, fstype: ext4, volume: lvopt, id: lv-opt-fs}
- {type: format, fstype: ext4, volume: lvvar, id: lv-var-fs}
- {type: mount, path: /boot, id: m-boot, device: sda-boot-fs}
- {type: mount, path: /, id: m-root, device: lv-root-fs}
- {type: mount, path: '', id: m-swap, device: lv-swap-fs}
- {type: mount, path: /home, id: m-home, device: lv-home-fs}
- {type: mount, path: /tmp, id: m-tmp, device: lv-tmp-fs}
- {type: mount, path: /opt, id: m-opt, device: lv-opt-fs}
- {type: mount, path: /var, id: m-var, device: lv-var-fs}
```

Installation was done using the pxe-booted live server ISO for Ubuntu 22.04.3.

[1] https://curtin.readthedocs.io/en/latest/topics/storage.html#disk-command

[Ryan Stewart (stew3254)]

Here are the relevant logs for this issue.

[Dan Bungert (dbungert)]

Hi Ryan, thanks for the logs.

So the immediate problem in the logs is the following:

Running command ['lvcreate', 'vgsys', '--name', 'lvopt', '--zero=y', '--wipesignatures=y', '--yes', '--size', '10737418240.0B'] with allowed return codes [0] (capture=False)
  Volume group "vgsys" has insufficient free space (1279 extents): 2560 required.
An error occured handling 'lvopt': ProcessExecutionError - Unexpected error while running command.
Command: ['lvcreate', 'vgsys', '--name', 'lvopt', '--zero=y', '--wipesignatures=y', '--yes', '--size', '10737418240.0B']
Exit code: 5

So that looks solvable with configuration changes.

I'm going to move this bug to Triaged because I think there is enough info here to investigate the current behavior and look at fixes.