[Bug 1893775] Re: [UBUNTU 20.04.1] Failure to install Ubuntu 20.04.1 as KVM guest on DASD
Dimitri John Ledkov
1893775 at bugs.launchpad.net
Tue Sep 8 09:36:28 UTC 2020
So the history of this msdos/dasd partitioning table stuff in the old
installer were as follows:
LTC-135429 https://bugs.launchpad.net/ubuntu/+source/partman-partitioning/+bug/1534629
LTC-136054 https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1527328
https://bugs.launchpad.net/ubuntu/+source/partman-partitioning/+bug/1537942
LTC-137464 https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1548411
LTC-149975 https://bugs.launchpad.net/ubuntu/+source/partman-partitioning/+bug/1650300
https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/1595495
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815916
partman-partitioning (110ubuntu3) xenial; urgency=medium
* Set s390x partitioning tables (parted label type) to dasd. LP:
#1534629, LP: #1527328, LP: #1537942.
-- Dimitri John Ledkov <xnox at ubuntu.com> Tue, 09 Feb 2016 19:32:43
+0000
partman-partitioning (110ubuntu4) xenial; urgency=medium
[ Viktor Mihajlovski ]
* Revert to using msdos partitioning table on s390x as a fallback,
however use dasd partitioning table if advised to do so by
partman. LP: #1548411
-- Dimitri John Ledkov <xnox at ubuntu.com> Mon, 29 Feb 2016 14:27:51
+0000
partman-partitioning (112ubuntu1) yakkety; urgency=medium
* Resynchronise with Debian. Remaining changes:
....
- On s390x use msdos partition table by default, unless partman
advises dasd.
-- Dimitri John Ledkov <xnox at ubuntu.com> Fri, 12 Aug 2016 09:52:51
+0100
But also this:
partman-base (190) unstable; urgency=medium
[ Viktor Mihajlovski ]
* Add disk label type to device directory, such that
e.g. partman-partitioning can elect dasd partitioning table for dasd
drives.
[ Dimitri John Ledkov ]
* On s390[x], prevent using extended partitions on DASD drives that can
only hold 3 partitions. Parted doesn't have special knowledge about
that and claims that msdos partition table on DASD drives can hold
the usual maximum number of partitions types.
-- Christian Perrier <bubulle at debian.org> Sun, 13 Nov 2016 07:45:31
+0100
The code there is:
s390|s390x)
if [ -e ./label ]; then
disklabel=$(cat label)
fi
# FBA devices have parted label dasd, but should not use dasd
# partition table. Maybe FBA|ECKD type should be exposed by
# partman-base and/or parted. LP: #1650300
device=$(sed 's|.*/||' ./device)
if grep -q "(FBA ).*$device" /proc/dasd/devices; then
disklabel=msdos
fi
if [ "$disklabel" != dasd ]; then
disklabel=msdos
fi
echo $disklabel;;
In partman-base we also limit msdos to primary partitions only on dasd
+#ifdef __s390__
+ /* DASD drives can only do 3 partitions */
+ && strcmp(disk->dev->model, "IBM S390 DASD drive")
+#endif
and disk label is saved to a file.
It is extremely limiting if installer cannot create/recreate/reformat
the drive, and has such hardcoded bad guesses.
In the past, qemu did not have vfio-ccw, but now it does. Surely, the
new libvirt/qemu in focal, when given a --disk path=/dev/disk/by-
path/ccw-0.0.1601 it must be emulating vfio-ccw if at all possible as
then on the guest it would appear as a /dev/dasda, and be correctly
processed.
So on s390x, the old installer
- default to use ms-dos partition table, with primary partitions only, with default layout having less than 4 partitions.
- if previously detected DASD partition table, use DASD, unless operating on FBA in that case use msdos again
The above I think was ultimately driven by "lowlevel formateded FBA or
ECKD drives" without a dasd partition table. In such cases, it was
reported in qemu/kvm as "unknown" and thus "msdos with 3 partitions" was
used which seemed to work, but is extremely fragile.
In the new installer, I do no wish to support partition tables that are
limited by a very small upper bound of 2TiB. My laptop has that, and
it's trivial to over-provision/thinly provision such sizes.
Is it reasonable to say that:
- nvme, zfcp, virtio-scsi will use GPT
- dasd ECKD devices must use vfio-ccw if passed directly to KVM, and uses dasd partition table
- If vfio-ccw is not available, one can partition it on the host, create LVM or ext4 storage pool, and passthrough LVM volume or qcow2 file via virtio-scsi
- passing through dasd devices as virtio-scsi in the guest must not be allowed
- dasd FBA is still confusing to me as it seems to not support neither dasd nor gpt partition table
Or what are you proposing we should be using across all storage variants, with/without passthrough?
I am interested to know what should be used for DASD-FBA passthrough
from host to guest as virtio-scsi.
I am also interested to know if we can pass more information from host
to guest via virtio-scsi to indicate what sort of backing storage is in
use. If it's zfcp, nvme, DASD-ECKD, DASD-FBA, whether or not it has been
low-level formatted or not (even if it's not possible to initiate low-
level formatting from the guest), etc. As it still feels like there is a
lot of blind guesswork in side the guest, which is limiting our
installers to tiny disk sizes.
** Bug watch added: Debian Bug tracker #815916
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815916
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to subiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1893775
Title:
[UBUNTU 20.04.1] Failure to install Ubuntu 20.04.1 as KVM guest on
DASD
Status in Ubuntu on IBM z Systems:
Triaged
Status in subiquity package in Ubuntu:
Incomplete
Status in subiquity source package in Focal:
Incomplete
Status in subiquity source package in Groovy:
Incomplete
Bug description:
---Problem Description---
Failure to install Ubuntu 20.04.1 as KVM guest on DASD
---uname output---
Linux version 5.4.0-42-generic (buildd at bos02-s390x-003) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #46-Ubuntu SMP Fri Jul 10 00:21:32 UTC 2020 (Ubuntu 5.4.0-42.46-generic 5.4.44)
Machine Type = 3096-703
---boot type---
CDROM / ISO image
---Install repository type---
Internet repository
---Install repository Location---
ports.ubunut.com
---Point of failure---
Other failure during installation (stage 1)
I tried to install an Ubuntu 20.04.1 guest from ISO which failed.
Steps to reproduce.
1. Boot from ISO to start installer, in my case I used virt-install, but a manually defined libvirt domain has the same issue:
$ virt-install --name focal.1 --memory 2048 --disk path=/dev/disk/by-path/ccw-0.0.a03f --cdrom ubuntu-20.04.1-live-server-s390x.iso
2. On the installer screen, stay in simple mode and accept all
defaults
3. Shortly after a error pop-up appears, saying the installation has failed. Opening the log I see:
...
storage:
config:
- {ptable: gpt, path: /dev/vda, wipe: superblock-recursive, preserve: false, name: '',
grub_device: false, type: disk, id: disk-vda}
- {device: disk-vda, size: 22153265152, wipe: superblock, flag: '', number: 1, preserve: false,
type: partition, id: partition-0}
- {fstype: ext4, volume: partition-0, preserve: false, type: format, id: format-0}
- {device: format-0, path: /, type: mount, id: mount-0}
version: 1
...
An error occured handling 'format-0': OSError - could not get path to dev from kname: vda1
finish: cmd-install/stage-partitioning/builtin/cmd-block-meta: FAIL: configuring format: format-0
TIMED BLOCK_META: 1.942
finish: cmd-install/stage-partitioning/builtin/cmd-block-meta: FAIL: curtin command block-meta
It seems that the new installation procedure isn't correctly detecting virtio-attached DASDs and tries to handle them like SCSI disks (gpt label, ...). This is a regression compared to the debian-installer and prevents the installation of Ubuntu 20.04 KVM guests on DASD.
I cross-checked by running the installation on a QCOW2 image, which
succeeded without problems.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893775/+subscriptions
More information about the foundations-bugs
mailing list