udev resource job does not list virtio drives as Block devices

[Jeff Lane ]

This is the second bug, the first involves a bad requires: statement in the disk/stats job, apparently.

THIS bug relates to disk tests not being runnable at all.

I noticed the following on the console while trying to run C-C-S from the packages in the testing ppa:
ii checkbox-ng 0.8~c3~ppa~ubuntu14.04.1 all PlainBox based test runner
ii plainbox-provider-checkbox 0.9~c1~ppa~ubuntu14.04.1 amd64 CheckBox provider for PlainBox
ii python3-checkbox-ng 0.8~c3~ppa~ubuntu14.04.1 all PlainBox based test runner (Python 3 library)
ii python3-checkbox-support 0.7~c1~ppa~ubuntu14.04.1 all collection of Python modules used by PlainBox providers
ii plainbox-insecure-policy 0.10~c1~ppa~ubuntu14.04.1 all policykit policy required to use plainbox (insecure version)
ii plainbox-provider-certification-server 0.5~c1~ppa~ubuntu14.04.1 all Server Certification
ii plainbox-provider-checkbox 0.9~c1~ppa~ubuntu14.04.1 amd64 CheckBox provider for PlainBox
ii plainbox-provider-resource-generic 0.7~c1~ppa~ubuntu14.04.1 amd64 CheckBox generic resource jobs provider
ii python3-plainbox 0.10~c1~ppa~ubuntu14.04.1 all toolkit for software and hardware testing (python3 module)

----------------------------------[ __disk__ ]----------------------------------
ID: 2013.com.canonical.certification::__disk__
(Command output hidden)
ERROR plainbox.ctrl: Ignoring invalid generated job 2013.com.canonical.certification::staging/disk/stats_{name}: Problem with field requires: wrong
Outcome: job passed
---------------------[ Check stats changes for each disk ]----------------------
ID: 2013.com.canonical.certification::disk/stats
Job cannot be started because:
 - resource expression "device.category == 'DISK'" evaluates to false
Outcome: job cannot be started
------[ Verify system storage performs at or above baseline performance ]-------
ID: 2013.com.canonical.certification::disk/read_performance
Job cannot be started because:
 - resource expression "device.category == 'DISK'" evaluates to false
Outcome: job cannot be started
---------------------------------[ SMART test ]---------------------------------
ID: 2013.com.canonical.certification::disk/smart
Job cannot be started because:
 - resource expression "device.category == 'DISK'" evaluates to false
Outcome: job cannot be started
[ Verify that storage devices, such as Fibre Channel and RAID can be detected and perform under stress. ]
ID: 2013.com.canonical.certification::disk/storage_devices
Job cannot be started because:
 - resource expression "device.category == 'DISK'" evaluates to false
Outcome: job cannot be started

After running udev_resource, it appears that there are NO devices listed as DISK.

This is on a qemu (KVM) cloud instance and has a virtio device /dev/vda:

lrwxrwxrwx 1 root root 0 Aug 11 12:07 vda -> ../devices/pci0000:00/0000:00:04.0/virtio1/block/vda/

And this is what udev_resource says:
path: /devices/pci0000:00/0000:00:04.0
bus: pci
category: SCSI
driver: virtio-pci
product_id: 4097
vendor_id: 6900
subproduct_id: 2
subvendor_id: 6900
product: Virtio block device
vendor: Red Hat, Inc

so device.category is being set to SCSI rather than DISK, and thus the disk tests are not runnable.

[Daniel Manrique (roadmr)]

I'll move this to checkbox-support, as it looks like a udev parser bug.

Also, Jeff, could you please attach udevadm info --export-db output to this bug? This will help add that machine's data to our test suite to ensure we don't have regressions in the future.

Thanks!

[Jeff Lane  (bladernr)]

Here's the full output...

[Jeff Lane  (bladernr)]

I mean HERE is the full output...

[Daniel Manrique (roadmr)]

Thanks.

Hey, this *is* being presented as a SCSI device :(

The PCI_CLASS value is :

E: PCI_CLASS=10000

After some processing I end up with:

(Pdb) class_id
1
(Pdb) subclass_id
0

If you look at checkbox_support/lib/pci.py, you'll see it has this:

    BASE_CLASS_STORAGE = 1
    CLASS_STORAGE_SCSI = 0

BASE_CLASS_STORAGE is compared against class_id, and then if it's storage (1), I look at subclass_id, comparing against CLASS_STORAGE_SCSI does tell me it's a SCSI device.

I'll look at other devices to see if any of them are the actual disk device but are being ignored for some reason; that seems a more likely cause (and one that won't require a horrible special-casing of SCSI detection). I'm looking at this one:

P: /devices/pci0000:00/0000:00:04.0/virtio1/block/vda
N: vda
E: DEVNAME=/dev/vda
E: DEVPATH=/devices/pci0000:00/0000:00:04.0/virtio1/block/vda
E: DEVTYPE=disk
E: ID_PART_TABLE_TYPE=gpt
E: MAJOR=253
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=8669

I'm having a bit of trouble comparing it to a known-good disk as the one I have is an SSD and looks *very* weird, but I'll try to compare to a good old rotary HD and see what I can discern.

[Daniel Manrique (roadmr)]

I booted a qemu VM:

DISK=/media/bulk/isos/ubuntu-14.04-desktop-amd64.iso
qemu-system-x86_64 -machine accel=kvm \
-drive file=$DISK,if=virtio -snapshot -m 1024M \
-net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22

once inside, I added the cert PPA, enabled universe and multiverse, and installed canonical-hw-submit.

Running that produced a bare-bones submission with pretty much just some devices, but one of them is the coveted virtio DISK device. It shows as unknown:unknown, but we can't really do anything about it as it's indeed not a real device :/

https://certification.staging.canonical.com/hardware/201112-10259/submission/96863/devices/?page=2

So the fix as uploaded to hexr looks good.