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

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.

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

Possible duplicate LP: #1996006

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.

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

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