Hi Oliver,

I did edit the grub file and was able to log on and the graphical interface now loads, however, I don't believe this is the 'fix' for the issue. The 'nomodeset' parameter is usually used when there is no graphics driver for the particular card/machine. That being... you are using an old machine that has no current driver to support it.

I personally, only see this as a work-around to be able to test the base of Lunar Lobster, and not really use it to its full potential. With that, I am still thinking an issue exists, and that issue is that with the new loader (as compared to the 22.nn branch), that machines that have the WWN issue can't have their screens set to anything other than default, because the new loader doesn't look for or see the graphics driver.  I see this on my machine where I'm running Hyper-V and also on m machine that has the WWN issue and is a clean machine where I'm wiping the disk and only installing 23.04.

I'd like to know your take on this and if a new bug should be issued for this?

Thanks,
...Kern



-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Olivier Gayot
Sent: Tuesday, April 11, 2023 1:14 AM
To: <email address hidden>
Subject: [Bug 2015100] Re: Disk lookup fails when WWN has vendor extension

Hi folks,

I went ahead and proceeded with an install under Hyper-V.

The installation went fine and I hit the same GUI freezes issues after logging in.

This is not ideal, but what worked for me is to pass the `nomodeset` keyword to the kernel CLI.

1. Perform the install
2. Boot the installed system
3. When prompted to log in on the GUI, ignore and hit ctrl-alt-f2 to switch to a virtual TTY 4. Login with your username and password 5. Edit /etc/default/grub as root and replace this line:

- GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

with this line:

+ GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

6. Run `sudo update-grub2`
7. Run `sudo reboot`

At this point, I don't consider this an installer issue anymore so I will mark this bug fix committed. If some of you continue to experience issues GUI freezes, I would recommend opening a new bug report against linux (Ubuntu). https://launchpad.net/ubuntu/+source/linux Please mention that you're using hyper-v and if you are using `nomodeset` or not.

Thanks

--
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