Troubleshooting practice questions

dpkg -l package

Why it fails: dpkg -l lists installed packages and their versions from the local dpkg database, ignoring configured repositories entirely. It is tempting because it reports versions, but it shows what is installed, not the candidate available for upgrade; apt-cache policy or apt list displays the candidate.

apt-show-versions package

Why it fails: apt-show-versions reports installed versions and their distribution status, not the candidate version a repository would supply. It is tempting because it queries APT metadata, but it answers which release a package came from; apt-cache policy or apt list --upgradable shows the candidate.

apt-get -s install package

Why it fails: apt-get -s install simulates installation, showing what would be fetched and changed, but its output does not cleanly present the candidate version field. It is tempting because -s previews actions, yet apt-cache policy or apt list explicitly reports the candidate version from configured repositories.

Run 'ldconfig' to update the library cache

Why it fails: ldconfig rebuilds the dynamic linker cache from libraries already present on disk; it cannot supply the absent libbar.so.2 file. It is tempting because it resolves 'library not found' runtime errors, but it would be correct after installing the missing library, not when the package manager reports an unsatisfied dependency.

Reinstall the 'foo' package using 'rpm -i --force foo.rpm'

Why it fails: Forcing installation with rpm -i --force bypasses dependency checks, leaving foo installed but broken because libbar.so.2 remains absent. It is tempting to silence the error, but it would be correct only when overwriting files from an already-satisfied package, not when a genuine dependency is missing.

Run 'rpm -q --whatrequires libbar.so.2'

Why it fails: rpm -q --whatrequires lists packages depending on libbar.so.2; it identifies consumers rather than locating or installing the provider. It is tempting as a diagnostic query, but it would be correct when assessing the impact of removing a library, not when resolving a missing dependency blocking installation.

Examine configuration files, then check service status and logs, then fix the issue, then restart the service.

Why it fails: This is incorrect because you should first check the service status and logs to understand the error, rather than jumping directly to configuration files without knowing the symptoms.

Check service status and logs, then fix the issue, then examine configuration files, then restart the service.

Why it fails: This is incorrect because you should examine configuration files before fixing the issue, as the fix often involves correcting a misconfiguration. Fixing without proper investigation may not address the root cause.

Restart the service, then check service status and logs, then examine configuration files, then fix the issue.

Why it fails: This is incorrect because restarting the service without diagnosing the problem is futile; you need to first understand why it failed, then apply a fix, then restart.

Run 'sync; echo 3 > /proc/sys/vm/drop_caches' to clear cache.

Why it fails: Dropping page cache frees reclaimable memory, not disk blocks; deleted files still held open by a process keep their space allocated. Clearing caches is tempting as a generic 'free resources' reflex, but the actual fix is restarting or truncating the process holding the deleted file.

Remount the /var partition with the 'noatime' option.

Why it fails: noatime suppresses access-time metadata writes, reducing future I/O; it cannot reclaim space already consumed by deleted-but-open files. It is tempting because mount options commonly address disk-pressure symptoms, but the correct step is finding the process still holding the unlinked file via lsof or /proc.

Run 'df -i' to check inode usage.

Why it fails: df -i reports inode exhaustion, which produces 'no space left' errors while df -h shows free blocks; here blocks were freed by deletion yet not reclaimed, indicating open file handles. Checking inodes is tempting because it explains some full-partition cases, but the stem's symptom points elsewhere.

Use a live CD to run fsck on /dev/md0.

Why it fails: Filesystem corruption would not produce 'unknown-block(0,0)', which indicates the kernel cannot locate the root device at all; fsck requires a mountable filesystem. Running fsck from a live CD is tempting for general boot failures, and it would be correct if the array assembled but the filesystem itself were damaged or inconsistent.

Check the /etc/fstab file for incorrect root device.

Why it fails: The error occurs before the initramfs hands off to the real root, so /etc/fstab is not yet read; an incorrect fstab entry produces a different failure later. Checking fstab is tempting because it defines mount points, and it would be the right action if the system mounted the root but failed to mount secondary filesystems.

