System Architecture →hardMultiple Choice

LPIC-1 System Architecture Practice Question

Exhibit

01:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS (rev 08)
        Subsystem: LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS
        Flags: bus master, fast devsel, latency 0, IRQ 24
        I/O ports at ec00 [size=256]
        Memory at f7ffc000 (64-bit, non-prefetchable) [size=16K]
        Memory at f7ff8000 (64-bit, non-prefetchable) [size=16K]
        Expansion ROM at f7f00000 [disabled] [size=256K]
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [68] Express Endpoint, MSI 00
        Capabilities: [98] Power Management version 3
        Capabilities: [a0] MSI-X: Enable- Count=15 Masked-
        Kernel driver in use: mpt3sas
        Kernel modules: mpt3sas

Refer to the exhibit. The system has multiple SAS drives attached to this controller, but one of them is not detected during boot. Which command is most likely to provide information about the device detection order?

⚠ Common exam trap

The trap here is that candidates often pick `lsscsi` or `cat /proc/scsi/scsi` because they show SCSI devices, but they fail to realize those commands only show the final state, not the boot-time detection order or failure messages that `dmesg` provides.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

dmesg | grep -i scsi

The `dmesg` command displays kernel ring buffer messages, which include hardware detection and initialization logs during boot. By piping to `grep -i scsi`, you filter for SCSI-related messages, revealing the order in which devices were discovered and any errors for undetected drives. This is the most direct way to see why a specific SAS drive failed to appear.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
cat /proc/scsi/scsi
Why it's wrong here
Reading /proc/scsi/scsi shows attached SCSI devices in the order the kernel detected them, which directly answers the detection-order question. It is tempting to reject as legacy, but this file remains the authoritative record of probe sequence for SAS drives.
✗
lsblk
Why it's wrong here
lsblk reads the current block-device tree from sysfs, showing partitions and mountpoints, not the controller's probe sequence, so it cannot expose detection order. It is tempting because it quickly confirms whether a disk is recognised, which suits verifying device presence rather than boot-time discovery sequence.
✓
dmesg | grep -i scsi
Why this is correct
The kernel ring buffer records SCSI and SAS device discovery, including host, target and LUN assignment order, as the controller probes each disk. Filtering dmesg for SCSI lines reveals which drives were detected and in what sequence, exposing the missing device.
✗
lsscsi
Why it's wrong here
lsscsi lists attached SCSI/SAS devices and their transport, but not the kernel's probe sequence, so it cannot reveal detection order. It is tempting because it enumerates devices, which suits confirming whether a drive is visible at all rather than diagnosing the order in which the controller discovered them.

Go deeper

LPIC-1 System Architecture Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question