Installation of 24.04 on s390x crashes due to curtin not always being able to remove pre-existing disk layout

[Frank Heimes]

While trying autoinstall (and later with an interactive install) on a s390x z/VM guest (with an autoinstall config that is known as good), the installation ended in a crash and the following was taken from the console:

...
finish: subiquity/Drivers/_list_drivers
start: subiquity/Install/install/curtin_install/run_curtin_step/cmd-instal
l: curtin command install
start: subiquity/Install/install/curtin_install/run_curtin_step/cmd-inst
all/stage-partitioning: configuring storage
start: subiquity/Install/install/curtin_install/run_curtin_step/cmd-in
stall/stage-partitioning/builtin: running 'curtin block-meta simple'
start: subiquity/Install/install/curtin_install/run_curtin_step/cmd-
install/stage-partitioning/builtin/cmd-block-meta: curtin command block-meta
start: subiquity/Install/install/curtin_install/run_curtin_step/cm
d-install/stage-partitioning/builtin/cmd-block-meta/clear-holders: removing prev
ious storage devices
finish: subiquity/Install/install/curtin_install/run_curtin_step/c
md-install/stage-partitioning/builtin/cmd-block-meta/clear-holders: removing pre
vious storage devices
finish: subiquity/Install/install/curtin_install/run_curtin_step/cmd
-install/stage-partitioning/builtin/cmd-block-meta: curtin command block-meta
finish: subiquity/Install/install/curtin_install/run_curtin_step/cmd-i
nstall/stage-partitioning/builtin: running 'curtin block-meta simple'
finish: subiquity/Install/install/curtin_install/run_curtin_step/cmd-ins
tall/stage-partitioning: configuring storage
finish: subiquity/Install/install/curtin_install/run_curtin_step
finish: subiquity/Install/install/curtin_install
finish: subiquity/Install/install
start: subiquity/ErrorReporter/1709659117.832598448.install_fail/add_info

I was able to login (by hitting Enter), which allowed me to gather crash files and log - see attachment.

The noble image with timestamp March 5th was used (from current).

[Frank Heimes (fheimes)]

According to the crash file, looks like curtin failed to configure storage:
hence I marked curtin as affected.

[Frank Heimes (fheimes)]

This problem also happened now during an interactive installation (using image March 5th), see attachment for logs and crash file.

(Updating the bug title.)

[Frank Heimes (fheimes)]

Just tried an (interactive) installation on LPAR that that unfortunately crashed too (see attachment).

All my installations (with image March 5th) were done with DASD disks - will try another LPAR install with SCSI now.

Please notice that this problem was introduced recently, since installations have worked until (at least) the image from Feb 27th.

[Frank Heimes (fheimes)]

And btw. I always updated the installer.
"
Version 22.02.2+git2055.2fd9c685 of the installer is now available
  (22.02.2+git2051.d010f921 is currently running).
"
(if that makes a difference).

[Frank Heimes (fheimes)]

Hmm - NOT updating the installer allowed me to complete the LPAR install.
Trying this (interactive install w/o updating installer) now again on z/VM to double check ...

[Frank Heimes (fheimes)]

No, the installer version does not seem to matter much .

It's a problem that curtin runs into in case of deleting disks.

If I (low-level) format the disks prior to an installation, the installation succeeds.
(I remember a similar situation in the past ...)

Well, to me it seems to be a regression, since this worked before.

I'll do some more tests (e.g. using SCSI disks, and if autoinstall also succeeds in case the disks get wiped before installing.)

[Frank Heimes (fheimes)]

After disks got wiped once, I am able to repeatedly do successful installation on DASD disks (no matter if z/VM or LPAR and no matter if updated installer or default).

SCSI/FCP disks do not seem to be affected (install worked there all the time).

So the issue seem to occur if an old (former) disk layout got detected and got marked for deletion. In such a case curtin seem to fail (at least sometimes, at least about 5 times for me).

Notice that all these attempts where done while using "Custom disk layout", using 3 DASDs, whereas one was with 1.875G for /boot, the rest of this disk and all the space from the other two disks for a single big LVM that holds root.

The workaround is to get (somehow) the disks wiped out before, in case this happens.
So this is probably not critical, but nevertheless a bad user experience.

(I'm updating the bug title to reflect the latest results.)

[Frank Heimes (fheimes)]

This still happens with image '20240311', with autoinstall as well as with interactive installs.

(log and crash file attached)

[Dan Bungert (dbungert)]

the 12032024_auto logs are a duplicate of bug LP: #2056570, same for 12032024_interactive and 06032024_lpar.

The 06032024 log and 05032024 log are a duplicate of bug LP: #2016860.
Marking the overall bug as a duplicate of 2016860 because that matches the description.

> Please notice that this problem was introduced recently, since installations have worked until (at least) the image from Feb 27th.

Right, but LP: #2016860 was never an all-the-time thing which is part of why it's proving difficult to solve.

[Frank Heimes (fheimes)]

Yes, right.
(I think it's just probably best to have an eye of the logs that are attached to this bug (even is now marked as dup), since they are newer and closer to 24.04.)

[Frank Heimes (fheimes)]

Just fyi happened on the z15 (running in DPM mode) with NVMe disks as well.
So it's even more severe than I thought ...

[Frank Heimes (fheimes)]

Still fails with latest ISO 12032024 on z13 z/VM.