Reinstall the bootloader on the MBR.

Why it fails: A missing or misconfigured bootloader yields GRUB errors or a blank screen, not a VFS mount failure; the kernel is already running when this message appears. Reinstalling the bootloader is tempting for any unbootable server, and it would be correct if GRUB itself were corrupted or the MBR overwritten.

`dpkg --info curl.deb`

Why it fails: Displays info from a .deb file, not the installed package.

`apt-get check`

Why it fails: Checks for broken dependencies system-wide, not for a specific package.

The network interface is down.

Why it fails: A down interface would break both queries, yet dig reaches 8.8.8.8 and resolves example.com. The fault lies in host's resolver configuration, not link state. Interface diagnostics belong to scenarios where no name resolution or connectivity succeeds at all, including direct queries to a specified server.

The /etc/hosts file is corrupt.

Why it fails: host consults the resolver configured in /etc/resolv.conf, so a corrupt /etc/hosts would not produce 'Host not found' while dig against 8.8.8.8 succeeds; the resolver configuration is the differing factor. It is tempting because /etc/hosts does affect name resolution, but only for entries it contains.

The DNS server at 8.8.8.8 is not responding.

Why it fails: dig @8.8.8.8 returned a response, proving that server answered the query; the failure lies with the resolver host itself uses. It is tempting because an unreachable DNS server is a common cause of resolution failure, but here the explicit query to that server already succeeded.

-A INPUT -i lo -j LOG

Why it fails: Logs loopback traffic, does not drop.

-A INPUT -p udp -j ACCEPT

Why it fails: Accepts all UDP, would not block traceroute.

-A INPUT -p tcp --dport 80 -j REJECT

Why it fails: Affects TCP port 80, not traceroute (UDP).

ifconfig eth0

Why it fails: ifconfig displays interface addressing, netmask and counters, but no routing information, so it cannot confirm a default gateway exists. It is tempting because the host has a valid 192.168.1.10/24 address, yet local connectivity already works; the missing piece is the route to remote networks.

ping 192.168.1.1

Why it fails: Pinging the gateway only re-tests local reachability, which the scenario already confirms succeeds, and returns no routing-table data. It is tempting as a quick connectivity check, but the fault lies beyond the gateway; the routing table must be inspected to confirm a default route exists.

arp -n

Why it fails: ARP maps IPv4 addresses to MAC addresses on the local segment, so it only reveals layer-2 neighbours, not routing entries. It is tempting because the gateway pings successfully, suggesting name or neighbour resolution, but the failing target is remote; the routing table, not the ARP cache, holds the default route.

iptables -L

Why it fails: iptables -L lists filter-table rules but prints no rule numbers, so the admin cannot reference a rule for deletion or insertion. It is tempting because it shows the chains and targets, and would be correct when only the matching rules matter, not their positions.

iptables -t raw -L

Why it fails: Shows raw table, not relevant for SSH filtering.

iptables -t nat -L

Why it fails: Shows NAT table, not filter table for SSH.

The init binary is missing or corrupted.

Why it fails: A missing init binary produces a different panic after the root filesystem mounts; this error occurs before init runs, when the kernel cannot locate or mount the root device, typically from a wrong root= parameter or absent initramfs module.

The root filesystem is corrupted and needs fsck.

Why it fails: Filesystem corruption surfaces as I/O or fsck errors once the device is found; unknown-block(0,0) means the kernel never identified a mountable root device, so it points to missing storage drivers or an incorrect root= kernel argument.

The boot loader is not installed correctly.

Why it fails: A misconfigured boot loader prevents the kernel from loading at all, producing a boot prompt or GRUB error; here the kernel has loaded and panicked, so the failure lies in locating the root device, not in the loader's installation.

rmmod

