LFCS Storage Management Practice Question
A storage administrator is troubleshooting a system where a new SCSI disk is detected by the kernel but not visible in /dev/disk/by-id/. What is the most likely cause?
⚠ Common exam trap
Many exam-takers assume a missing partition table or device mapper target is the cause, but the question explicitly states the disk is detected by the kernel, meaning the issue is with udev link creation, not with kernel-level detection or partitioning.
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
✓
The udev daemon has not processed the device yet; run 'udevadm trigger' to generate links.
When a new SCSI disk is detected by the kernel, the kernel creates the device node (e.g., /dev/sdb), but the symbolic links under /dev/disk/by-id/ are generated by udev based on the device's WWID or other identifiers. If udev has not yet processed the uevent for the new disk, those persistent by-id links will not exist. Running 'udevadm trigger' forces udev to reprocess all pending or missed uevents, which creates the missing links.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The device mapper target is not set for the disk.
Why it's wrong here
Device mapper targets underpin LVM and dm-crypt volumes, not the udev rules that build by-id links for a raw SCSI disk. It would be the answer if the disk were a mapped logical volume whose links were absent, not a newly detected physical device.
- ✗
The disk does not have a valid partition table.
Why it's wrong here
by-id symlinks are generated from udev reading the disk's identifying metadata (serial, WWN), not its partition table; an unpartitioned disk still appears there. Partition tables matter for by-partuuid or by-partlabel links, so this is tempting when those specific paths are missing.
- ✗
The scsi_mod kernel module is not loaded.
Why it's wrong here
If scsi_mod were unloaded, the kernel would not detect the disk at all, so it cannot explain detection without a by-id link. The by-id symlinks come from udev rules reading device identifiers; their absence points to missing or misconfigured udev rules, not the SCSI module.
- ✓
The udev daemon has not processed the device yet; run 'udevadm trigger' to generate links.
Why this is correct
udev creates the persistent /dev/disk/by-id/ symlinks asynchronously after the kernel emits a uevent for the new SCSI device. The disk appearing in kernel logs confirms detection, but the by-id links only materialise once udev processes that event; running 'udevadm trigger' forces reprocessing, generating the missing symlinks.
Go deeper
Related to this question
About these practice questions
This LFCS question is part of Courseiva's 406-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LFCS practice question is part of Courseiva's free Linux Foundation certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LFCS exam.