ubuntu-installer/partman does not properly detect partitions on FBA device

Bug #1650300 reported by bugproxy on 2016-12-15
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
High
Dimitri John Ledkov
partman-partitioning (Ubuntu)
High
Dimitri John Ledkov
Xenial
Medium
Dimitri John Ledkov
Yakkety
Medium
Dimitri John Ledkov

Bug Description

[Impact]
* multipartition installations on DASD-FBA use wrong partition table, resulting in userspace tools not recognising the partitions that kernel uses on those drives

[Testcase]
* install ubuntu using manual partitioning onto DASD-FBA drive with two partitions e.g. 500M for /boot and / for the rest.
* re-start the installer again
* observe that in manual partitioning both partitions are correctly detected and for example reuse of partition #2 is offered.

I installed Ubuntu 16.04.1 on an FBA device. When the partman menu appeared, I created a new partition table on DASD 0.0.ede0 (FBA), and then I created two partitions: 0.7G ext4 for /boot and 10G ext4 for /.
Installation proceeded ok, and the system ipled from EDEV EDE0. All fine.

During a 2nd installation on the same device the following problem occured:
After activation of the previously installed EDEV disk, partman shows one single full size partition, which is not correct:
DASD 0.0.ede0 (FBA ) - 10.7 GB IBM S390 DASD drive
> #1 10.7 GB

while kernel has the correct info:
~ # cat /proc/partitions |grep dasd
  94 0 10485760 dasda
  94 1 683584 dasda1
  94 2 9801984 dasda2
Continuing with the installation from here results in a system IPL that ends up in an initramfs, since the rootfs could not be mounted due to an incorrect partition table.

Attaching syslog.

Until this bug is fixed, I recommend to describe the workaround (when installing on EDEV DASD it is highly recommended to create an empty partition table on the entire device before partitioning) in the release notes.

Maybe you can have a look info LTC bug 137464 / LP1548411 which described a similar problem with vdisks under KVM.

------- Comment From <email address hidden> 2016-12-15 10:07 EDT-------
Canonical, please assign to correct component within LP. Thx

tags: added: architecture-s39064 bugnameltc-149975 severity-high targetmilestone-inin16041

Default Comment by Bridge

Changed in ubuntu:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
affects: ubuntu → linux (Ubuntu)
Frank Heimes (frank-heimes) wrote :

This ticket is a replacement to LP 1578232 which was a bit screwed up ...

affects: linux (Ubuntu) → parted (Ubuntu)
Changed in ubuntu-z-systems:
importance: Undecided → Medium
Changed in ubuntu-z-systems:
assignee: nobody → Dimitri John Ledkov (xnox)
Changed in parted (Ubuntu):
importance: Undecided → High
assignee: Skipper Bug Screeners (skipper-screen-team) → Dimitri John Ledkov (xnox)
milestone: none → ubuntu-17.01
Changed in ubuntu-z-systems:
importance: Medium → High
Changed in parted (Ubuntu):
status: New → Confirmed
milestone: ubuntu-17.01 → ubuntu-17.02
Dimitri John Ledkov (xnox) wrote :

Please excuse my ignorance, but I am working under the assumption that FBA devices should be partitioned using DASD partitioning table just like the ECKD drives (using fdasd tool). If this is wrong, and e.g. ms-dos partition table should be used for FBA devices, we need to change the logic that decides which partitioning tables to use in the installer.

I can reproduce this bug, in a sense that kernel manages to read DASD partitioning table, and partitions, off FBA device including volume label, yet userspace tools parted and fdasd cannot.

syslog:
Jan 11 07:07:27 kernel: [ 156.679393] dasd-fba 0.0.0104: New FBA DASD 9336/10 (CU 6310/80) with 59025 MB and 512 B/blk
Jan 11 07:07:27 kernel: [ 156.682792] dasdb:VOL1/ 0X0104: dasdb1 dasdb2

# cat /proc/dasd/devices
0.0.0104(FBA ) at ( 94: 4) is dasdb : active at blocksize: 512, 120884827 blocks, 59025 MB

# cat /proc/partitions | grep dasdb
  94 4 60442413 dasdb
  94 5 585920 dasdb1
  94 6 59856256 dasdb2

# fdasd -p /dev/dasdb

fdasd error: Unsupported disk type
/dev/dasdb is not an ECKD disk! This disk type is not supported!

# fdasd -f -p /dev/dasdb
reading volume label ..:
Cannot show requested information because the disk label block is invalid
exiting...

