chzdev and --by-path doesn't work with LVM

[sharkcz]

My root fs is on a LV on a multi-DASD LVM setup. chzdev --export --by-path / returns just the first device, not all of them. lsblk and findmnt are available. As a result dracut adds incomplete info into the initrd and boot fails, because root fs can't be found.

[root@devel10 ~]# lsblk
NAME                    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
dasda                    94:0    0  2.3G  0 disk 
├─dasda1                 94:1    0    1G  0 part /boot
└─dasda2                 94:2    0  1.3G  0 part 
  └─fedora_devel10-root 253:0    0 11.4G  0 lvm  /
dasdb                    94:4    0  2.3G  0 disk 
└─dasdb1                 94:5    0  2.3G  0 part 
  ├─fedora_devel10-root 253:0    0 11.4G  0 lvm  /
  └─fedora_devel10-swap 253:1    0  1.4G  0 lvm  [SWAP]
dasdc                    94:8    0  2.3G  0 disk 
└─dasdc1                 94:9    0  2.3G  0 part 
  └─fedora_devel10-root 253:0    0 11.4G  0 lvm  /
dasdd                    94:12   0  2.3G  0 disk 
└─dasdd1                 94:13   0  2.3G  0 part 
  └─fedora_devel10-root 253:0    0 11.4G  0 lvm  /
dasde                    94:16   0  2.3G  0 disk 
└─dasde1                 94:17   0  2.3G  0 part 
  └─fedora_devel10-root 253:0    0 11.4G  0 lvm  /
dasdf                    94:20   0  2.3G  0 disk 
└─dasdf1                 94:21   0  2.3G  0 part 
  └─fedora_devel10-root 253:0    0 11.4G  0 lvm  /
[root@devel10 ~]# chzdev --export - --persistent --by-path / --quiet --type
# Generated by chzdev on devel10
[persistent dasd-eckd 0.0.0200]
online=1
[root@devel10 ~]# lszdev
TYPE         ID                          ON   PERS  NAMES
dasd-eckd    0.0.0200                    yes  yes   dasda
dasd-eckd    0.0.0201                    yes  yes   dasdb
dasd-eckd    0.0.0202                    yes  yes   dasdc
dasd-eckd    0.0.0203                    yes  yes   dasdd
dasd-eckd    0.0.0204                    yes  yes   dasde
dasd-eckd    0.0.0205                    yes  yes   dasdf
qeth         0.0.0800:0.0.0801:0.0.0802  yes  no    enc800
generic-ccw  0.0.0009                    yes  no    
[root@devel10 ~]# chzdev -v
chzdev version 2.12.0-3.fc32

[sharkcz]

for the record, I have no issues with zdev and root on LVM in Fedora 30 ...

[oberpar]

Seems to be due to a bug or changed behavior in lsblk:

$ lsblk --version
lsblk from util-linux 2.34
$ lsblk -o NAME,PKNAME
NAME     PKNAME
dasda    
└─dasda1 dasda
dasdb    
└─dasdb1 dasdb
  └─test dasdb1
dasdc    
└─dasdc1 dasdc
  └─test dasdc1
dasdd    
└─dasdd1 dasdd
  └─test dasdd1

Note how the entry for "test" is listed multiple times.

$ lsblk -o NAME,PKNAME -P
NAME="dasda" PKNAME=""
NAME="dasda1" PKNAME="dasda"
NAME="dasdb" PKNAME=""
NAME="dasdb1" PKNAME="dasdb"
NAME="dasdc" PKNAME=""
NAME="dasdc1" PKNAME="dasdc"
NAME="dasdd" PKNAME=""
NAME="dasdd1" PKNAME="dasdd"
NAME="test" PKNAME="dasdd1"

In the --pairs output the entry for "test" is only listed once. Compare that to the output of an older lsblk version:

$ lsblk --version
lsblk from util-linux 2.32
$ lsblk -o NAME,PKNAME -P
NAME="dasda" PKNAME=""
NAME="dasda1" PKNAME="dasda"
NAME="dasdb" PKNAME=""
NAME="dasdb1" PKNAME="dasdb"
NAME="dasdc" PKNAME=""
NAME="dasdc1" PKNAME="dasdc"
NAME="dasdd" PKNAME=""
NAME="dasdd1" PKNAME="dasdd"
NAME="test" PKNAME="dasdc1"
NAME="test" PKNAME="dasdd1"
NAME="test" PKNAME="dasdb1"

zdev relies on the repeat listing of these entries to determine the list of block devices associated with a compound device mapper device.

[sharkcz]

@karelzak, could you take a look on the behavior change for lsblk above?

[karelzak]

Unfortunately, it seems like a regression in v2.34. The issue will be fixed in v2.35.2 (I'll backport it ASAP to Fedora 32 too)

Anyway, it seems a little bit fragile to depend on the way how lsblk order standard output etc. The best way would be to use JSON where you have all the information in complete parent->child hierarchy.

For example RAID1 on sdc{1,2,3,4}:

$ lsblk -oNAME,MAJ:MIN,FSTYPE -J /dev/sdc
{
   "blockdevices": [
      {"name":"sdc", "maj:min":"8:32", "fstype":null,
         "children": [
            {"name":"sdc1", "maj:min":"8:33", "fstype":"linux_raid_member",
               "children": [
                  {"name":"md127", "maj:min":"9:127", "fstype":"ext4"}
               ]
            },
            {"name":"sdc2", "maj:min":"8:34", "fstype":"linux_raid_member",
               "children": [
                  {"name":"md127", "maj:min":"9:127", "fstype":"ext4"}
               ]
            },
            {"name":"sdc3", "maj:min":"8:35", "fstype":"linux_raid_member",
               "children": [
                  {"name":"md127", "maj:min":"9:127", "fstype":"ext4"}
               ]
            },
            {"name":"sdc4", "maj:min":"8:36", "fstype":"linux_raid_member",
               "children": [
                  {"name":"md127", "maj:min":"9:127", "fstype":"ext4"}
               ]
            },
            {"name":"sdc5", "maj:min":"8:37", "fstype":null}
         ]
      }
   ]
}

I guess json-c can parse and create all the hierarchy for you, so you don't need 90% code from s390-tools/zdev/src/blkinfo.c ;-) Just idea.

Another long term solution is to create a shared library from lsblk -- it's in my TODO list.

[sharkcz]

For the record, json-c library is already used by the zkey tools, so it wouldn't be a new dependency.

[oberpar]

Sounds like an idea for a future improvement in zdev. Thanks for pointing this out.

Can we close this issue with the reference to the lsblk change that should fix the problem?

[sharkcz]

Yup, let's close it as it has been fixed in lsblk via https://github.com/karelzak/util-linux/commit/91b636b5654576d0b808d0030ca9d773099e1db9