LVMs with mixed block sizes break subiquity

Bug #1899477 reported by Christian Ehrhardt 
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
Triaged
Medium
Canonical Foundations Team
subiquity
New
Undecided
Unassigned

Bug Description

Hi,
I was trying to create the following setup.

2* DASD (4K block size by default) and 2*FCP (512b block size) into a single LVM.

That crashed subiquity badly and I have selected "submit to Canonical" but fail to get any feedback where that data is. I have since then rebooted, but if you could help to combine this report and the data that would be great.

I later on tried to combine such an LVM manually and found a possible root cause:
 sudo vgextend ubuntu-vg /dev/dasdf1 /dev/mapper/mpathd-part1 /dev/mapper/mpathe-part1
   Devices have inconsistent logical block sizes (4096 and 512).

So it seems subiquity/curtin need to better consider/adapt block sizes (re-format dasd devices for example) to make them match each other to be able to create a single LVM across them.

tags: added: s390x
Frank Heimes (fheimes)
tags: added: installer
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

As confirmation to prove that it can work.
After re-formatting the dasd blksize to match the 512 of the fcp disks as following I was able to "unite" them in one LVM.

$ sudo dasdfmt /dev/disk/by-path/ccw-0.0.254e
[sudo] password for ubuntu:
Please enter the blocksize of the formatting [4096]: 512
Drive Geometry: 60102 Cylinders * 15 Heads = 901530 Tracks
Device Type: Fully Provisioned
I am going to format the device /dev/disk/by-path/ccw-0.0.254e in the following way:
   Device number of device : 0x254e
   Labelling device : yes
   Disk label : VOL1
   Disk identifier : 0X254E
   Extent start (trk no) : 0
   Extent end (trk no) : 901529
   Compatible Disk Layout : yes
   Blocksize : 512
   Mode : Full
...

$ sudo fdasd /dev/disk/by-path/ccw-0.0.254e
...
$ lsdasd | grep 512
0.0.154e active dasdc 94:8 ECKD 512 21569MB 44174970
0.0.254e active dasdf 94:20 ECKD 512 21569MB 44174970

$ sudo pvcreate /dev/disk/by-path/ccw-0.0.254e-part1
$ sudo pvcreate /dev/disk/by-path/ccw-0.0.154e-part1
$ sudo vgextend ubuntu-vg /dev/disk/by-path/ccw-0.0.254e-part1 /dev/disk/by-path/ccw-0.0.154e-part1
  Volume group "ubuntu-vg" successfully extended
$ sudo lvextend /dev/ubuntu-vg/ubuntu-lv /dev/disk/by-path/ccw-0.0.254e-part1 /dev/disk/by-path/ccw-0.0.154e-part1
  Size of logical volume ubuntu-vg/ubuntu-lv changed from 126.99 GiB (32510 extents) to <169.12 GiB (43294 extents).
  Logical volume ubuntu-vg/ubuntu-lv successfully resized.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I'm a little confused here. Are you saying that you tried to combine the dasd and fcp drives into a single vg and things exploded? I guess subiquity should read out the physical block size of each device and prevent combinations that will not work...

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Yes Michael you are reading correctly, that is exactly what I tried and what happened.

I agree in "general" that "read the phys block size and prevent that config" would be a good start.

But Dasd's in there have a special twist as they don't really have blocks anyway (they have tracks and records), so with a dasdfmt call you can essentially "change" the physical block size (there is a net-size vs granularity tradeoff but anyway I have shown above that it can work).

Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
assignee: nobody → Canonical Foundations Team (canonical-foundations)
status: New → Triaged
importance: Undecided → Medium
Steve Langasek (vorlon)
tags: added: fr-856
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.