Installation crash if 'custom 'is selected in guided storage screen and having a LUN with a previous installation on it

Bug #1993633 reported by Frank Heimes
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
New
High
Skipper Bug Screeners
subiquity
New
High
Unassigned

Bug Description

While doing an interactive installation with the latest kinetic ISO image (on s390x, but I think it's not limited to this architecture) using a SCSI LUN as disk storage that has a previous installation on it, I'm facing the following crash, in case I select 'Custom storage layout' at the
'Guided storage configuration' screen.

The remote ssh installation session drops with the following output:

generating crash report
report saved to /var/crash/1666201519.789847612.ui.crash
Traceback (most recent call last):
  File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/client/controllers/filesystem.py", line 258, in _guided_choice
    self.ui.set_body(FilesystemView(self.model, self))
  File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/ui/views/filesystem/filesystem.py", line 476, in __init__
    self.refresh_model_inputs()
  File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/ui/views/filesystem/filesystem.py", line 522, in refresh_model_inputs
    self.avail_list.refresh_model_inputs()
  File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/ui/views/filesystem/filesystem.py", line 410, in refresh_model_inputs
    for obj, cells in summarize_device(device, filter):
  File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/ui/views/filesystem/helpers.py", line 34, in summarize_device
    anns = labels.annotations(device) + labels.usage_labels(device)
  File "/snap/subiquity/4005/usr/lib/python3.8/functools.py", line 875, in wrapper
    return dispatch(args[0].__class__)(*args, **kw)
  File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/common/filesystem/labels.py", line 96, in _annotations_vg
    member = next(iter(vg.devices))
StopIteration

 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/client/client.py", line 407, in run
     super().run()
   File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquitycore/tui.py", line 381, in run
     super().run()
   File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquitycore/core.py", line 135, in run
     raise exc
 RuntimeError: coroutine raised StopIteration

also:

 2022-10-19 17:45:19,787 DEBUG subiquity.models.filesystem:1271 exclusions set()
 2022-10-19 17:45:19,789 DEBUG subiquity.common.errorreport:384 generating crash report
 2022-10-19 17:45:19,794 INFO subiquity.common.errorreport:406 saving crash report 'Installer UI crashed with RuntimeError' to /var/crash/1666201519.789847612.ui.crash
 2022-10-19 17:45:19,794 INFO subiquity/ErrorReporter/1666201519.789847612.ui/add_info:107 start:
InstallerLogInfo:

The full /var/log and /var/crash content from two different system are attached.

This is a spin-off from bug LP#1993257.

After an initial chat with dbungert, it's believed that wipefs doesn't do a proper job and leaves other components in unspecific states.

Reconnecting to the installer and trying to 'Continue' does not work.
But manually wiping the disks on the LUN with for example:
wipefs -a -f /dev/sda1
wipefs -a -f /dev/sda2
wipefs -a -f /dev/sda
AND then restarting the installation from scratch works
and will finally show an empty disk at the 'Custom storage layout'.

Revision history for this message
Frank Heimes (fheimes) wrote :
Revision history for this message
Frank Heimes (fheimes) wrote :
Revision history for this message
Dan Bungert (dbungert) wrote :

Thanks for splitting out this bug, Frank.
I think the key to this is the exact steps used to wipe the devices - I assume everything is fine if you don't do that?

Would you spend a little time retracing your steps on what you did to wipe the devices? I would like to record that information in this bug.

To get the devices into this state, you may need to first perform a good install then do the steps we're questioning.

Revision history for this message
Frank Heimes (fheimes) wrote (last edit ):
Download full text (3.2 KiB)

While doing an interactive installation with the latest kinetic ISO image (on s390x, but I think it's not limited to this architecture) using a SCSI LUN as disk storage that has a previous installation on it, I'm facing the following crash, in case I select 'Custom storage layout' at the 'Guided storage configuration' screen.

The remote ssh installation session drops with the following output:

generating crash report
report saved to /var/crash/1666201519.789847612.ui.crash
Traceback (most recent call last):
  File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/client/controllers/filesystem.py", line 258, in _guided_choice
    self.ui.set_body(FilesystemView(self.model, self))
  File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/ui/views/filesystem/filesystem.py", line 476, in __init__
    self.refresh_model_inputs()
  File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/ui/views/filesystem/filesystem.py", line 522, in refresh_model_inputs
    self.avail_list.refresh_model_inputs()
  File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/ui/views/filesystem/filesystem.py", line 410, in refresh_model_inputs
    for obj, cells in summarize_device(device, filter):
  File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/ui/views/filesystem/helpers.py", line 34, in summarize_device
    anns = labels.annotations(device) + labels.usage_labels(device)
  File "/snap/subiquity/4005/usr/lib/python3.8/functools.py", line 875, in wrapper
    return dispatch(args[0].__class__)(*args, **kw)
  File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/common/filesystem/labels.py", line 96, in _annotations_vg
    member = next(iter(vg.devices))
StopIteration

 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquity/client/client.py", line 407, in run
     super().run()
   File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquitycore/tui.py", line 381, in run
     super().run()
   File "/snap/subiquity/4005/lib/python3.8/site-packages/subiquitycore/core.py", line 135, in run
     raise exc
 RuntimeError: coroutine raised StopIteration

also:

 2022-10-19 17:45:19,787 DEBUG subiquity.models.filesystem:1271 exclusions set()
 2022-10-19 17:45:19,789 DEBUG subiquity.common.errorreport:384 generating crash report
 2022-10-19 17:45:19,794 INFO subiquity.common.errorreport:406 saving crash report 'Installer UI crashed with RuntimeError' to /var/crash/1666201519.789847612.ui.crash
 2022-10-19 17:45:19,794 INFO subiquity/ErrorReporter/1666201519.789847612.ui/add_info:107 start:
InstallerLogInfo:

The full /var/log and /var/crash content of two different system are attached.

This is a spin-off from bug LP#1993257.

After an initial chat with dbungert, it's believed that wipefs doesn't do a proper job and leaves other components in unspecific states.

Reconnecting to the installer and trying to 'Continue' does _not_ work.
But manually wiping the disks of the LUN with for example:
wipefs -a -f /dev/sda1
wipefs -a -f /dev/sda2
wipefs -a -f /dev/sda
AND then restarting the installatio...

Read more...

Dan Bungert (dbungert)
Changed in subiquity:
importance: Undecided → High
tags: added: foundations-todo
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
importance: Undecided → High
Revision history for this message
Dan Bungert (dbungert) wrote :

Possible duplicate LP: #1996006

Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
tags: added: s390x
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

So this is a bit strange. It seems that probert is failing to detect the pre-existing volume group correctly, and in fact is concluding it has no devices:

        "volume_groups": {
            "ubuntu-vg": {
                "name": "ubuntu-vg",
                "devices": [],
                "size": "0B"
            }
        }

Besides being generally impossible for a few reasons, it's clear from looking at udev data that /dev/sda2 is actually the pv for the vg. It's not at all obvious from the logs why this is being missed though. If you can still reproduce this, could you drop to a shell and run

$ vgs --reportformat=json --units=B -o vg_name,pv_name,pv_uuid,vg_size

Although it's obviously a pretty bogus situation, I guess we should not have the UI fall over in quite such a heap when this happens.

Revision history for this message
Frank Heimes (fheimes) wrote :

Same with my first lunar install (I guess it has still the same installer anyway).

Revision history for this message
Frank Heimes (fheimes) wrote :

I just faced an interesting situation:

I did an autoinstall (of latest lunar) and it worked,
but a manual install did not worked - with the same image, same system.

Then I remembered that I delete the partitions in the autoinstall and recreate the partitions (well I reuse an autogenerated one).

So this seems to be sufficient to get the installation going (so a manual rough wipefs might not be needed).

Revision history for this message
Dan Bungert (dbungert) wrote :
Revision history for this message
Dan Bungert (dbungert) wrote :
Dan Bungert (dbungert)
tags: added: fr-3405
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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