Kernel Panic: Unable to Mount Root FS on Unknown Block
A technician is troubleshooting a system that fails to boot after adding a new SATA SSD and editing /etc/fstab. The error message is 'Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,17)'. What is the most likely issue?
Quick Answer
The answer is an incorrect root filesystem UUID in /etc/fstab. This error occurs because the kernel, upon encountering the unknown-block(8,17) designation, cannot match the specified filesystem identifier to any available partition; block device 8,17 corresponds to /dev/sdb1, meaning the device exists but the UUID in the fstab entry does not match the actual partition’s UUID, causing the mount to fail and triggering the kernel panic. On the LPIC-2 exam, this scenario tests your understanding of block device naming and the boot process, often appearing as a trap where candidates mistakenly suspect a missing driver or hardware failure rather than a simple configuration mismatch. A common memory tip is to think of the “unknown block” as a UUID mismatch—always verify with blkid or lsblk that the UUID in /etc/fstab matches the root partition’s actual identifier.
⚠ Common exam trap
Candidates often confuse a missing initramfs with an incorrect fstab entry, but the specific block device number proves the kernel sees the disk, so the issue is a mount configuration error, not a driver or initramfs problem.
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 root filesystem UUID in /etc/fstab is incorrect.
The error 'unknown-block(8,17)' indicates the kernel cannot find the root filesystem. Block device 8,17 corresponds to /dev/sdb1 (major 8 for SCSI/SATA, minor 17). The most likely cause is an incorrect UUID in /etc/fstab, which prevents the system from mounting the root partition. The kernel can see the device, but the mount fails because the UUID specified does not match any available partition.
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 root filesystem UUID in /etc/fstab is incorrect.
Why this is correct
Incorrect UUID leads to unknown-block error.
- ✗
The kernel image is missing.
Why it's wrong here
Missing kernel would prevent any boot messages.
- ✗
The kernel lacks SATA driver support.
Why it's wrong here
Most kernels include SATA drivers.
- ✗
The initramfs was not regenerated after adding the disk.
Why it's wrong here
Initramfs regeneration is not required for an additional disk unless the root filesystem changes.
Go deeper
Related to this question
About these practice questions
Courseiva writes every LPIC-2 question from scratch — 507 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 →
Same concept, more angles
2 more ways this is tested on LPIC-2
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A systems administrator is troubleshooting a server that fails to boot after a kernel upgrade. The boot process hangs at the stage where the kernel attempts to mount the root filesystem. Which of the following is the most likely cause?
hard- ✓ A.The root= parameter in the kernel command line points to a non-existent device.
- B.The root filesystem is formatted with an unsupported filesystem type.
- C.The initrd image is missing from the /boot partition.
- D.The GRUB bootloader is not installed on the MBR.
Why A: When the kernel fails to mount the root filesystem during boot, the most common cause is an incorrect or missing `root=` parameter in the kernel command line. This parameter specifies the device (e.g., `/dev/sda1` or `UUID=...`) that the kernel should mount as the root filesystem; if it points to a non-existent device, the kernel cannot proceed past the mount stage, resulting in a hang or kernel panic.
Variation 2. A server with a custom kernel fails to boot after a kernel update. The system displays a kernel panic: 'VFS: Unable to mount root fs on unknown-block(0,0)'. The root filesystem is on an LVM volume. What is the most likely cause?
hard- A.The GRUB configuration is pointing to the wrong kernel partition.
- B.The kernel does not have the necessary device drivers compiled in.
- C.The root filesystem is formatted with an unsupported filesystem.
- ✓ D.The initramfs is missing LVM support.
Why D: The kernel panic 'VFS: Unable to mount root fs on unknown-block(0,0)' indicates the kernel cannot locate the root filesystem. Since the root filesystem resides on an LVM volume, the initramfs must contain LVM tools and modules to activate the volume group and logical volumes before the kernel can mount the root. If the initramfs was not rebuilt after the kernel update, it will lack LVM support, causing the boot failure.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LPIC-2 practice question is part of Courseiva's free LPI 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 LPIC-2 exam.