Why is my U.2 NVMe SSD not detected in my server?

1. 1.List NVMe controllers by PCI class as well as by name. An NVMe controller always enumerates as class 0108, 'Non-Volatile memory controller', whatever the vendor's device name says, so a grep for 'nvme' alone can miss one. Match the class in brackets so a vendor or device ID containing 0108 does not count. Count the lines against the drives you installed.

   lspci -nn | grep -i -e nvme -e '\[0108\]' -e non-volatile

   ReadingEach controller prints as 'Non-Volatile memory controller [0108]' with its [vendor:device] IDs. A drive missing here is not visible on the host's PCI bus: the bay is not NVMe-wired, the slot or card is not configured (bifurcation for a passive card, BIOS settings for a retimer card), the card is a vendor-locked switch card, the cable is the wrong type or dead, VMD is enabled without the kernel's vmd driver (step 4), or the drive itself is at fault. Look at firmware, cabling and BIOS (paths p4 and p5) before the OS. A drive present here has a problem above the PCI bus: go to p2.
2. 2.Print the bus tree to see where each drive sits: directly on a root port, behind a switch, or in a separate PCI domain.

   lspci -tv

   ReadingAn extra bridge level with several downstream ports means a switch-type adapter. Drives in their own PCI domain are behind Intel VMD.
3. 3.For a drive that is present, check the negotiated link against what it can do. Run it as root, because some config space is root-only and the capability block may not print otherwise.

   sudo lspci -vv -s <bus:dev.fn> | grep -E 'LnkCap|LnkSta'

   ReadingLnkCap is the most the device can do (for example Speed 16GT/s, Width x4); LnkSta is what it negotiated. An endpoint whose LnkSta is below LnkCap is marked '(downgraded)'. A width of x1 or x2 instead of x4, or a lower speed, points at the slot's lane allocation, a cable, a riser or a retimer rather than the drive.
4. 4.If the board has Intel VMD enabled, NVMe root ports and the drives behind them are moved into a separate VMD PCI domain, and the kernel needs its vmd module to reach them. Check which kernel driver owns the VMD controller.

   lspci -k | grep -i -B3 -e vmd -e "volume management"

   Readinglspci -k prints both the driver handling a device ('Kernel driver in use') and the modules capable of handling it ('Kernel modules'). 'Kernel driver in use: vmd' means the vmd module owns the VMD controller, and its drives should show in the VMD domain in lspci -tv. VMD enabled in firmware with no device using the vmd driver, and no VMD domain in lspci -tv, points at the kernel side. Do not stop at the VMD setting: in one 45HomeLab thread on a Supermicro X11SPH-nCTPF board, the drives were not seen with VMD disabled and threw PCI BAR errors with it enabled, and replacing the third-party OCuLink cables with Supermicro's own fixed it with VMD disabled. Check the cable too (p5).

1. 1.Check which kernel driver owns the controller. Take the bus:dev.fn address from the first lspci command.

   lspci -k -s <bus:dev.fn>

   Reading'Kernel driver in use: nvme' is correct. 'vfio-pci' means the device was unbound from its host driver and handed to passthrough (a Proxmox VM, or a TrueNAS isolated device), so the host will not create /dev/nvme for it: remove it from the VM's passthrough or the isolated-device list and reboot. No driver line at all means the nvme driver did not bind; read the kernel log in the next step.
2. 2.Read the nvme driver's probe messages and match each address to lspci.

   dmesg | grep -i nvme

   ReadingA healthy probe logs 'nvmeN: pci function 0000:BB:DD.F'. Errors on the same address after that line (timeouts, resets, removal) mean the link came up and the controller failed to initialise. No nvme lines for an address that lspci shows means no nvme driver bound (previous step).
3. 3.Ask nvme-cli what the driver registered.

   nvme list && nvme list-subsys

   Readingnvme list only shows controllers the nvme driver registered in sysfs, so a drive in lspci but absent here is a driver, binding or controller problem. list-subsys shows each registered controller with its transport and address.
4. 4.Read each registered controller's state from sysfs. This is the kernel's own state word for the controller.

   grep . /sys/class/nvme/nvme*/state

   Reading'live' is the working state. A controller that stays at 'dead', or stays at 'resetting' or 'connecting', was found by the driver and could not be brought up: suspect the drive or its firmware, not the bay. Before blaming the drive, move it to a different known-good NVMe path and repeat.
5. 5.Check that a usable namespace exists. lsblk lists block devices (namespaces such as nvme0n1), not controllers.

   lsblk -d -o NAME,MODEL,SIZE

   ReadingA controller in nvme list with no nvmeXnY here has no usable namespace attached. Run 'lsblk --list-columns' to confirm the column names on the installed version.

