Comment 25 for bug 2009141

I tried to re-create this (or at least a situation that is similar) on our system, but I have to admit that I do not have the exact same hardware.
But I have a PR/SM system (not a DPM box) with FICON Express 16S (no 32s, but the driver is the same for both) and a DS8000 disk storage sub-system. I tried that on a z/VM guest that has one 64Gbit LUN attached via two HBAs each with two paths. (DASD ECKD devices were also available, but not used at all.)
With that I could successfully complete an Ubuntu Server 22.04.2 installation.
Please see the attached doc for the relevant storage related installer screens and at the end the lszdev output from the installer shell.

Unfortunately I don't have an XIV storage system (since I know that it behaves slightly different compared to a DS8k).

And you already retried on 22.04.2 with the same result you've reported.

And you did a (standard) interactive install (and no 'autoinstall'), right?

May I also ask if your system a DPM system?
And if you, could you please check if there is autoconf data set, like 'lszdev --auto-conf'?

Then I faced a special situation where a disk was previously used and had existing LVM config on it that the installer tries to read, but struggled with it - or where a very old LVM existed that had (meanwhile) incompatible meta data.
To rule out any issues like this I also want to recommend to try manually wiping out the disk, like:
Start the installer (which fortunately is a Ubuntu live system), enable the FCP LUN (either in the UI or in an installer shell, which can be reached via the help menu or Control-Z, respectively 'F2') and wipe the disks like:
# ls -la /dev/mapper/
control mpatha mpatha-part1
# wipefs -a -f /dev/mapper/mpatha-part1
# wipefs -a -f /dev/mapper/mpatha
( # or go via the scsi device:
# wipefs -a -f /dev/sda
# wipefs -a -f /dev/sda1 )
Afterwards it's needed to restart the installer from scratch (Load task).