EX200 Configure local storage Practice Question
A Red Hat Enterprise Linux 9 server has an LVM volume group 'vg01' that contains two physical volumes: /dev/sda2 and /dev/sdb1. After a reboot, the system fails to activate the volume group. The administrator runs 'pvdisplay' and sees one physical volume as 'unknown device'. What is the most likely cause?
⚠ Common exam trap
Test-takers frequently assume 'unknown device' means hardware failure or corruption, when in reality it is usually a configuration issue like an incorrect LVM filter or missing device-mapper entries.
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 LVM filter in /etc/lvm/lvm.conf is excluding /dev/sdb1
The LVM filter in /etc/lvm/lvm.conf controls which devices LVM scans during activation. If the filter excludes /dev/sdb1, LVM will not recognize that physical volume, causing the volume group to fail activation. The 'unknown device' status indicates LVM cannot access the device metadata, not that the device is missing or corrupted.
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 physical volume is corrupted and needs to be restored from backup
Why it's wrong here
Physical volume corruption typically surfaces as I/O errors, failed metadata reads, or 'Read of PV failed' messages during vgscan, not as an 'unknown device' placeholder. The PV's identity and device path remain known; LVM would mark the PV as having errors or being unavailable while still displaying its name. Restoring from backup is relevant only after metadata loss or device failure, but it would not explain a filter-induced scanning exclusion.
- ✓
The LVM filter in /etc/lvm/lvm.conf is excluding /dev/sdb1
Why this is correct
The LVM filter in /etc/lvm/lvm.conf controls which block devices LVM scans when looking for physical volumes. A negative entry such as filter = ['r|/dev/sdb1|'] tells LVM to reject that device entirely, so its PV metadata is never read and the VG sees the missing PV as an 'unknown device.' Removing the rejection or using a positive filter that accepts /dev/sdb1 and running pvscan/vgscan restores visibility.
- ✗
The filesystem on the logical volume has become corrupted, preventing LVM metadata access
Why it's wrong here
Filesystem corruption on a logical volume is unrelated to LVM metadata, because metadata lives in the physical volume's metadata area and in /etc/lvm/backup, not inside the filesystem on the LV. LVM activation is completely independent of filesystem health; a corrupted ext4/xfs filesystem does not prevent LVM from reading PV metadata or activating the VG. Therefore, it cannot be the cause of an 'unknown device' status.
- ✗
The UUID of the physical volume has changed due to a disk replacement
Why it's wrong here
When a disk is replaced, the new device's PV UUID differs from the original, so LVM treats it as a brand-new physical volume; the old PV is considered missing, appearing as 'unknown device' only if its device node is gone. If /dev/sdb1 is present with a changed UUID, LVM would display it as an unrecognized PV, not cloak it as 'unknown device.' A deliberate filter exclusion, not a UUID change, is what prevents the PV from being scanned and identified.
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX200 question from scratch — 127 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 EX200 practice question is part of Courseiva's free Red Hat 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 EX200 exam.