1. 1.Over SSH to the iDRAC, dump the hardware inventory. Each NVMe drive the server's own management path can see is listed with a bay FQDD.

   racadm hwinventory

   ReadingLook for entries like 'Disk.Bay.8:Enclosure.Internal.0-1:PCIeExtender.Slot.1' with BusProtocol = PCIE and DeviceProtocol = NVMe-MI1.0. A bay with no entry was not seen by the iDRAC, so the OS will not see it either: go to p5. BusNumber is decimal; convert it to hex to match lspci (Dell's example: BusNumber 134 is bus 86 in hex).
2. 2.Check the drive list and the Lifecycle Controller log for the bay. Dell's KB gives the drive list as iDRAC > Physical Disks and the messages as Lifecycle Controller log entries; where that log sits in the UI depends on the iDRAC version.

   iDRAC > Physical Disks, and the Lifecycle Controller log (location varies by iDRAC version; filter PR8, CTL137)

   ReadingPR8 reads 'Device not detected: Dell NVMe PCIe SSD Configuration Data(PCIe SSD in Slot X in Bay Y)'. CTL137 reads 'iDRAC is unable to successfully communicate with the device PCIe SSD in Slot X in Bay Y'. Both name the bay. The KB these messages come from has a fix that applies only to Dell PM1733a and PM1735a firmware: use it for the message IDs, not the remedy.

1. 1.Work out what kind of card it is: passive (each drive takes its own x4 share of the slot's lanes), retimer (Supermicro's example runs 4 lanes per port and needs BIOS configuration), or switch (built on a PCIe switch chip). The bus tree shows a switch as an extra bridge level.

   lspci -tv

   ReadingSeveral downstream ports under one extra bridge: a switch-type card. Drives (or nothing) directly under the root port: passive or retimer.
2. 2.For a passive card, open the host BIOS/UEFI setup and find the bifurcation setting for the slot holding the card. The setting is per slot and the menu names differ by vendor. Lenovo's UEFI offers x8x8, x8x4x4 or x4x4x8, and x4x4x4x4 for a physical x16 slot. On Lenovo's Override Slot Bifurcation menu, x16 (the default) means the system setting is used; choose x4x4x4x4 explicitly.

   Host BIOS/UEFI setup: the per-slot PCIe bifurcation setting for the slot holding the card (for example Lenovo 'Slot n' = x4x4x4x4)

   ReadingA passive card shows one drive per x4 link the slot is split into: each drive needs its own x4 link (x4x4 for two drives, x4x4x4x4 for four in an x16 slot). Supermicro documents that a slot left at x8 or x16 shows only one drive, for a two-drive M.2 carrier; the lane split is the same rule a passive multi-U.2 card relies on.
3. 3.For a retimer card, the BIOS still has to be configured for it. Supermicro says its AOC-SLG3-4E4T retimer card requires motherboard BIOS configuration and points to the card's User's Guide for the settings.
4. 4.If the board offers no split for that slot, or no split with one x4 link per drive, a passive card cannot show every drive there. Forum posters report boards where the setting was missing from the BIOS. A split fixed at x4x4 is not the obstacle for two drives: in one thread on an ASUS K14PA-U12, whose MCIO ports the poster reports as fixed at x4x4, the fault was a dead cable. The sourced option is a different slot that can be split. Forum replies say a switch card avoids the split; we have not found a vendor document stating that. Supermicro's own switch-based NVMe cards are stated to work only in validated Supermicro systems and motherboards.

1. 1.Confirm the bay itself is on an NVMe path. A bay takes an NVMe drive only behind an NVMe or AnyBay backplane, in configurations that wire it to onboard NVMe ports, retimer cards or NVMe switch adapters. On Lenovo's SR650 V2 a Tri-Mode RAID adapter is another route, but only for U.3 drives on an AnyBay backplane. Dell's R740xd manual lists up to 32 SAS or SATA drives but up to 24 NVMe drives, so not every bay takes NVMe; we have not found a Dell document stating which bays those are. Oracle labels its NVMe-capable bays NVMe0, NVMe1 and so on: check the bay label and the service manual for your chassis.
2. 2.If the drive is cabled to a tri-mode RAID adapter or HBA, check the cable type. Intel documents NVMe drives that the adapter BIOS could not detect on regular data cables, with the NVMe (OCuLink) data cable as the resolution. A ServeTheHome thread on a Broadcom 9400-16i shows the same symptom with an SFF-8643-to-SFF-8639 cable. Separately, Lenovo's SR650 V2 guide supports Tri-Mode only with U.3 drives on an AnyBay backplane and states U.2 drives are not supported there.
3. 3.Swap in a cable of the type the board or controller maker documents for NVMe, or a known-good one. Several of the U.2 threads below pointed at the cable: two were fixed by replacing it (t4, t3), and in a third the poster found the wrong SFF-8654 type, with no confirmation afterwards (t1).
   ReadingIf the drive appears in lspci after the swap, the old cable was the fault. If it still does not, move the drive to another bay or path before suspecting the drive.

Forum replies say so, but we have not found a vendor document stating it, so treat it as unconfirmed. Supermicro's switch-based NVMe cards are built on a PCIe switch chip and Supermicro states they work only in validated Supermicro systems and motherboards, so check the card maker's host requirements before relying on one in another server.

Take the BusNumber from racadm hwinventory, which is decimal, and convert it to hex to find the lspci address (Dell's example: BusNumber 134 is bus 86 in hex). Then find the 'nvmeN: pci function' line for that address in dmesg, which names the /dev/nvmeN device.

Not to diagnose it, and often not at all: bifurcation, retimer BIOS settings, VMD and vfio-pci binding are all configuration. Hardware is the answer when the bay has no NVMe path, the cable is the wrong standard or dead, a vendor-locked switch card sits in another maker's system, or the drive fails the same way on a known-good NVMe path. A slot that cannot be split for a passive card is first a reason to use another slot. This page does not list a product, because whether a card or cable fits depends on your board's slot options and the connector your controller documents.