I had the same issue with the 14 apr build. I did use the workaround in hyper-v, and that still works, however I couldn’t get it to install on my clean machine. I, too, don’t see the issue fixed.
> On Apr 15, 2023, at 2:15 AM, griffon <email address hidden> wrote:
>
> Hello All,
>
> Tried with daily build image from April 14, 2023...the problem seems to
> be back... installation failed + confirm that there is an issue if the
> installation succeeds; no mouse detected with the Virtual machine in
> Hyper-v so Ubuntu cannot be used... I have seen multiple workarounds...
> but they are just workarounds
>
> Till next time
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2015100
>
> Title:
> Disk lookup fails when WWN has vendor extension
>
> Status in curtin:
> Fix Committed
> Status in subiquity:
> Fix Committed
>
> Bug description:
> We got multiple private reports of failed installs where curtin logs
> show the following pattern:
>
> found candidate disks [set(), {'/dev/sda'}, {'/dev/sda'}]
> An error occured handling 'disk-sda': ValueError - Failed to find storage volume id='disk-sda' config: {'ptable': 'gpt', 'serial': '121212121212121212121212', 'wwn': '0x123456789abcdef0deadbeef', 'path': '/dev/sda', 'wipe': 'superblock-recursive', 'preserve': False, 'name': '', 'grub_device': False, 'type': 'disk', 'id': 'disk-sda'}
>
> When trying to look up the disk, the value of the wwn field (i.e.,
> 0x123456789abcdef0deadbeef here) is compared to the ID_WWN udev
> variable of available disks.
>
> However, the wwn variable is not always initialized from the ID_WWN
> variable. If present, the ID_WWN_WITH_EXTENSION variable takes
> precedence:
>
> source_keys = {
> 'wwn': ['ID_WWN_WITH_EXTENSION', 'ID_WWN'],
> 'serial': ['ID_SERIAL', 'ID_SERIAL_SHORT'],
> }
>
> Example
> -------
>
> "ID_WWN": '0x123456789abcdef0'
> "ID_WWN_VENDOR_EXTENSION": "0xdeadbeef",
> "ID_WWN_WITH_EXTENSION": '0x123456789abcdef0deadbeef'
>
> Since present, the wwn variable gets initialized from
> ID_WWN_WITH_EXTENSION.
>
> Later on, we compare the wwn variable with ID_WWN and the lookup
> fails.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/curtin/+bug/2015100/+subscriptions
>
I had the same issue with the 14 apr build. I did use the workaround in hyper-v, and that still works, however I couldn’t get it to install on my clean machine. I, too, don’t see the issue fixed.
> On Apr 15, 2023, at 2:15 AM, griffon <email address hidden> wrote: /bugs.launchpad .net/bugs/ 2015100 1212121212' , 'wwn': '0x123456789abc def0deadbeef' , 'path': '/dev/sda', 'wipe': 'superblock- recursive' , 'preserve': False, 'name': '', 'grub_device': False, 'type': 'disk', 'id': 'disk-sda'} ef0deadbeef here) is compared to the ID_WWN udev WITH_EXTENSION variable takes WITH_EXTENSION' , 'ID_WWN'], def0' VENDOR_ EXTENSION" : "0xdeadbeef", WITH_EXTENSION" : '0x123456789abc def0deadbeef' WITH_EXTENSION. /bugs.launchpad .net/curtin/ +bug/2015100/ +subscriptions
>
> Hello All,
>
> Tried with daily build image from April 14, 2023...the problem seems to
> be back... installation failed + confirm that there is an issue if the
> installation succeeds; no mouse detected with the Virtual machine in
> Hyper-v so Ubuntu cannot be used... I have seen multiple workarounds...
> but they are just workarounds
>
> Till next time
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> Disk lookup fails when WWN has vendor extension
>
> Status in curtin:
> Fix Committed
> Status in subiquity:
> Fix Committed
>
> Bug description:
> We got multiple private reports of failed installs where curtin logs
> show the following pattern:
>
> found candidate disks [set(), {'/dev/sda'}, {'/dev/sda'}]
> An error occured handling 'disk-sda': ValueError - Failed to find storage volume id='disk-sda' config: {'ptable': 'gpt', 'serial': '12121212121212
>
> When trying to look up the disk, the value of the wwn field (i.e.,
> 0x123456789abcd
> variable of available disks.
>
> However, the wwn variable is not always initialized from the ID_WWN
> variable. If present, the ID_WWN_
> precedence:
>
> source_keys = {
> 'wwn': ['ID_WWN_
> 'serial': ['ID_SERIAL', 'ID_SERIAL_SHORT'],
> }
>
> Example
> -------
>
> "ID_WWN": '0x123456789abc
> "ID_WWN_
> "ID_WWN_
>
> Since present, the wwn variable gets initialized from
> ID_WWN_
>
> Later on, we compare the wwn variable with ID_WWN and the lookup
> fails.
>
> To manage notifications about this bug go to:
> https:/
>