[15:27] <zph1nx> is there a way to have the storage part pick the first biggest possible disk as part of the path: option when partititioning? trying to set up an automated ubuntu installation, which has the partition path set to /dev/sda, is there anyway to "wildcard" this?
[15:32] <zph1nx> is there a catch all for disk path under the storage key?
[15:36] <zph1nx> https://pastebin.com/eBAZLuRb is the user-data
[15:40] <dbungert> zph1nx: I think you want `match: {size: largest}` - https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html#disk-selection-extensions - this is more autoinstall then cloud-init though, we should move to #ubuntu-server if there is more to discuss
[15:56] <zph1nx> dbungert: im there, the problem here if you've noticed my user-data is that i have a very specific storage layout. and the problem atm is that autoinstall is bugging out on me as soon as /dev/sda is not a valid path
[15:58] <zph1nx> my layout dont really follow the preordained simple gpt -> lvm/direct layouts
[15:59] <dbungert> right, so the idea is that you remove the `path` declaration from the `type: disk` object and use the `match` instead
[15:59] <zph1nx> to * ?
[16:00] <dbungert> { ptable: gpt, match: {size: largest}, wipe: superblock, preserve: false, name: '', grub_device: false, type: disk, id: disk-sda }
[16:01] <zph1nx> so the logic would be that path would get changed to match: {size: largest}
[16:02] <dbungert> right
[16:02] <zph1nx> and type_ disk, id: largest would be the proper naming also
[16:04] <dbungert> the value of id is arbitrary, just needs to be consistent with the other objects referring to it.
[16:09] <zph1nx> so the id can be anything
[16:09] <zph1nx> as long as the other partitions reference it carving in lvms?