Troubleshooting Scenario Questions

The root filesystem is formatted with an unsupported filesystem type.

Why wrong: This would typically produce an error message, not a hang.

The initrd image is missing from the /boot partition.

Why wrong: An initrd is not always required; the kernel can mount root directly.

The GRUB bootloader is not installed on the MBR.

Why wrong: This would prevent the bootloader from loading entirely, not cause a hang at root mount.

The DHCP server did not provide DNS server information.

Why wrong: Even if DHCP provides DNS servers, the client's network configuration tool may overwrite /etc/resolv.conf. The presence of only 127.0.0.1 indicates a local resolver, not missing DHCP option.

The /etc/resolv.conf file is a symbolic link to /run/NetworkManager/resolv.conf.

Why wrong: A symlink would still reflect the content pointed to; the issue is the content itself pointing to loopback.

The /etc/resolv.conf file is not being updated by the DHCP client.

Why wrong: The file exists with content, so it is being updated, but with the wrong content.

nsenter -t 1234 -n ip addr show

Why wrong: Requires process PID; not for named namespace.

unshare -n ip addr show

Why wrong: Creates new namespace, does not use existing one.

ip netns add ns1

Why wrong: Only adds namespace, does not execute command.

host -l example.com primary

Why wrong: host -l also requests a zone transfer, but may not work if transfers are restricted or the command is not available.

dig -x 192.0.2.1 @primary

Why wrong: dig -x performs a reverse lookup, not a zone transfer.

nslookup -type=any example.com primary

Why wrong: nslookup -type=any queries for all record types, not a full zone transfer.

The kernel image is corrupted.

Why wrong: Corrupted kernel would cause a different panic or fail to execute.

The init process is missing.

Why wrong: Init missing causes panic later, not VFS error.

The root filesystem is formatted with an unsupported filesystem.

Why wrong: Unsupported filesystem would show different error like 'unknown filesystem type'.

The module has not been signed for Secure Boot

Why wrong: Secure Boot issues produce a 'Required key not available' error, not 'Unknown symbol'.

The module's dependencies are missing

Why wrong: Missing dependencies produce 'Unknown symbol' for symbols in dependencies, but the primary cause is usually a version mismatch.

The module name conflicts with a built-in driver

Why wrong: A name conflict would result in 'Module already present' or similar, not unknown symbols.

The kernel image is missing.

Why wrong: Missing kernel would prevent any boot messages.

The kernel lacks SATA driver support.

Why wrong: Most kernels include SATA drivers.

The initramfs was not regenerated after adding the disk.

Why wrong: Initramfs regeneration is not required for an additional disk unless the root filesystem changes.

The default policy is ACCEPT, so the DROP rule is ignored.

Why wrong: The DROP rule is explicit and overrides the default policy for matched packets.

The conntrack module is not loaded, so the state matching fails.

Why wrong: If conntrack were not loaded, the rules would fail entirely; SSH would not work at all.

The rules are in the wrong order; the DROP rule should be before the SSH rule.

Why wrong: Order is correct: established/related first, then new SSH, then drop.

The kernel configuration has disabled module loading.

Why wrong: If module loading is disabled, the error would be different.

The modules have incorrect file permissions.

Why wrong: Permission errors would be 'Permission denied', not 'Exec format error'.

The modules are not properly ordered in the dependency file.

Why wrong: Dependency order does not cause exec format errors.

The /etc/hosts file contains an entry that overrides the DNS resolution for external domains.

Why wrong: An override in hosts would affect all resolution for that hostname, not just external.

The nmblookup service is not running.

Why wrong: nmblookup is for NetBIOS name resolution, not DNS.

The /etc/nsswitch.conf file is missing the 'dns' service in the 'hosts' line.

Why wrong: Missing dns would prevent any DNS resolution, but the question states ping to internal IPs works, so DNS is partially working.

Run lsblk to list all block devices.

Why wrong: lsblk only lists devices already recognized by the kernel.

Check dmesg output for errors.

Why wrong: dmesg is useful after lspci to diagnose driver issues.

Run fdisk -l /dev/nvme0n1 to probe the drive.

Why wrong: fdisk requires the device to be present.

Check the routing table on the remote server.

Why wrong: The remote server is reachable from other hosts, so its routing is likely fine.

Ping the remote server from another host on the same subnet to verify connectivity.

Why wrong: The problem states that other hosts can reach it, so this step is unnecessary.

Traceroute to the remote server from the affected server.

Why wrong: While traceroute can help, the most direct isolation steps are ARP and firewall checks.

The GRUB configuration is pointing to the wrong kernel partition.

Why wrong: The error is about mounting root fs, not kernel location.

The kernel does not have the necessary device drivers compiled in.

Why wrong: Drivers may be present but LVM activation fails.

The root filesystem is formatted with an unsupported filesystem.

Why wrong: The error is about unknown-block, not filesystem type.

A DNAT rule is also needed to translate the destination address.

Why wrong: DNAT is not needed; the source is being masqueraded, but the destination is the actual server.

A route must be added on the 10.0.0.0/24 network pointing back to 10.0.0.1.

Why wrong: The server is the gateway, so return traffic will go through it; no extra route needed if the server is the default gateway for 10.0.0.0/24.

The IP address 10.0.0.1 is not configured on the external interface.

Why wrong: The server has IP 10.0.0.1, which is the source address for masqueraded traffic.

root=/dev/sda1

Why wrong: Already present in the command line; the kernel knows the root device but can't access it.

noprompt

Why wrong: Disables prompts; irrelevant to the mount failure.

rootfstype=ext4

Why wrong: Specifies filesystem type, but the panic indicates missing device, not invalid superblock.

single

Why wrong: Boots into single-user mode; does not fix device detection.