Disk lookup fails when WWN has vendor extension

Bug #2015100 reported by Olivier Gayot
56
This bug affects 5 people
Affects Status Importance Assigned to Milestone
curtin
Fix Committed
Undecided
Olivier Gayot
subiquity
Fix Released
Undecided
Olivier Gayot

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.

Related branches

Olivier Gayot (ogayot)
Changed in curtin:
assignee: nobody → Olivier Gayot (ogayot)
Changed in subiquity:
assignee: nobody → Olivier Gayot (ogayot)
Changed in curtin:
status: New → In Progress
Olivier Gayot (ogayot)
Changed in subiquity:
status: New → In Progress
Olivier Gayot (ogayot)
Changed in curtin:
status: In Progress → Fix Committed
Olivier Gayot (ogayot)
Changed in subiquity:
status: In Progress → Fix Committed
Revision history for this message
griffon (6-info-s) wrote :

Hello All,

We have downloaded the daily build image on April 05, 2023 and performed the installation on a Virtual machine hosted on Hyper-V server. The installation went through and we have now a successful installation process. We will also perform some tests on ESXI servers and assess that the problem is indeed fixed

If other people can test and confirm, would be nice

Thank you all for the quick action and providing the fix

Revision history for this message
Olivier Gayot (ogayot) wrote :

Hi griffon,

Thank you for going through a retest and providing us with the feedback.

Indeed, we'd be happy if other people can test and confirm, but this is already very good news!

Best regards,
Olivier

Revision history for this message
Manohar Amkem (manoharamkem) wrote : Re: [Bug 2015100] Re: Disk lookup fails when WWN has vendor extension

Hi Olivier,

Many thanks for your quick fix release. I have downloaded the latest daily
image and tried to install it in my Hyper-V. I was able to install it
successfully, however I am not able to access the Ubuntu desktop at all.
Ubuntu is not recognizing my mouse. Whatever the mouse pointer shown on the
desktop is not at all moving and my windows mouse pointer is not being
recognized. I have tried continuously without successfully moving my mouse
pointer. It's quite hard to explain, that's why I attached the picture.

I have been using Hyper-V for a very long time and at present I have Ubuntu
22.04 LTS since it was released running in Hyper-V. So I could say this is
an issue with Ubuntu 23.04 with Hyper-V.

Regards,
Manohar

On Wed, Apr 5, 2023 at 3:20 PM Olivier Gayot <email address hidden>
wrote:

> Hi griffon,
>
> Thank you for going through a retest and providing us with the feedback.
>
> Indeed, we'd be happy if other people can test and confirm, but this is
> already very good news!
>
> Best regards,
> Olivier
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (2014995).
> 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
>
>

--
Manohar

Revision history for this message
Kern Hardman (kernh4) wrote :
Download full text (5.2 KiB)

Hi Guys,

Thanks from me too on the quick fix for this!

I too, am now able to install 23.04 in a Hyper-V machine, however like Manohar, the background and sidebar appear and that's all that happens after I log in. The mouse fails to activate on the main screen, yet it was working on the login screen. I also have the same issue on a clean machine that has the WWN issue.

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Manohar Amkem
Sent: Wednesday, April 5, 2023 8:36 AM
To: <email address hidden>
Subject: Re: [Bug 2015100] Re: Disk lookup fails when WWN has vendor extension

Hi Olivier,

Many thanks for your quick fix release. I have downloaded the latest daily image and tried to install it in my Hyper-V. I was able to install it successfully, however I am not able to access the Ubuntu desktop at all.
Ubuntu is not recognizing my mouse. Whatever the mouse pointer shown on the desktop is not at all moving and my windows mouse pointer is not being recognized. I have tried continuously without successfully moving my mouse pointer. It's quite hard to explain, that's why I attached the picture.

I have been using Hyper-V for a very long time and at present I have Ubuntu
22.04 LTS since it was released running in Hyper-V. So I could say this is an issue with Ubuntu 23.04 with Hyper-V.

Regards,
Manohar

On Wed, Apr 5, 2023 at 3:20 PM Olivier Gayot <email address hidden>
wrote:

> Hi griffon,
>
> Thank you for going through a retest and providing us with the feedback.
>
> Indeed, we'd be happy if other people can test and confirm, but this
> is already very good news!
>
> Best regards,
> Olivier
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (2014995).
> 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...

Read more...

Revision history for this message
Kern Hardman (kernh4) wrote : 2015100@bugs.launchpad.net

Hi Guys,

Thanks from me too on the quick fix for this!

I too, am now able to install 23.04 in a Hyper-V machine, however like
Manohar, the background and sidebar appear and that's all that happens after
I log in. The mouse fails to activate on the main screen, yet it was working
on the login screen. I also have the same issue on a clean machine that has
the WWN issue.

Thanks,

.Kern

Revision history for this message
griffon (6-info-s) wrote :

Hello All,

I Can confirm that the installation process is successful now but indeed as other have mentioned there is a problem to access the Desktop interface just after login page. Random behavior... either no dockbar loading or dockbar loading but Mouse get stuck indeed... Not sure if this is related to the installation process fix provided or a more generic problem.

Thanks

Revision history for this message
Olivier Gayot (ogayot) wrote :

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

Revision history for this message
Kern Hardman (kernh4) wrote : RE: [Bug 2015100] Re: Disk lookup fails when WWN has vendor extension
Download full text (3.9 KiB)

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

Read more...

Revision history for this message
griffon (6-info-s) 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

Revision history for this message
Kern Hardman (kernh4) wrote :

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
>

Revision history for this message
Olivier Gayot (ogayot) wrote :

Hi,

For the GUI freezing issue after reboot and login, Kern opened a follow-on bug so I would like to continue the discussion there:

https://bugs.launchpad.net/subiquity/+bug/2015100

As far as installs failing with the build from April 14th, I just tested an install on hyper-v with the same build and it went through without issue. I suspect something was wrong with the archive but logs would be most welcome (/var/log/installer + /var/crash + journal if possible).

Best regards,
Olivier

Olivier Gayot (ogayot)
Changed in curtin:
status: Fix Committed → Fix Released
Changed in subiquity:
status: Fix Committed → Fix Released
Changed in curtin:
status: Fix Released → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.