# parted /dev/dasdb print
Model: IBM S390 DASD drive (dasd)
Disk /dev/dasdb: 61.9GB
Sector size (logical/physical): 512B/512B
Partition Table: dasd
Disk Flags:

Number Start End Size File system Flags
 1 1024B 61.9GB 61.9GB

Changed in ubuntu-z-systems:
status: New → Confirmed

------- Comment From <email address hidden> 2017-01-11 10:18 EDT-------
Hi Dimitri,

FBA DASDs must be treated differently from regular DASDs, i.e. to create a partition, you should use fdisk, parted etc. and not fdasd.

(In reply to comment #8)
> Please excuse my ignorance, but I am working under the assumption that FBA
> devices should be partitioned using DASD partitioning table just like the
> ECKD drives (using fdasd tool). If this is wrong, and e.g. ms-dos partition
> table should be used for FBA devices, we need to change the logic that
> decides which partitioning tables to use in the installer.
>
> I can reproduce this bug, in a sense that kernel manages to read DASD
> partitioning table, and partitions, off FBA device including volume label,
> yet userspace tools parted and fdasd cannot.
>
> syslog:
> Jan 11 07:07:27 kernel: [ 156.679393] dasd-fba 0.0.0104: New FBA DASD
> 9336/10 (CU 6310/80) with 59025 MB and 512 B/blk
> Jan 11 07:07:27 kernel: [ 156.682792] dasdb:VOL1/ 0X0104: dasdb1 dasdb2
>
> # cat /proc/dasd/devices
> 0.0.0104(FBA ) at ( 94: 4) is dasdb : active at blocksize: 512,
> 120884827 blocks, 59025 MB
>
> # cat /proc/partitions | grep dasdb
> 94 4 60442413 dasdb
> 94 5 585920 dasdb1
> 94 6 59856256 dasdb2
>
> # fdasd -p /dev/dasdb
>
> fdasd error: Unsupported disk type
> /dev/dasdb is not an ECKD disk! This disk type is not supported!
>
> # fdasd -f -p /dev/dasdb
> reading volume label ..:
> Cannot show requested information because the disk label block is invalid
> exiting...
>
> # parted /dev/dasdb print
> Model: IBM S390 DASD drive (dasd)
> Disk /dev/dasdb: 61.9GB
> Sector size (logical/physical): 512B/512B
> Partition Table: dasd
> Disk Flags:
>
> Number Start End Size File system Flags
> 1 1024B 61.9GB 61.9GB

affects: parted (Ubuntu) → partman-partitioning (Ubuntu)
Changed in partman-partitioning (Ubuntu Xenial):
assignee: nobody → Dimitri John Ledkov (xnox)
Changed in partman-partitioning (Ubuntu Yakkety):
assignee: nobody → Dimitri John Ledkov (xnox)
Changed in partman-partitioning (Ubuntu Xenial):
milestone: none → xenial-updates
Changed in partman-partitioning (Ubuntu Yakkety):
milestone: none → yakkety-updates
Changed in partman-partitioning (Ubuntu Xenial):
status: New → Confirmed
Changed in partman-partitioning (Ubuntu Yakkety):
status: New → Confirmed
importance: Undecided → Medium
Changed in partman-partitioning (Ubuntu Xenial):
importance: Undecided → Medium
Dimitri John Ledkov (xnox) wrote :

Hello,

I think I should add a condition in partman-partitioning that checks /proc/dasd/devices to see if the drive with `dasd` label is FBA, and if so, fallback to msdos partioning table. I'm not sure if FBA drive via virtio in KVM has /proc/dasd/devices with the right information or not. I guess using BIODASDINFO ioctl is better.

However, shouldn't the GNU parted use BIODASDINFO ioctl and report/export dasd_info.type such that partman-partioning can use that? Or e.g. not set `dasd` label when dasd_info.type != "ECKD" (same logic as fdasd)?

Regards,

Dimitri.

bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2017-01-12 07:23 EDT-------
Unfortunately, the term dasd is overloaded as it describes a) a disk device type in terms of access method (more comparable with SCSI or IDE) and b) the format of the disk in a misleading manner (instead of dasd it should rather be called eckd).
This becomes quite obvious by looking at KVM: here the device typein the guest is virtio_blk, whereas the data format is determined by the device type in the host, which can be an ECKD DASD. BIODASDINFO won't work in this case because it needs the dasd driver.
The way I'd suggest to attack this would be in partman-base rather than in partman-partitioning, because the former package determines the label type to be written. I.e. one could check whether the disk is of type dasd_fba and in this case not request a dasd label.
Alternatively, one could consider changing parted, but this might be more complex/error prone.

