Closed sharkcz closed 4 years ago
for the record, I have no issues with zdev and root on LVM in Fedora 30 ...
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.
@karelzak, could you take a look on the behavior change for lsblk above?
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.
For the record, json-c library is already used by the zkey tools, so it wouldn't be a new dependency.
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?
Yup, let's close it as it has been fixed in lsblk
via https://github.com/karelzak/util-linux/commit/91b636b5654576d0b808d0030ca9d773099e1db9
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
andfindmnt
are available. As a result dracut adds incomplete info into the initrd and boot fails, because root fs can't be found.