Test failures on system wtih NVMe drive

[trgill]

Our tests fail on a system with an NVMe drive. The error message is:

thread 'engine::strat_engine::backstore::backstore::tests::real_test_setup' panicked at 'block devices have devnode', libcore/option.rs:914:5

The problem can be reproduced on dell-r730-011.dsal.lab.eng.rdu2.redhat.com

[agrover]

It looks like the two nvme drives on this system each have 2 entries, one of which has devnode and one which doesn't?

https://gist.github.com/agrover/c2b432e59a183fdf1f5c97ba7d2e2c1c

[agrover]

Maybe this means we need to be more precise about using udev to enumerate block devices. See also #908.

[agrover]

That entry in the gist at line 48 -- it's listed as SUBSYSTEM=block and DEVTYPE=disk but doesn't have DEVNAME (or any of the other tags we check for, ID_PART_TABLE_TYPE, ID_PART_ENTRY_DISK, ID_FS_USAGE). or MAJOR or MINOR set.

It also shares ID_WWN with the entry at line 84. This seems like some kind of container or controller device.

Should we be filtering these out?

[mulkieran]

I don't think that the udevadm output will reliably tell what device has a devnode and what doesn't. The devnode is obtained by a specific udevadm method, rather than by just looking up some udev property. Probably the cheapest way to find the true state of affairs is to run a query using pyudev.

[agrover]

It's showing us something that is SUBSYSTEM=block and DEVTYPE=disk that doesn't have a DEVNAME on this machine and appears to be a duplicate of another entry that looks much more usable. I'm sure there are other ways to lack a DEVNAME but this seems to be one that we can fix straight off. How should we fix this? Is this something we need to handle or is this a udev problem for thinking something is a disk when it really isn't?

[mulkieran]

Related: https://bugzilla.redhat.com/show_bug.cgi?id=1582025.