tries to use sfdisk on dasd disk and dies

[Christian Ehrhardt ]

Hi,
I tried to set up the following custom layout on s390x:

2* dasd => LVM
  - /boot
  - /
2* scsi => LVM
  - /var

On install it tries to use sfdisk on a dasd device (known to not work) and breaks.
Other than usual it breaks so bad it doesn't even ask me to submit an error report with the data.

I have used apport-bug and provided a video to help.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
Uname: Linux 5.4.0-42-generic s390x
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27.4
Architecture: s390x
CasperMD5CheckResult: pass
CasperVersion: 1.445.1
CrashDB: {'impl': 'launchpad', 'project': 'subiquity'}
Date: Mon Oct 12 12:00:08 2020
ExecutablePath: /snap/subiquity/1969/usr/bin/subiquity
InterpreterPath: /snap/subiquity/1969/usr/bin/python3.6
LiveMediaBuild: Ubuntu-Server 20.04.1 LTS "Focal Fossa" - Release s390x (20200731)
Lspci:

Lspci-vt: -[0000:00]-
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t: Error: command ['lsusb', '-t'] failed with exit code 1: /sys/bus/usb/devices: No such file or directory
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcAttrCurrent: snap.subiquity.subiquity (complain)
ProcCmdline: /snap/subiquity/1969/usr/bin/python3 /snap/subiquity/1969/usr/bin/subiquity
ProcKernelCmdLine:
 --- quiet
 am0 ro
Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 3.8.2-0ubuntu2
PythonDetails: N/A
Snap: subiquity 20.07.1+git2.5de9df3e ()
SnapChannel:

SnapRevision: 1969
SnapUpdated: False
SnapVersion: 20.07.1+git2.5de9df3e
Title: install failed crashed with CalledProcessError
UpgradeStatus: No upgrade log present (probably fresh install)
UsingAnswers: False

[Michael Hudson-Doyle (mwhudson)]

Is this a KVM or an LPAR? There is another bug about dasds passed through to KVMs not being identified correcty.

[Christian Ehrhardt  (paelzer)]

On Tue, Oct 13, 2020 at 3:35 AM Michael Hudson-Doyle <
<email address hidden>> wrote:

> Is this a KVM or an LPAR?

LPAR

> There is another bug about dasds passed
> through to KVMs not being identified correcty.
>

No this is unrelated to KVM passthrough.

Note: A single dasd in an LVM (the default install setup) works fine.
Note2: to be clear - this is not the mixed (dasd+fcp) LVM, that I reported
in a different bug.

But building two LVMs one 2*dasd and the other one 2*fcp seems to make it
enter a code path that eventually tries sfdisks on the dasd and due to that
breaks.

[Michael Hudson-Doyle (mwhudson)]

Ah I think the issue here is around reusing existing partitions on a dasd vs anything to do with LVM, although I'm not completely sure.

[Server Team CI bot (server-team-bot)]

This bug is fixed with commit 8818498e to curtin on branch master.
To view that commit see the following URL:
https://git.launchpad.net/curtin/commit/?id=8818498e

[Michael Hudson-Doyle (mwhudson)]

This bug is believed to be fixed in curtin in version 21.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.