On Fri, Dec 14, 2018 at 06:56:06AM -0200, Thadeu Lima de Souza Cascardo wrote: > On Fri, Dec 14, 2018 at 08:47:20AM +0100, Hannes Reinecke wrote: > > But you haven't answered my question: > > > > Why can't we patch 'lsblk' to provide the required information even with the > > current sysfs layout? > > > Just to be clear here. If with 'current sysfs layout' you mean without any of the patches we have been talking about, lsblk is not broken. It just works with nvme multipath enabled. It will show the multipath paths and simply ignore the underlying/hidden ones. If we hid them, we meant for them to be hidden, right? What I am trying to fix here is how to find out which PCI device/driver is needed to get to the block device holding the root filesystem, which is what initramfs needs. And the nvme multipath device is a virtual device, pointing to no driver at all, and no relation to its underlying devices, needed for it to work. Cascardo. > I think we could, but with my Ubuntu hat on, after the kernel fix for > initramfs-tools, that is, slaves/holders links, the user will get an updated > kernel that breaks the current lsblk on Bionic (Ubuntu 18.04). That will > require that we backport the lsblk fix, which is not only more work, but there > may be users who only update from -security, which is where kernel updates end > regularly, but not this lsblk fix. > > And that kernel update is a regression against that old lsblk version. > > Cascardo. > > > Cheers, > > > > Hannes > > -- > > Dr. Hannes Reinecke Teamlead Storage & Networking > > hare@xxxxxxx +49 911 74053 688 > > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg > > GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton > > HRB 21284 (AG Nürnberg)
