Refer to the exhibit. A Linux system fails to boot with a kernel panic. The dmesg output shows the disk is detected and partitions are recognized. Which of the following is the most likely cause of the kernel panic?
Kernel panic after disk and partition detection indicates the kernel cannot mount the root filesystem. An incorrect root= parameter points to a non-existent device, so the kernel halts with a panic once it fails to locate the root filesystem.
Why this answer
A is correct because the kernel panic occurs after the disk and partitions are detected, indicating the kernel can see the hardware but cannot mount the root filesystem. The most common cause is an incorrect or missing `root=` kernel parameter in the bootloader configuration (e.g., GRUB), which specifies the root device (e.g., `/dev/sda1` or `UUID=...`). If this parameter points to a non-existent or wrong partition, the kernel cannot pivot to the root filesystem, leading to a panic.
Exam trap
The trap here is that candidates see the disk is detected and assume hardware is fine, then incorrectly blame the SATA controller or initramfs, missing the subtle point that the kernel panic occurs specifically because the root filesystem cannot be mounted due to a misconfigured `root=` parameter.
How to eliminate wrong answers
Option B is wrong because if the SATA controller module were missing from the initramfs, the disk would not be detected at all, but the dmesg output shows the disk is detected and partitions are recognized. Option C is wrong because the SATA controller is clearly supported by the kernel, as the disk is detected and partitions are recognized, contradicting a lack of support. Option D is wrong because bad sectors causing read errors would typically produce I/O errors or filesystem corruption messages, not a kernel panic at the stage where the root filesystem cannot be mounted; the panic occurs before any filesystem read attempts.