Dimitri John Ledkov (xnox) wrote :
description: updated
description: updated
Changed in partman-partitioning (Ubuntu):
status: Confirmed → Fix Committed
Changed in partman-partitioning (Ubuntu Xenial):
status: Confirmed → Triaged
Changed in partman-partitioning (Ubuntu Yakkety):
status: Confirmed → Triaged
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package partman-partitioning - 114ubuntu2

---------------
partman-partitioning (114ubuntu2) zesty; urgency=medium

  * DASD-FBA drives should still use msdos partition table, and not dasd
    one. LP: #1650300

 -- Dimitri John Ledkov <email address hidden> Thu, 12 Jan 2017 12:36:28 +0000

Changed in partman-partitioning (Ubuntu):
status: Fix Committed → Fix Released
Dimitri John Ledkov (xnox) wrote :

"I.e. one could check whether the disk is of type dasd_fba and in this case not request a dasd label." but how would one do that in partman-base? given that parted does report "dasd" type to partman. Note that partman-partitioning ultimately decides what the default partition table is, and users can override that. What I have uploaded is a whitelist, thus if somebody export FBA via virtio, it will result in using dasd partition table =(. However, the combination of FBA and KVM is niche no? (as in running kvm, in z/VM, with FBA pass-through virtio devices)

Changed in ubuntu-z-systems:
status: Confirmed → Triaged
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2017-01-12 10:39 EDT-------
My point of view was more a structural one: the parameters for the "make label" operation are assembled in partman-base and the extra check for FBA could be done there as well. But that may just be a matter of taste.

And the comment about virtio and DASD may have been misleading, I wanted to point out that using DASD-specific ioctls as only means of identifying DASD type disks would break the (ECKD) DASD detection in KVM.

Dimitri John Ledkov (xnox) wrote :

And the current DASD detection in KVM, detects both ECKD and FBA as the same thing? or does it manage to make a distinction? I'll need to test that.

Default Comment by Bridge

Default Comment by Bridge

Changed in partman-partitioning (Ubuntu Xenial):
status: Triaged → In Progress
status: In Progress → Triaged
Changed in partman-partitioning (Ubuntu Yakkety):
status: Triaged → In Progress
Changed in partman-partitioning (Ubuntu Xenial):
status: Triaged → In Progress
Changed in ubuntu-z-systems:
status: Triaged → In Progress

Hello bugproxy, or anyone else affected,

Accepted partman-partitioning into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/partman-partitioning/112ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in partman-partitioning (Ubuntu Yakkety):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in partman-partitioning (Ubuntu Xenial):
status: In Progress → Fix Committed
Brian Murray (brian-murray) wrote :

Hello bugproxy, or anyone else affected,

Accepted partman-partitioning into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/partman-partitioning/110ubuntu4.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in ubuntu-z-systems:
status: In Progress → Fix Committed
Dimitri John Ledkov (xnox) wrote :

Testing yakkety d-i 20101020ubuntu483.1 with apt-setup/proposed=true with partman-partitioning_112ubuntu1.1_s390x.udeb. Successful.

Dimitri John Ledkov (xnox) wrote :

Testing xenial d-i 20101020ubuntu451.9 with apt-setup/proposed=true with partman-partitioning_110ubuntu4.1_s390x.udeb. Successful.

tags: added: verification-done
removed: verification-needed

The verification of the Stable Release Update for partman-partitioning has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package partman-partitioning - 112ubuntu1.1

---------------
partman-partitioning (112ubuntu1.1) yakkety; urgency=medium

  * DASD-FBA drives should still use msdos partition table, and not dasd
    one. LP: #1650300

 -- Dimitri John Ledkov <email address hidden> Thu, 12 Jan 2017 16:51:03 +0000

Changed in partman-partitioning (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package partman-partitioning - 110ubuntu4.1

---------------
partman-partitioning (110ubuntu4.1) xenial; urgency=medium

  * DASD-FBA drives should still use msdos partition table, and not dasd
    one. LP: #1650300

 -- Dimitri John Ledkov <email address hidden> Thu, 12 Jan 2017 16:56:44 +0000

Changed in partman-partitioning (Ubuntu Xenial):
status: Fix Committed → Fix Released
Changed in ubuntu-z-systems:
status: Fix Committed → Fix Released

------- Comment From <email address hidden> 2017-01-25 06:45 EDT-------
IBM Bugzilla -> closed

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers