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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1893775 Title: [UBUNTU 20.04.1] Failure to install Ubuntu 20.04.1 as KVM guest on DASD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893775/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