Why it fails: rmmod removes a module from the running kernel. It is the opposite of what is needed when a driver is missing, and it cannot identify PCI hardware or load a module. Using it here would not help detect or enable the network card and could disrupt other working drivers if misused.

ifconfig -a

Why it fails: ifconfig -a displays all network interfaces, including those that are down, but it does not identify PCI devices or load kernel modules. If the driver is missing, the interface may not appear at all, so this command cannot reveal the underlying hardware. It also does not provide vendor or device IDs.

lsusb -v

Why it fails: lsusb -v provides detailed information about USB devices, not PCI devices. A network card installed in a PCIe slot will not appear in lsusb output, so this command cannot identify the hardware or its driver. It is useful for USB peripherals but irrelevant to the described PCI network card.

fuser -m /var

Why it fails: fuser -m lists processes using any file on the specified mount point, but it does not distinguish deleted files from active ones and produces a bare PID list. It may show many unrelated processes and does not confirm which one holds the unlinked file, making it a weaker diagnostic than a link-count filter.

df -i /var

Why it fails: The -i option reports inode usage rather than block usage. It would reveal whether the filesystem has run out of inodes, which is a different failure mode, but it cannot show which process holds a deleted file open. The applications reported a space problem, not an inode exhaustion problem.

du -sh /var

Why it fails: du walks directory entries and sums apparent file sizes. Because a deleted file no longer appears in any directory, du cannot see the space it occupies, which is why du and df disagree in this scenario. Running it would simply confirm the undercount rather than identify the holding process.

At the GRUB menu, press c to open the command line and run the normal command.

Why it fails: Pressing c drops into the GRUB command shell, which is useful for manually loading modules and booting a kernel when the menu is broken. It does not present the existing entry with its kernel line for simple editing, so appending parameters there requires manually specifying the kernel and initrd paths. It is a heavier, error-prone approach compared with editing the entry directly.

Boot normally, then use sysctl -w to apply the parameters and reboot.

Why it fails: sysctl adjusts runtime kernel parameters exposed under /proc/sys, such as network or memory tunables. Kernel boot parameters passed on the command line, like those controlling console or early initramfs behavior, are consumed during early boot and cannot be set through sysctl. This approach also cannot affect the pre-boot hang because it requires a successful boot first.

Edit /etc/default/grub, add the parameters to GRUB_CMDLINE_LINUX, and reboot.

Why it fails: Editing /etc/default/grub and regenerating the configuration makes a persistent change to the boot menu entries. That alters the system permanently for every future boot, which contradicts the requirement for a temporary, one-time parameter addition. It also requires running the configuration generator afterward, so it is both persistent and more steps than needed.

cat /etc/nsswitch.conf

Why it fails: The nsswitch.conf file determines the order of name service sources (e.g., files, dns), but it does not show the actual DNS servers or their status. It is useful for checking if DNS is used at all, but not for identifying the specific DNS servers in use.

nslookup google.com

Why it fails: nslookup also queries the default resolver and provides an answer or error, but it does not display the underlying DNS server configuration or the resolution path. It is less informative than resolvectl for diagnosing systemd-resolved issues.

dig google.com

Why it fails: dig google.com queries the default resolver, but if the resolver is misconfigured, it may fail or return an error. It does not show which DNS servers are being used or the resolution path, so it is not the best tool for determining the actual DNS configuration.

systemctl list-units --state=failed

Why it fails: This command lists failed units, which may indicate problems but does not provide timing information about boot performance. A failed unit could cause delays, but the command itself does not show how long units took or which are on the critical path.

journalctl -b -p err

Why it fails: journalctl -b -p err shows error-priority messages from the current boot, which can indicate failures but does not measure timing or identify slow units. It is useful for diagnosing what went wrong, but not for analyzing boot performance or duration.

dmesg | grep -i 'time'

Why it fails: dmesg shows kernel ring buffer messages, and grepping for 'time' may show timestamp-related kernel messages, but it does not provide systemd unit timing or boot performance analysis. Kernel messages are not organized by unit and do not measure service startup durations.