Disk Detected but Disk tests not Run on the Correct Disk

[mreed8855]

Bug Description

I have seen this issue where the disk is detected correctly but the tests are not run for the correct nvme disk.
Name: /dev/sda
Model: SanDisk 3.2Gen1
Size: 28.7G
Name: /dev/sdb
Model: SanDisk 3.2Gen1
Size: 28.7G
Name: /dev/nvme1n1
Model: Dell Ent NVMe CM7 E3.S MU 3.2TB
Size: 2.9T

disk/disk_cpu_load_nvme1c1n1 failed blocker I/O log
disk/disk_stress_ng_nvme1c1n1 failed blocker I/O log
disk/disk_stress_ng_sru_nvme1c1n1 failed blocker I/O log
disk/fstrim_nvme1c1n1 failed I/O log
disk/read_performance_nvme1c1n1 failed blocker I/O log
disk/smart_nvme1c1n1 failed I/O log
disk/stats_nvme1c1n1 failed blocker I/O log

The issue is that nvme1n1 is detected but the tests are attempting to run on nvme1c1n1

Cert-blocker Test Case

• cert-blocker

To Reproduce

So far I have only seen this on two systems. Dell and Mitac.
https://certification.canonical.com/certificates/2603-17316/

Expected Result

The disk tests should run on the detected nvme disk

Actual Result

The issue is that nvme1n1 is detected but the tests are attempting to run on nvme1c1n1

Environment

• 26.04

• Dell PowerEdge

• 6.19.0-6-generic x86_64

• Name: /dev/nvme1n1
  Model: Dell Ent NVMe CM7 E3.S MU 3.2TB
  Size: 2.9T

• 24.04.4

• Mitac GC68CB8056

• 6.8.0-101-generic

• Name: /dev/nvme0n1
  Model: KIOXIA KCMY1RUG7T68
  Size: 7T

Relevant log output

Additional context

No response

[syncronize-issues-to-jira]

Thank you for reporting your feedback to us!

The internal ticket has been created: https://warthogs.atlassian.net/browse/CHECKBOX-2194.

This message was autogenerated

[Mahmoud-Darweesh]

Hi, I looked into this and traced the root cause.

What's happening

When udev doesn't set DEVNAME for an NVMe device (which occurs on these
enterprise controllers), UdevadmDevice.name in udevadm.py falls back to
deriving the name from DEVPATH using regex. The current logic tries
nvmeXcYnZ before nvmeXnY:

# Tries controller-qualified name first - wrong on Dell/Mitac
match = re.search(r"/(nvme\d+c\d+n\d+)(?:/|$)", devpath)
if match:
    return match.group(1)  # returns nvme1c1n1 instead of nvme1n1

On the affected systems the sysfs path ends with nvme1c1n1, so that pattern
wins and every disk test is templated with nvme1c1n1, which isn't a usable
block device.

The fix

Check nvmeXnY first. When nvmeXcYnZ is matched, cross-reference lsblk
(already available in the parser). If the standard namespace device exists as
a real block device, prefer it:

match = re.search(r"/(nvme\d+n\d+)(?:/|$)", devpath)
if match:
    return match.group(1)  # nvme1n1 - correct
 
match = re.search(r"/(nvme(\d+)c\d+n(\d+))(?:/|$)", devpath)
if match:
    standard_name = "nvme{}n{}".format(match.group(2), match.group(3))
    if self._lsblk:
        lsblk_names = {d.get("kname") for d in self._lsblk.get("blockdevices", [])}
        if standard_name in lsblk_names:
            return standard_name  # lsblk confirms nvme1n1 exists
    return match.group(1)  # fallback to controller-qualified name

The existing test_DISK_SAMSUNG_KIOXIA behaviour is unaffected. Those
devices expose their standard namespace via the virtual NVMe subsystem with
DEVNAME set, so they never reach this code path.

All existing tests pass.

Happy to open a PR if this looks right.