Courseiva

CCNA Linux Kernel and System Startup Questions

75 of 78 questions · Page 1/2 · Linux Kernel and System Startup · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

An administrator wants to ensure a kernel module is loaded automatically at boot for a hardware device. Which file should be modified to add the module name?

A./etc/modprobe.d/blacklist.conf
B./etc/udev/rules.d/
C./etc/modules-load.d/
D./proc/sys/kernel/
AnswerC

Files in /etc/modules-load.d/ specify modules to load at boot.

Why this answer

Option C is correct because the `/etc/modules-load.d/` directory contains configuration files that list kernel module names to be loaded automatically at boot by the `systemd-modules-load.service`. This is the standard mechanism in modern Linux distributions using systemd to ensure specific modules are loaded early in the boot process, before udev or other services handle device detection.

Exam trap

The trap here is that candidates confuse the static boot-time module loading mechanism (`/etc/modules-load.d/`) with the dynamic device-driven module loading via udev rules (`/etc/udev/rules.d/`), mistakenly thinking udev is the correct place to force a module to load at boot regardless of device presence.

How to eliminate wrong answers

Option A is wrong because `/etc/modprobe.d/blacklist.conf` is used to prevent a kernel module from being loaded, not to force its loading at boot. Option B is wrong because `/etc/udev/rules.d/` contains udev rules that trigger actions based on device events (like loading modules when hardware is detected), but it does not directly specify modules to load automatically at boot independent of device events. Option D is wrong because `/proc/sys/kernel/` is a virtual filesystem for runtime kernel parameters (sysctl), not a configuration file for loading modules at boot.

Practice this question →
2
Multi-Selectmedium

Which TWO commands can be used to rebuild the initramfs on modern Linux systems? (Choose two.)

Select 2 answers
A.dracut -f
B.mkinitrd
C.update-initramfs -u
D.grub-mkconfig
E.mkinitramfs
AnswersA, C

Correct for Red Hat-based systems.

Why this answer

Option A is correct because `dracut -f` forces the regeneration of the initramfs on modern Red Hat–based distributions (e.g., RHEL, CentOS, Fedora). Option C is correct because `update-initramfs -u` updates the initramfs on Debian/Ubuntu systems by rebuilding the current kernel's initramfs image. Both commands are the standard tools for rebuilding the initial RAM filesystem on their respective distributions.

Exam trap

The trap here is that candidates often confuse `mkinitrd` (legacy) with `dracut` or `update-initramfs`, or mistakenly think `grub-mkconfig` rebuilds the initramfs when it only updates the bootloader menu.

Practice this question →
3
MCQhard

An administrator needs to ensure a kernel module is never loaded, even if requested. Which file should be used?

A./etc/modprobe.d/deny.conf
B./etc/modprobe.d/blacklist.conf
C./lib/modprobe.d/blacklist.conf
D./etc/modules-load.d/blacklist.conf
AnswerB

Adding 'blacklist <module>' to a .conf file in /etc/modprobe.d/ prevents the module from being loaded automatically.

Why this answer

Option B is correct because the standard mechanism to prevent a kernel module from loading is to add a `blacklist` directive in a file under `/etc/modprobe.d/`, typically named `blacklist.conf`. The `modprobe` utility reads all `.conf` files in this directory, and a `blacklist <module_name>` entry ensures the module is never automatically loaded or loaded via `modprobe`, even if explicitly requested.

Exam trap

The trap here is that candidates confuse the purpose of `/etc/modprobe.d/` (for module options and blacklisting) with `/etc/modules-load.d/` (for loading modules at boot), leading them to choose Option D, which is for loading, not blocking.

How to eliminate wrong answers

Option A is wrong because `/etc/modprobe.d/deny.conf` is not a standard file name; the correct directive is `blacklist`, not `deny`, and the file name is arbitrary but conventionally `blacklist.conf`. Option C is wrong because `/lib/modprobe.d/` is a distribution-provided directory for default settings, not intended for administrator customizations; user modifications should go in `/etc/modprobe.d/` to override defaults. Option D is wrong because `/etc/modules-load.d/` is used to specify modules to load at boot via `systemd-modules-load.service`, not to blacklist modules; blacklisting is handled by `modprobe.d`.

Practice this question →
4
Multi-Selectmedium

Which TWO of the following commands are used to load a kernel module manually at runtime? (Choose two.)

Select 2 answers
A.loadmod
B.depmod
C.modprobe
D.modload
E.insmod
AnswersC, E

Loads a module by name, automatically resolving dependencies.

Why this answer

Both `modprobe` and `insmod` are standard Linux commands for manually loading kernel modules at runtime. `modprobe` is preferred because it automatically resolves and loads module dependencies, while `insmod` inserts a single module file directly without dependency resolution.

Exam trap

The trap here is that candidates may confuse `depmod` (which only builds dependency metadata) with a module-loading command, or assume `loadmod` or `modload` are valid Linux utilities when they are not.

Practice this question →
5
MCQeasy

After installing a new kernel, the system administrator notices that the system boots to the old kernel by default. Which command should be used to update the GRUB configuration to boot the new kernel?

A.grub-install
B.mkinitrd
C.grub-set-default
D.update-grub
AnswerD

update-grub regenerates the GRUB configuration file.

Why this answer

The `update-grub` command (which is a wrapper for `grub-mkconfig -o /boot/grub/grub.cfg`) scans the installed kernels and regenerates the GRUB configuration file, automatically setting the newest kernel as the default boot entry. This ensures the system boots the newly installed kernel on the next reboot.

Exam trap

The trap here is that candidates confuse `grub-install` (which installs the bootloader) with updating the boot menu, or think `grub-set-default` can automatically detect and set the new kernel as default without regenerating the configuration.

How to eliminate wrong answers

Option A is wrong because `grub-install` installs GRUB to the Master Boot Record (MBR) or EFI System Partition (ESP), but does not update the boot menu entries or change the default kernel selection. Option B is wrong because `mkinitrd` (or `dracut`) creates an initial RAM disk image for a specific kernel, but does not modify the GRUB configuration or default boot order. Option C is wrong because `grub-set-default` sets the default boot entry by index or name in the saved default mechanism, but it does not scan for new kernels or regenerate the configuration file; it only changes the default selection within the existing menu.

Practice this question →
6
Multi-Selecthard

Which THREE of the following are standard steps in compiling and installing a custom Linux kernel from source? (Choose three.)

Select 3 answers
A.make modules_install
B.make menuconfig
C.make install
D.make
E.make oldconfig
AnswersB, C, D

This step configures the kernel features and modules before compilation.

Why this answer

Option B is correct because `make menuconfig` is a standard step that launches a text-based menu-driven interface for configuring kernel options before compilation. This step allows the user to select which features, drivers, and modules to include in the kernel build, generating the `.config` file that guides the subsequent compilation.

Exam trap

The trap here is that candidates often confuse `make modules_install` as a core compilation step rather than a post-compilation installation step, and may overlook that `make install` is the standard step for installing the kernel image itself, while `make oldconfig` is a configuration update tool, not a standard step in a fresh build.

Practice this question →
7
Drag & Dropmedium

Order the steps to configure a Linux system as an SSH server with key-based authentication.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

Install SSH server, configure it, generate keys, copy public key, restart and test.

Practice this question →
8
MCQeasy

An administrator wants to disable the graphical splash screen during boot. What change should be made in /etc/default/grub?

A.Set GRUB_CMDLINE_LINUX="nosplash"
B.Remove 'quiet' from GRUB_CMDLINE_LINUX_DEFAULT
C.Set GRUB_TIMEOUT=0
D.Remove 'splash' from GRUB_CMDLINE_LINUX_DEFAULT
AnswerD

The 'splash' parameter enables the graphical splash screen; removing it disables it.

Why this answer

Option D is correct because the graphical splash screen during boot is controlled by the 'splash' kernel parameter. Removing 'splash' from GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub disables the splash screen, allowing verbose boot messages to be displayed. This parameter is passed to the kernel via the bootloader, and its absence prevents the plymouth or similar splash service from activating.

Exam trap

The trap here is that candidates often confuse 'quiet' with 'splash', thinking that removing 'quiet' alone disables the splash screen, when in fact 'splash' is the specific parameter controlling the graphical boot animation.

How to eliminate wrong answers

Option A is wrong because 'nosplash' is not a valid kernel parameter; the correct parameter to disable the splash screen is the absence of 'splash', not a negative parameter. Option B is wrong because removing 'quiet' only enables verbose kernel messages but does not disable the splash screen; the splash screen can still appear even without 'quiet'. Option C is wrong because GRUB_TIMEOUT=0 only sets the boot menu timeout to zero, skipping the menu, and has no effect on the graphical splash screen during boot.

Practice this question →
9
MCQhard

During kernel development, a developer modifies only a few source files in a module directory. Which make target should be used to rebuild only that module without compiling the entire kernel?

A.make oldconfig && make
B.make M=./drivers/net
C.make modules
D.make modules_install
AnswerB

The M parameter specifies the directory of the module to compile, useful for external modules or partial rebuilds.

Why this answer

Option B is correct because the `M=./drivers/net` argument tells the kernel build system to build only the module(s) in the specified directory as external modules, without recompiling the entire kernel tree. This is the standard way to rebuild a single kernel module after modifying its source files, leveraging the already configured kernel build environment.

Exam trap

The trap here is that candidates confuse `make modules` (which builds all modules) with the `M=` syntax (which targets a specific module directory), leading them to choose option C instead of B.

How to eliminate wrong answers

Option A is wrong because `make oldconfig && make` would first update the kernel configuration (which is unnecessary if only source files changed) and then rebuild the entire kernel, not just the modified module. Option C is wrong because `make modules` compiles all kernel modules that are enabled in the configuration, not a single module directory. Option D is wrong because `make modules_install` only installs already-built modules into the filesystem (e.g., /lib/modules) and does not perform any compilation.

Practice this question →
10
MCQmedium

A system administrator has multiple kernel modules that depend on each other. Module A must be loaded before module B. How can this dependency be ensured automatically when using modprobe?

A.Use depmod to generate dependency information
B.Use insmod to load module A first, then module B in a startup script
C.Add options module_a softdep=module_b to /etc/modprobe.d/
D.Add module B to the /etc/modules file
AnswerC

The softdep option in modprobe.conf allows specifying pre- and post-dependencies, ensuring module A is loaded before module B.

Why this answer

Option C is correct because the `softdep` directive in a modprobe configuration file (e.g., `/etc/modprobe.d/*.conf`) allows you to declare a soft dependency where one module should be loaded before another, without creating a hard dependency in the module symbol table. When `modprobe` processes this directive, it ensures that module A is loaded before module B automatically, even if there is no explicit symbol dependency between them.

Exam trap

The trap here is that candidates often confuse `depmod` (which resolves symbol-based dependencies) with `softdep` (which resolves ordering dependencies without symbol links), leading them to incorrectly choose Option A as the automatic solution.

How to eliminate wrong answers

Option A is wrong because `depmod` generates the `modules.dep` file based on symbol dependencies (e.g., exported symbols used by other modules), not arbitrary ordering requirements like 'A must load before B' when no symbol dependency exists. Option B is wrong because using `insmod` in a startup script is a manual, non-automated approach that bypasses `modprobe`'s dependency resolution and does not leverage the system's module dependency framework. Option D is wrong because `/etc/modules` (or `/etc/modules-load.d/`) is used to specify modules to be loaded at boot time, but it does not enforce load ordering between modules; it simply lists modules to load, and the kernel may load them in an unspecified order.

Practice this question →
11
MCQhard

An administrator wants to limit the size of the kernel ring buffer to prevent memory overflow. Which kernel boot parameter should be used?

A.log_buf_len
B.log_size
C.kernel.log.size
D.dmesg_size
AnswerA

log_buf_len sets the kernel log buffer size (e.g., log_buf_len=4M).

Why this answer

Option A is correct because `log_buf_len` is the kernel boot parameter that explicitly sets the size of the kernel ring buffer (dmesg buffer). By specifying a value (e.g., `log_buf_len=4M`), the administrator can increase or limit the buffer size to prevent memory overflow when a large volume of kernel messages is generated.

Exam trap

The trap here is that candidates may confuse kernel boot parameters with sysctl or configuration file settings, leading them to pick plausible-sounding but nonexistent options like `log_size` or `dmesg_size` instead of the correct `log_buf_len`.

How to eliminate wrong answers

Option B (`log_size`) is wrong because no such kernel boot parameter exists; it is a fictional name that might be confused with the `log_buf_len` parameter. Option C (`kernel.log.size`) is wrong because it resembles a sysctl or kernel configuration parameter, not a boot-time kernel command-line parameter; the kernel ring buffer size is controlled only via `log_buf_len` at boot. Option D (`dmesg_size`) is wrong because it is not a valid kernel boot parameter; `dmesg` is a user-space command to read the ring buffer, and its size is not set via a boot parameter named `dmesg_size`.

Practice this question →
12
MCQhard

A system administrator compiled a custom kernel module for a new hardware device. After copying the .ko file to /lib/modules/$(uname -r)/, the module is not loading automatically at boot. What is the most likely cause?

A.The module needs to be added to /etc/modules.
B.The module has a dependency error.
C.The kernel version does not match the module.
D.The module is blacklisted in /etc/modprobe.d/.
AnswerD

Blacklisted modules are prevented from loading even if installed correctly.

Why this answer

Option D is correct because a blacklist entry in /etc/modprobe.d/ explicitly prevents the kernel from loading the module at boot, regardless of its presence in /lib/modules/$(uname -r)/. The modprobe system reads these configuration files during early boot and skips any module listed with a 'blacklist' directive, which is the most likely cause when a module is present but fails to load automatically.

Exam trap

The trap here is that candidates often assume a module must be explicitly added to a configuration file to load at boot, overlooking that blacklisting is a silent override that prevents automatic loading without any error message.

How to eliminate wrong answers

Option A is wrong because /etc/modules (or /etc/modules-load.d/*.conf) is used to specify modules to load at boot on some distributions, but the module is already present in the correct directory and should load automatically if not blacklisted; adding it there is not the most likely cause. Option B is wrong because a dependency error would typically produce an error message during modprobe or boot, and the module would still be attempted; the question states it is 'not loading automatically at boot' without mentioning errors, making blacklisting more plausible. Option C is wrong because the administrator copied the .ko file to /lib/modules/$(uname -r)/, which matches the running kernel version, so a version mismatch is unlikely.

Practice this question →
13
Multi-Selectmedium

A system fails to boot due to a corrupted initramfs. Which TWO methods can be used to recover? (Choose two.)

Select 2 answers
A.Edit GRUB command line to add 'init=/bin/bash' and then rebuild initramfs from that shell
B.Reinstall the kernel package from the GRUB command line using a network boot
C.Use kexec to boot a different kernel
D.Use the rescue mode of the installation media (e.g., RHEL rescue, Ubuntu recovery)
E.Boot with a live CD, chroot to the system, and rebuild initramfs
AnswersD, E

Rescue mode provides a minimal environment to repair the system.

Why this answer

Option D is correct because booting from installation media (e.g., RHEL rescue or Ubuntu recovery) provides a minimal environment that can mount the root filesystem, chroot into it, and then rebuild the initramfs using the system's own kernel and modules. This method does not require a working initramfs on the disk, as the rescue environment supplies its own kernel and initial RAM disk.

Exam trap

The trap here is that candidates often think 'init=/bin/bash' is a universal recovery method, but it fails to provide a functional environment for rebuilding initramfs because the root filesystem is not fully mounted and critical tools are missing.

Practice this question →
14
MCQhard

A company has a fleet of servers running a custom Linux kernel version 5.4. They have developed several in-house kernel modules that interface with proprietary hardware. Due to a security vulnerability, the company decides to upgrade all servers to kernel version 5.10. After upgrading the kernel on a test server, the custom modules fail to load with the error 'Invalid module format' or 'disagrees about version magic'. The system administrator must resolve this issue for all servers. The modules are closed-source and cannot be modified easily. The administrator considers the following options. Question: What is the most effective course of action to load the custom modules on the new kernel?

A.Recompile the custom kernel modules against the new kernel headers and install them.
B.Use modprobe with the --force-vermagic option to bypass the version check.
C.Update the version magic string in the module binary by patching the file.
D.Use systemd-modules-load to load the modules later in the boot process.
AnswerA

Recompiling ensures the modules match the new kernel's version magic and ABI.

Why this answer

Option A is correct because the custom kernel modules were compiled against the version magic string of kernel 5.4. Kernel 5.10 has a different version magic (which includes the kernel version, SMP/preemption settings, and compiler version). Recompiling the modules against the new kernel headers regenerates the correct version magic, allowing the modules to load without error.

Since the modules are closed-source, recompilation is not possible in practice, but the question states the administrator considers options; recompilation is the only technically valid method to resolve the version magic mismatch.

Exam trap

The trap here is that candidates may think modprobe has a --force-vermagic option (Option B) or that patching the binary is straightforward (Option C), but the LPIC-2 exam expects knowledge that only recompilation against the correct kernel headers resolves version magic mismatches, and that force-loading is a temporary, risky workaround.

How to eliminate wrong answers

Option B is wrong because modprobe does not support a --force-vermagic option; the correct modprobe option is --force-modversion or the kernel's module loading can be forced via 'insmod -f', but this bypasses the version magic check entirely, which is insecure and may cause undefined behavior or crashes. Option C is wrong because patching the version magic string in a compiled kernel module binary is extremely fragile, requires deep knowledge of the ELF structure and vermagic section layout, and is not a reliable or maintainable solution for a fleet of servers. Option D is wrong because systemd-modules-load simply loads modules at a later boot stage; it does not alter the version magic check, so the modules will still fail to load with the same error.

Practice this question →
15
MCQhard

During boot, a server's video driver causes a freeze. At the GRUB2 menu, the administrator needs to interactively add the kernel parameter 'nomodeset' to the boot entry. Which key should be pressed to access the kernel command line editor?

A.a
B.e
C.Tab
D.c
AnswerB

Pressing 'e' allows editing the selected boot entry's commands and kernel parameters.

Why this answer

Option B is correct because pressing 'e' at the GRUB2 menu enters the edit mode for the selected boot entry, allowing the administrator to modify kernel parameters interactively. This is the standard GRUB2 keybinding to access the kernel command line editor, where 'nomodeset' can be added to the 'linux' line to disable kernel mode-setting and prevent the video driver from freezing during boot.

Exam trap

The trap here is that candidates confuse the GRUB2 interactive editor key 'e' with the GRUB legacy 'a' (append) or 'c' (command line), leading them to choose options that do not provide the full editing capability required to modify kernel parameters like 'nomodeset'.

How to eliminate wrong answers

Option A is wrong because pressing 'a' in GRUB2 appends kernel parameters to the boot command line without entering a full editor, which is less flexible and not the standard interactive editor for modifying boot entries. Option C is wrong because pressing Tab in GRUB2 typically cycles through boot entries or shows available completions, but does not open the kernel command line editor for parameter modification. Option D is wrong because pressing 'c' in GRUB2 opens the GRUB command-line interface (a shell-like environment), not the kernel command line editor for the current boot entry.

Practice this question →
16
MCQmedium

During boot, the kernel panics because the root filesystem cannot be mounted. Which kernel parameter should be added at the GRUB prompt to try an alternative root device?

A.root=/dev/sdb1
B.init=/bin/sh
C.rescue
D.single
AnswerA

The root= parameter explicitly specifies the root device.

Why this answer

The kernel parameter 'root=' specifies the device for the root filesystem. When the default root device fails to mount, adding 'root=/dev/sdb1' at the GRUB prompt overrides the compiled-in root and tells the kernel to attempt mounting from that alternative block device. This is the standard method to redirect the root mount during boot troubleshooting.

Exam trap

The trap here is that candidates confuse kernel parameters with bootloader commands or init system targets, mistakenly thinking 'rescue' or 'single' can fix a root device failure when they only affect post-mount behavior.

How to eliminate wrong answers

Option B is wrong because 'init=/bin/sh' specifies an alternative init program (a shell) to run after the root filesystem is mounted, but it does not change which device the kernel attempts to mount as root; the kernel will still panic if the root device itself is inaccessible. Option C is wrong because 'rescue' is not a valid kernel parameter; it is a systemd target or a GRUB menu entry label, not a parameter passed to the kernel to alter root device selection. Option D is wrong because 'single' sets the runlevel to single-user mode, which only affects the init process after a successful root mount; it does not change the root device and cannot prevent a kernel panic from a missing root filesystem.

Practice this question →
17
MCQhard

A developer has compiled a custom kernel with a new feature. The kernel modules are installed in /lib/modules/$(uname -r)/. However, when the system boots, the kernel fails to load some modules with 'Exec format error'. What is the most likely cause?

A.The kernel configuration has disabled module loading.
B.The modules were compiled against a different kernel version.
C.The modules have incorrect file permissions.
D.The modules are not properly ordered in the dependency file.
AnswerB

Exec format error occurs when module version doesn't match kernel.

Why this answer

The 'Exec format error' indicates that the kernel module binary is incompatible with the running kernel. This most commonly occurs when modules are compiled against a different kernel version (e.g., different kernel source tree or configuration), as the module's vermagic string must exactly match the kernel's vermagic. The kernel's module loader checks this version magic before loading; a mismatch causes the exec format error.

Exam trap

The trap here is that candidates confuse 'Exec format error' with file permission or dependency issues, but the error specifically points to an incompatible binary format, which is a hallmark of kernel version mismatch.

How to eliminate wrong answers

Option A is wrong because if module loading were disabled in the kernel configuration (CONFIG_MODULES=n), the kernel would not attempt to load modules at all, and the error would be different (e.g., 'module loading disabled') or modules would simply not be found. Option C is wrong because incorrect file permissions (e.g., not readable) would produce a 'Permission denied' error, not 'Exec format error'. Option D is wrong because improper ordering in the dependency file (modules.dep) would cause dependency resolution failures (e.g., 'Unknown symbol' or 'Required key not available'), not an exec format error, which is a binary format mismatch.

Practice this question →
18
MCQhard

A system administrator is responsible for a production server running a custom-compiled Linux kernel version 5.15. After a routine update of the kernel source and recompilation, the server fails to boot. The error message on the console is: 'Kernel panic - not syncing: No working init found. Try passing init= option to kernel.' The administrator verifies that the root filesystem is intact by booting from a live USB and mounting the root partition. The filesystem contains the usual /sbin/init (symlinked to systemd). The administrator also checks the boot loader configuration and sees that the kernel command line includes 'root=/dev/sda1 ro'. The init binary exists and is executable. Which of the following is the most likely cause of this boot failure?

A.The boot loader's 'initrd' directive is missing or points to a non-existent file
B.The kernel was compiled without support for the ext4 filesystem
C.The init binary is missing or corrupted
D.The root filesystem is corrupted and cannot be mounted properly
AnswerA

Without an initramfs, the kernel may fail to properly set up the root filesystem, causing 'No working init found' if the initramfs was expected to contain the init or necessary modules.

Why this answer

The error 'No working init found' indicates the kernel successfully mounted the root filesystem but could not execute the init binary. Since the administrator confirmed the init binary exists and is executable on the root partition, the most likely cause is that the kernel did not have access to the necessary drivers or modules to properly access the root filesystem at boot time. The missing or misconfigured initrd (initial RAM disk) directive means the kernel lacks the temporary root filesystem containing essential modules (e.g., storage controller drivers) needed to mount the real root filesystem, leading to the kernel falling back to a failed init search.

Exam trap

LPI often tests the misconception that 'No working init found' always means the init binary is missing or corrupted, when in fact it often results from the kernel being unable to access the root filesystem due to a missing initrd or missing storage drivers.

How to eliminate wrong answers

Option B is wrong because if the kernel lacked ext4 support, the root filesystem would fail to mount entirely, resulting in a 'VFS: Cannot open root device' error, not a 'No working init found' message. Option C is wrong because the administrator explicitly verified that the init binary exists and is executable on the root partition. Option D is wrong because the administrator confirmed the root filesystem is intact by mounting it from a live USB, and a corrupted filesystem would typically produce I/O errors or a 'mount: unknown filesystem type' message, not a successful mount followed by an init failure.

Practice this question →
19
MCQeasy

A system fails to boot with a kernel panic: 'Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)'. The administrator suspects the root filesystem is not being detected. Which kernel parameter should be checked first?

A.init=/sbin/init
B.root=/dev/sda1
C.ro
D.panic=10
AnswerB

The root parameter tells the kernel which device to mount as root.

Why this answer

The kernel panic 'VFS: Unable to mount root fs on unknown-block(0,0)' indicates the kernel cannot locate the root filesystem. The 'root=' kernel parameter specifies the device for the root filesystem (e.g., root=/dev/sda1). Checking this parameter first is critical because if it is missing, incorrect, or the device name is wrong, the kernel will fail to mount the root filesystem and panic.

Exam trap

The trap here is that candidates often confuse kernel parameters that affect boot behavior (like 'ro' or 'panic') with the one that actually tells the kernel where the root filesystem lives, leading them to overlook the 'root=' parameter.

How to eliminate wrong answers

Option A is wrong because 'init=/sbin/init' specifies the path to the init program, not the root filesystem device; it does not affect VFS root mounting. Option C is wrong because 'ro' mounts the root filesystem as read-only, but it does not specify which device to use; the kernel still needs a valid 'root=' parameter. Option D is wrong because 'panic=10' sets a timeout (in seconds) before the kernel reboots after a panic, but it does not help the kernel find or mount the root filesystem.

Practice this question →
20
MCQmedium

An organization is migrating from SysV init to systemd. What systemd command should be used to check the status of the HTTP service?

A.systemd-analyze httpd
B.systemctl list-units httpd
C.systemd status httpd
D.systemctl status httpd
AnswerD

This command shows whether the service is active, enabled, and other details.

Why this answer

The correct command to check the status of a service in systemd is `systemctl status httpd`. This command displays the current state, recent log entries, and process details for the specified unit. The `systemctl` utility is the primary interface for managing systemd services, while `systemd` itself is the init system daemon, not a user-facing command.

Exam trap

The trap here is that candidates confuse `systemd` (the daemon) with `systemctl` (the control tool), leading them to choose `systemd status httpd` instead of the correct `systemctl status httpd`.

How to eliminate wrong answers

Option A is wrong because `systemd-analyze` is used for analyzing boot performance and dependency trees, not for checking service status; `systemd-analyze httpd` would fail as it expects subcommands like `blame` or `critical-chain`. Option B is wrong because `systemctl list-units httpd` lists all loaded units matching the pattern, but it does not show detailed status, logs, or process information; it only shows whether the unit is active or inactive. Option C is wrong because `systemd status httpd` is not a valid command; `systemd` is the system and service manager daemon, not a command-line tool for querying service status.

Practice this question →
21
MCQhard

You are a systems administrator for a company that runs a critical web server on a Linux system. The server has been running stably for months, but after a recent kernel update from version 5.10.0-8 to 5.10.0-9, the server fails to boot. The boot process starts, but after the kernel loads, the system hangs with no output on the console. You have physical access to the server and can interrupt the boot process. The server uses GRUB 2 as the bootloader and the root filesystem is on an LVM logical volume. The previous kernel (5.10.0-8) is still present in /boot. Which of the following is the best course of action to restore the server to a working state?

A.Interrupt the boot process at GRUB, select the advanced options, and boot the old kernel 5.10.0-8.
B.Reinstall GRUB from a live CD to fix the bootloader configuration.
C.Boot from a live CD, chroot into the system, and reinstall the new kernel package.
D.Boot from a live CD, chroot into the system, and rebuild the initrd for the new kernel.
AnswerA

This restores functionality immediately, allowing later troubleshooting of the new kernel.

Why this answer

The server fails to boot after a kernel update, but the previous kernel is still present in /boot. By interrupting GRUB 2 at boot, selecting 'Advanced options for Ubuntu' (or similar), and booting the old kernel 5.10.0-8, you bypass the problematic new kernel without modifying the bootloader or filesystem. This is the fastest, least invasive recovery method because GRUB 2 automatically detects and lists all installed kernels in /boot, including the previous one.

Exam trap

The trap here is that candidates assume the boot process failed due to a corrupted bootloader or initrd, when in fact the kernel itself is the culprit, and the simplest recovery is to boot the previous kernel from GRUB's advanced menu.

How to eliminate wrong answers

Option B is wrong because reinstalling GRUB from a live CD addresses bootloader corruption or missing configuration, but the problem is a kernel-level hang after the kernel loads, not a bootloader failure. Option C is wrong because reinstalling the new kernel package does not fix the underlying issue (e.g., a bug in the kernel or incompatible module); it would reinstall the same broken kernel. Option D is wrong because rebuilding the initrd for the new kernel assumes the issue is a missing or corrupted initramfs, but the system hangs after the kernel loads, indicating the kernel itself is faulty, not the initrd.

Practice this question →
22
Drag & Dropmedium

Arrange the steps to configure a Linux server as an NFS client that mounts a remote export.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

The NFS client needs the nfs-common package, a mount point, an fstab entry, then mounting and verification.

Practice this question →
23
MCQhard

Refer to the exhibit. Which kernel version will be booted by default when using a standard GRUB2 configuration that uses the symlinks vmlinuz and initrd.img?

A.Depends on GRUB_DEFAULT setting, but if not set, it will boot the highest versioned kernel
B.It will prompt to choose between the two kernels
C.5.10.0-9-amd64
D.5.10.0-8-amd64
AnswerC

The symlinks are updated to point to the latest installed kernel, so GRUB uses that as default.

Why this answer

In a standard GRUB2 configuration, the symlinks `vmlinuz` and `initrd.img` point to the latest installed kernel version. When GRUB2 generates its boot menu using `update-grub` (or `grub-mkconfig`), it reads these symlinks to create the default boot entry. Therefore, the default booted kernel is the one pointed to by these symlinks, which in this case is 5.10.0-9-amd64.

Exam trap

The trap here is that candidates assume GRUB2 automatically selects the highest versioned kernel based on version string comparison, when in reality it relies on the symlinks `vmlinuz` and `initrd.img` to determine the default boot entry.

How to eliminate wrong answers

Option A is wrong because GRUB_DEFAULT is typically set to '0' (the first menu entry) by default, not to a version-based selection; the default entry is determined by the order in `/boot/grub/grub.cfg`, which uses the symlinks, not the highest versioned kernel automatically. Option B is wrong because GRUB2 does not prompt to choose between kernels unless the user manually interrupts the boot process or has a custom configuration; the default behavior is to boot the first entry without prompting. Option D is wrong because 5.10.0-8-amd64 is an older kernel version; the symlinks `vmlinuz` and `initrd.img` are updated to point to the newest installed kernel after each kernel package update, so the default boot entry will be 5.10.0-9-amd64.

Practice this question →
24
MCQmedium

A system administrator needs to ensure that a custom kernel module loads automatically at boot. The module is named 'my_driver' and is built for the current kernel. Which configuration file should be modified to ensure the module loads automatically?

A.Add the insmod command in /etc/rc.local
B.Add the module name to /etc/modules.conf
C.Add a configuration file in /etc/modules-load.d/
D.Add a configuration file in /etc/modprobe.d/
AnswerC

/etc/modules-load.d/ is the standard location for specifying modules to load at boot.

Why this answer

Option C is correct because systemd-based Linux distributions use /etc/modules-load.d/ to specify kernel modules that should be loaded automatically at boot. Placing a configuration file (e.g., my_driver.conf) containing the module name 'my_driver' in this directory instructs systemd-modules-load.service to load the module during early boot. This is the modern, distribution-agnostic method for ensuring a custom kernel module loads automatically.

Exam trap

The trap here is that candidates confuse /etc/modprobe.d/ (used for modprobe configuration) with /etc/modules-load.d/ (used for automatic loading), or they assume the legacy /etc/modules.conf is still valid on modern distributions.

How to eliminate wrong answers

Option A is wrong because /etc/rc.local is a legacy script that runs after most services have started, not during early boot when kernel modules are typically loaded; using insmod there may fail if dependencies are not yet met, and it is not the standard mechanism for automatic module loading. Option B is wrong because /etc/modules.conf is an obsolete configuration file used by the old modutils package on 2.4.x kernels; modern systems use /etc/modprobe.d/ for modprobe options and /etc/modules-load.d/ for module loading. Option D is wrong because /etc/modprobe.d/ is used to configure modprobe options (e.g., aliases, blacklists, parameters) but does not cause modules to load automatically at boot; it only affects how modules are loaded when explicitly requested.

Practice this question →
25
Multi-Selectmedium

Which two of the following are valid methods to pass kernel parameters during the boot process? (Choose two.)

Select 2 answers
A.Edit /boot/grub/grub.cfg and append parameters to the 'linux' line
B.Use the 'linux' command in the GRUB 2 interactive shell
C.Use the 'initrd' command in GRUB
D.Write the parameter directly to /proc/cmdline
E.Set the parameter in /etc/sysctl.conf
AnswersA, B

This is a permanent method for GRUB 2.

Why this answer

Option A is correct because editing /boot/grub/grub.cfg to append parameters to the 'linux' line directly modifies the kernel command line that GRUB 2 passes to the Linux kernel at boot. This is a standard method for permanently adding kernel parameters like 'quiet' or 'nomodeset'.

Exam trap

The trap here is that candidates confuse kernel boot parameters with runtime kernel parameters, leading them to select /etc/sysctl.conf or /proc/cmdline, which are not valid for boot-time configuration.

Practice this question →
26
MCQhard

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?

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.
AnswerD

The kernel cannot access the LVM volume without LVM modules in initramfs.

Why this answer

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.

Exam trap

The trap here is that candidates often assume a kernel panic with 'VFS' errors points to a missing kernel driver (Option B), but LVM root mounting depends on the initramfs, not compiled-in kernel drivers.

How to eliminate wrong answers

Option A is wrong because the GRUB configuration pointing to the wrong kernel partition would typically result in a different error, such as 'file not found' or a blank screen, not a VFS mount failure on an LVM volume. Option B is wrong because the kernel does not need device drivers compiled in for LVM; LVM is handled by userspace tools in the initramfs, not by kernel drivers. Option C is wrong because the root filesystem being formatted with an unsupported filesystem would produce a different error, such as 'unknown filesystem type', not 'unknown-block(0,0)', and LVM volumes commonly use ext4 or xfs which are well-supported.

Practice this question →
27
MCQeasy

Which file is used by GRUB2 to load the kernel and initramfs?

A./etc/lilo.conf
B./etc/default/grub
C./boot/grub/menu.lst
D./boot/grub/grub.cfg
AnswerD

GRUB2 uses grub.cfg as its main configuration file.

Why this answer

GRUB2 uses /boot/grub/grub.cfg as its main configuration file, which contains the menu entries, kernel paths, and initramfs locations. This file is generated by update-grub (or grub-mkconfig) based on scripts in /etc/grub.d/ and settings in /etc/default/grub, and it is read directly by the GRUB2 bootloader at boot time to load the kernel and initramfs.

Exam trap

The trap here is that candidates often confuse /etc/default/grub (the user configuration file) with the actual bootloader configuration file /boot/grub/grub.cfg, or they mistakenly associate GRUB2 with the legacy menu.lst file used by GRUB Legacy.

How to eliminate wrong answers

Option A is wrong because /etc/lilo.conf is the configuration file for LILO (LInux LOader), a legacy bootloader that is not used by GRUB2. Option B is wrong because /etc/default/grub is a user-editable file that stores GRUB2 environment variables (e.g., GRUB_DEFAULT, GRUB_TIMEOUT), but it is not read directly by the bootloader; it is used by grub-mkconfig to generate grub.cfg. Option C is wrong because /boot/grub/menu.lst is the configuration file for GRUB Legacy (version 0.97 and earlier), not for GRUB2 (version 1.99+), which uses a different syntax and file structure.

Practice this question →
28
MCQhard

An administrator needs to disable IPv6 on a running system without rebooting and make the change permanent across reboots. Which set of commands should be used?

A.modprobe -r ipv6
B.echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6 && edit /etc/sysctl.conf to add net.ipv6.conf.all.disable_ipv6=1
C.Edit /boot/grub/grub.cfg to add ipv6.disable=1
D.sysctl -w net.ipv6.conf.all.disable_ipv6=1
AnswerB

echo changes the runtime parameter; editing /etc/sysctl.conf makes it permanent. Both steps are necessary.

Why this answer

Option B is correct because it combines a runtime sysctl command to immediately disable IPv6 on the running system without a reboot, and a persistent configuration in /etc/sysctl.conf to ensure the setting survives reboots. The /proc/sys/net/ipv6/conf/all/disable_ipv6 file controls the IPv6 stack at runtime, and sysctl.conf applies the kernel parameter at boot time.

Exam trap

The trap here is that candidates often choose Option D (sysctl -w) alone, forgetting that the question explicitly requires the change to be permanent across reboots, which necessitates editing a persistent configuration file like /etc/sysctl.conf.

How to eliminate wrong answers

Option A is wrong because modprobe -r ipv6 attempts to unload the IPv6 kernel module, but on most modern systems IPv6 is built into the kernel (not a module) or compiled as a module that cannot be removed while in use, and this method does not provide a permanent configuration across reboots. Option C is wrong because editing /boot/grub/grub.cfg to add ipv6.disable=1 is a boot-time kernel parameter that requires a reboot to take effect, and it disables IPv6 entirely at the kernel level, which is not what the question asks (the change must be made on a running system without rebooting). Option D is wrong because while sysctl -w net.ipv6.conf.all.disable_ipv6=1 immediately disables IPv6 on the running system, it does not make the change permanent across reboots — the setting will revert to the default after a reboot unless also added to a persistent configuration file like /etc/sysctl.conf or /etc/sysctl.d/.

Practice this question →
29
Multi-Selectmedium

Which TWO of the following commands can be used to list currently loaded kernel modules? (Choose two.)

Select 2 answers
A.modinfo -l
B.cat /proc/modules
C.ls /lib/modules/$(uname -r)
D.depmod -e
E.lsmod
AnswersB, E

/proc/modules directly shows the kernel's current modules; cat displays it.

Why this answer

Option B is correct because `/proc/modules` is a virtual file maintained by the kernel that lists all currently loaded kernel modules, including their size, usage count, and dependent modules. Reading this file provides a real-time snapshot of the kernel's module state. Option E is correct because `lsmod` is a user-space utility that parses `/proc/modules` and formats the output in a human-readable table, making it the standard command for listing loaded modules.

Exam trap

The trap here is that candidates confuse listing available modules on disk (Option C) with listing currently loaded modules, or mistakenly think `modinfo` or `depmod` can enumerate loaded modules when they are designed for module metadata and dependency resolution, respectively.

Practice this question →
30
MCQhard

Which sysctl parameter controls the system's behavior when a kernel oops occurs (e.g., automatically reboot)?

A.vm.panic_on_oom
B.kernel.unknown_nmi_panic
C.kernel.panic_on_oops
D.kernel.oops
AnswerC

Setting this to 1 causes a panic on oops, which can then trigger a reboot via kernel.panic.

Why this answer

The `kernel.panic_on_oops` sysctl parameter controls the system's behavior when a kernel oops occurs. Setting it to 1 causes the kernel to panic on an oops, and if `kernel.panic` is also set to a positive value (e.g., seconds before reboot), the system will automatically reboot after the panic. This is the correct parameter for triggering a reboot on an oops.

Exam trap

The trap here is that candidates confuse `kernel.panic_on_oops` with `vm.panic_on_oom` or assume a non-existent parameter like `kernel.oops` exists, because both involve panic behavior but apply to entirely different kernel events (oops vs. OOM).

How to eliminate wrong answers

Option A is wrong because `vm.panic_on_oom` controls the system's behavior on an out-of-memory (OOM) condition, not on a kernel oops; it triggers a panic when the OOM killer is invoked, but is unrelated to oops events. Option B is wrong because `kernel.unknown_nmi_panic` controls whether the kernel panics on an unknown Non-Maskable Interrupt (NMI), not on a kernel oops. Option D is wrong because `kernel.oops` is not a valid sysctl parameter; the correct parameter is `kernel.panic_on_oops`.

Practice this question →
31
Multi-Selecteasy

Which three directories or files are typically associated with the Linux kernel? (Choose three.)

Select 3 answers
A./proc
B./dev
C./etc
D./sys
E./boot/vmlinuz-*
AnswersA, D, E

/proc is a virtual filesystem that provides kernel and process information.

Why this answer

/proc is a virtual filesystem that provides an interface to kernel data structures, exposing process information, system hardware details, and runtime kernel parameters. It is dynamically generated by the kernel and does not occupy disk space, making it a direct representation of kernel state.

Exam trap

The trap here is that candidates often confuse /dev as a kernel-associated directory because it contains device nodes, but /dev is a user-space interface managed by udev, whereas /proc and /sys are virtual filesystems directly maintained by the kernel.

Practice this question →
32
MCQhard

A system administrator has compiled a custom Linux kernel (version 5.15.19) with ext4 filesystem support built as a module. The administrator installed the kernel to /boot and built an initramfs using dracut with default options. After rebooting, the system fails with a kernel panic: 'VFS: Unable to mount root fs on unknown-block(0,0)'. The administrator confirms that the root partition is /dev/sda1 formatted as ext4 and that the kernel configuration includes the ext4 module. The kernel command line includes 'root=/dev/sda1' and 'rd.auto'. The administrator also notices that the initramfs file is only 5 MB in size, which seems smaller than expected. Which of the following is the most likely cause and best solution?

A.The initramfs is missing the ext4 module because dracut did not include it. The administrator should run 'dracut --force --add-drivers ext4 /boot/initramfs-5.15.19.img 5.15.19' to regenerate the initramfs including the ext4 module.
B.The kernel command line needs the 'rd.shell' parameter to allow interactive debugging. The administrator should add 'rd.shell' to the kernel parameter and boot again to investigate.
C.The root filesystem label or UUID is incorrect. The administrator should change the kernel command line to use 'root=LABEL=root' or 'root=UUID=...'.
D.The kernel is missing the ext4 module because it was not compiled. The administrator should recompile the kernel with ext4 compiled directly into the kernel (y) instead of as a module.
AnswerA

Dracut may fail to detect the module; --add-drivers forces inclusion, and --force overwrites the existing initramfs.

Why this answer

The small initramfs size (5 MB) suggests it does not contain the ext4 module. Dracut should have included it automatically, but may have failed. Rebuilding with --force and explicitly adding the ext4 driver ensures the module is included.

Compiling ext4 into the kernel would work but is not the most efficient solution; changing the root parameter would not help because the device is correct; rd.shell would allow debugging but not fix the underlying issue.

Practice this question →
33
MCQhard

After upgrading the kernel on a Red Hat Enterprise Linux system, the system fails to boot because the initramfs is missing. Which command can be used to regenerate the initramfs?

A.dracut -f
B.mkinitrd -f
C.grub2-mkconfig -o /boot/grub2/grub.cfg
D.mkinitramfs -o /boot/initrd.img
AnswerA

dracut -f regenerates the initramfs image.

Why this answer

On Red Hat Enterprise Linux (RHEL) systems, the `dracut` utility is the standard tool for creating and regenerating initial RAM filesystem images (initramfs). The `-f` (force) option overwrites an existing initramfs file, which is necessary after a kernel upgrade to ensure the new kernel has the correct drivers and modules to mount the root filesystem during boot. Without a valid initramfs, the kernel cannot access the root filesystem, causing a boot failure.

Exam trap

The trap here is that candidates often confuse the initramfs regeneration command with the bootloader configuration update command (`grub2-mkconfig`), or they mistakenly apply a Debian/Ubuntu command (`mkinitramfs`) to a RHEL system, not realizing that `dracut` is the correct tool for Red Hat-based distributions.

How to eliminate wrong answers

Option B is wrong because `mkinitrd` is a legacy tool that was used on older RHEL versions (RHEL 5 and earlier) and is not the current standard; on modern RHEL systems, `mkinitrd` is typically a wrapper script that calls `dracut`, but using it directly with `-f` is not the recommended or primary command. Option C is wrong because `grub2-mkconfig` regenerates the GRUB2 bootloader configuration file (`/boot/grub2/grub.cfg`), not the initramfs; it updates the boot menu but does not create or modify the initial RAM disk. Option D is wrong because `mkinitramfs` is a Debian/Ubuntu-specific command used to generate initramfs images; it is not available or appropriate on RHEL systems, which use `dracut`.

Practice this question →
34
MCQhard

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?

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.
AnswerA

A missing root device causes the kernel to hang while waiting for the device to appear.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse a missing initrd (which causes a different error earlier in boot) with a root filesystem mount failure, or they assume an unsupported filesystem type is the issue, but the kernel's behavior at the mount stage specifically points to a missing or misconfigured root device parameter.

How to eliminate wrong answers

Option B is wrong because if the root filesystem were formatted with an unsupported filesystem type, the kernel would typically emit a specific error message (e.g., 'VFS: Cannot open root device') and drop to a kernel panic, not simply hang at the mount stage; modern kernels include drivers for common filesystems like ext4, so this is rare. Option C is wrong because a missing initrd image would cause the kernel to fail to load necessary drivers or modules early in boot, but the boot process would usually halt earlier with a 'No init found' or similar error, not specifically at the root mount stage. Option D is wrong because if GRUB were not installed on the MBR, the system would not even start the bootloader; the boot process would fail before the kernel is loaded, not during the kernel's attempt to mount the root filesystem.

Practice this question →
35
MCQmedium

During boot, the kernel panics with 'VFS: Unable to mount root fs on unknown-block(0,0)'. Which of the following is the most likely cause?

A.The kernel lacks the driver for the storage controller.
B.The kernel image is corrupted.
C.The init process is missing.
D.The root filesystem is formatted with an unsupported filesystem.
AnswerA

Missing driver prevents accessing the root filesystem.

Why this answer

The error 'VFS: Unable to mount root fs on unknown-block(0,0)' indicates the kernel cannot find a driver for the block device containing the root filesystem. This most commonly occurs when the kernel lacks the necessary storage controller driver (e.g., for SATA, NVMe, or SCSI controllers), often because the driver was built as a module and not included in the initramfs or compiled into the kernel.

Exam trap

The trap here is that candidates confuse a missing init process (which occurs after mounting) with a missing storage driver (which prevents mounting entirely), leading them to select option C when the error clearly indicates the root device itself is unrecognized.

How to eliminate wrong answers

Option B is wrong because a corrupted kernel image would typically cause a different error, such as a panic during decompression or an 'Invalid or corrupt kernel image' message, not a VFS mount failure on a specific block device. Option C is wrong because a missing init process would result in a 'Kernel panic - not syncing: No init found' error after the root filesystem is successfully mounted, not a failure to mount the root filesystem itself. Option D is wrong because an unsupported filesystem would produce an error like 'VFS: Cannot open root device' or 'unknown filesystem type', but the block device would still be recognized (e.g., 'unknown-block(8,1)'), not 'unknown-block(0,0)' which indicates no driver claimed the device.

Practice this question →
36
MCQeasy

Which systemd target is equivalent to the traditional SysV runlevel 3 (multi-user text mode)?

A.rescue.target
B.graphical.target
C.multi-user.target
D.emergency.target
AnswerC

This target provides a multi-user, non-graphical environment.

Why this answer

The correct answer is C because in systemd, multi-user.target is the direct equivalent of SysV runlevel 3, which provides a multi-user text-mode environment without a graphical desktop. This target starts all essential system services and network support but does not launch a display manager, making it the standard for headless servers and maintenance.

Exam trap

The trap here is that candidates often confuse rescue.target (runlevel 1) with multi-user.target (runlevel 3) because both lack a GUI, but rescue.target is for single-user recovery with minimal services, not for normal multi-user text-mode operation.

How to eliminate wrong answers

Option A is wrong because rescue.target is equivalent to SysV runlevel 1 (single-user mode) and is used for emergency system recovery with minimal services, not for normal multi-user text operation. Option B is wrong because graphical.target is equivalent to SysV runlevel 5, which adds a graphical login manager (e.g., GDM, LightDM) on top of multi-user.target, not the text-only runlevel 3. Option D is wrong because emergency.target is an even more minimal state than rescue.target, starting only a root shell on the console with no network or other services, and has no direct SysV runlevel equivalent.

Practice this question →
37
MCQeasy

A system administrator needs to find out which kernel parameters were passed at boot time. Which command displays the kernel boot parameters?

A.cat /proc/cmdline
B.dmesg
C.lsmod
D.cat /proc/version
AnswerA

/proc/cmdline contains the boot parameters.

Why this answer

The correct command is `cat /proc/cmdline` because the Linux kernel stores the boot parameters (also known as the kernel command line) passed by the bootloader (e.g., GRUB) in the virtual file `/proc/cmdline`. Reading this file directly displays the exact parameters used during boot, such as `root=`, `quiet`, or `splash`.

Exam trap

The trap here is that candidates confuse `dmesg` (which shows boot messages) with the direct kernel command line, or assume `lsmod` or `/proc/version` might contain boot parameters, when only `/proc/cmdline` provides the exact boot-time arguments.

How to eliminate wrong answers

Option B is wrong because `dmesg` displays kernel ring buffer messages, which include boot logs and driver output, but not the raw kernel command line parameters in a direct, unparsed form. Option C is wrong because `lsmod` lists currently loaded kernel modules, not boot parameters. Option D is wrong because `cat /proc/version` shows the Linux kernel version string and compiler information, not the boot-time command-line arguments.

Practice this question →
38
Multi-Selecthard

Which THREE kernel boot parameters can be added to the GRUB command line to enable verbose debug output during boot? (Choose three.)

Select 3 answers
A.verbose
B.quiet
C.debug
D.earlyprintk
E.loglevel=7
AnswersC, D, E

Enables general debug output from the kernel.

Why this answer

The `debug` kernel boot parameter enables verbose debug output from the kernel during boot, printing extensive diagnostic messages. It is a valid parameter that can be added to the GRUB command line to increase verbosity for troubleshooting.

Exam trap

The trap here is that candidates may confuse `verbose` with a valid kernel parameter or think `quiet` enables debug output, when in fact `quiet` suppresses messages and `verbose` is not a kernel-recognized boot parameter.

Practice this question →
39
MCQeasy

After installing a new kernel on a system using GRUB2, which command should be run to update the boot menu configuration file?

A.grub-install /dev/sda
B.grub-mkconfig -o /boot/grub/grub.cfg
C.update-grub
D.grub2-mkconfig -o /boot/grub2/grub.cfg
AnswerB

This is the standard command to regenerate the GRUB2 configuration file.

Why this answer

After installing a new kernel on a system using GRUB2, the boot menu configuration file must be regenerated to include the new kernel entry. The command `grub-mkconfig -o /boot/grub/grub.cfg` reads the configuration snippets in `/etc/default/grub` and scripts in `/etc/grub.d/`, then writes the updated GRUB2 configuration to the specified output file (`/boot/grub/grub.cfg`). This is the standard method on most Linux distributions that use GRUB2 (e.g., Debian, Ubuntu, RHEL 7+).

Exam trap

The trap here is that candidates confuse `grub-install` (which installs the bootloader to disk) with `grub-mkconfig` (which updates the menu configuration), or they assume distribution-specific wrappers like `update-grub` are the correct answer when the exam expects the generic GRUB2 command.

How to eliminate wrong answers

Option A is wrong because `grub-install /dev/sda` installs GRUB2 to the Master Boot Record (MBR) or GPT partition of the disk, but it does not regenerate the boot menu configuration file; it only writes the bootloader code and stage files. Option C is wrong because `update-grub` is a distribution-specific wrapper script (commonly found on Debian/Ubuntu) that internally calls `grub-mkconfig -o /boot/grub/grub.cfg`, but it is not the direct command specified in the LPIC-2 exam objectives; the exam expects the explicit `grub-mkconfig` command. Option D is wrong because `grub2-mkconfig -o /boot/grub2/grub.cfg` uses the legacy GRUB2 naming convention (e.g., on RHEL/CentOS 7), but the question specifies a system using GRUB2 without indicating the distribution-specific path; the standard GRUB2 configuration file path is `/boot/grub/grub.cfg`, not `/boot/grub2/grub.cfg`.

Practice this question →
40
MCQmedium

A company develops a custom PCIe device driver as a kernel module. After installing a new kernel version 5.10.50 via a distribution update, the existing driver module fails to load with the error: 'insmod: ERROR: could not insert module mydriver.ko: Invalid module format'. The administrator checks the kernel version and sees that the module was compiled against a previous kernel version 5.10.45. The driver source code is available in /usr/src/mydriver. The administrator needs to get the driver working with the new kernel. Which of the following is the correct course of action?

A.Copy the compiled .ko file to /lib/modules/5.10.50/kernel/drivers/misc/ and run 'depmod -a'
B.Edit the module's Makefile to change the version string to match the new kernel
C.Recompile the module using 'make -C /lib/modules/$(uname -r)/build M=/usr/src/mydriver modules'
D.Use 'modprobe --force mydriver' to bypass the version check
AnswerC

This compiles the module against the new kernel's build tree, ensuring compatible symbols.

Why this answer

Option C is correct because the kernel module was compiled against a different kernel version (5.10.45) and the new kernel (5.10.50) has a different vermagic string, which includes the kernel version and other build parameters. The module must be recompiled against the new kernel's build tree located at /lib/modules/$(uname -r)/build to match the vermagic and ensure symbol compatibility. The command 'make -C /lib/modules/$(uname -r)/build M=/usr/src/mydriver modules' uses the kernel build system to compile the module against the running kernel's configuration and headers.

Exam trap

The trap here is that candidates assume copying the module to the correct directory or using --force will work, but the kernel's strict version and symbol checking requires recompilation against the exact kernel build tree.

How to eliminate wrong answers

Option A is wrong because copying the old .ko file to the new kernel's module directory and running depmod -a does not change the module's internal vermagic string; the kernel will still reject it due to version mismatch. Option B is wrong because editing the Makefile to change the version string does not recompile the module; the compiled .ko file retains the original vermagic from the previous build, and the Makefile change would only affect future compilations. Option D is wrong because modprobe --force bypasses the vermagic check but not the symbol versioning (CRC) check, and it can lead to kernel instability or crashes; it is not a proper solution for production systems.

Practice this question →
41
MCQhard

A user reports that an external USB hard drive is not detected when plugged in. The system uses a standard kernel with USB support. What is the most likely reason?

A.The USB driver is not installed.
B.The external drive is incompatible.
C.The kernel lacks USB support.
D.The usb_storage module is blacklisted.
AnswerD

The blacklist directive prevents the module from loading automatically.

Why this answer

Option B is correct because the blacklist.conf file prevents the usb_storage module from loading, which is required for USB mass storage devices. The module is installed but not loaded due to blacklisting.

Practice this question →
42
Matchingmedium

Match each Linux boot component to its role.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Bootloader that loads the kernel and initramfs

Temporary root filesystem for early boot drivers

Init system that starts services and manages targets

Compressed Linux kernel image

Older initial ramdisk for booting

Why these pairings

These components are involved in the Linux boot process.

Practice this question →
43
MCQhard

A company runs a critical web server on a custom-built Linux distribution. The server has been stable for months, but after a recent kernel update from version 5.10 to 5.15, the server experiences intermittent crashes. The crashes occur under heavy load and are accompanied by kernel oops messages mentioning a NULL pointer dereference in a network driver. The network driver is a third-party module that was compiled against the old kernel. The system administrator has recompiled the module against the new kernel, but the crashes persist. The server has 64 GB of RAM and uses a bonded network interface with two 10 GbE NICs. The kernel oops trace points to a function in the bonding driver. Which of the following is the most likely cause of the crashes?

A.Increase the system memory to reduce memory pressure.
B.Update the firmware on the network interface cards.
C.Check the kernel configuration changes between versions 5.10 and 5.15 that affect the bonding driver.
D.Recompile the network driver module with debugging enabled.
AnswerC

Kernel API changes in the bonding driver could cause the third-party module to dereference a NULL pointer.

Why this answer

Option C is correct because the crashes persist after recompiling the third-party network driver, and the oops trace points to the bonding driver. This indicates that the issue is likely due to changes in the kernel's internal APIs or data structures between versions 5.10 and 5.15 that affect the bonding driver, not the third-party module. The bonding driver is part of the kernel itself, so it must be compatible with the new kernel version; checking kernel configuration changes (e.g., modifications to `struct net_device`, bonding sysfs interfaces, or locking mechanisms) is the appropriate next step.

Exam trap

The trap here is that candidates assume recompiling the third-party module against the new kernel is sufficient, overlooking that the crash originates in the in-tree bonding driver, which must also be compatible with the kernel version and may require kernel configuration adjustments or backported patches.

How to eliminate wrong answers

Option A is wrong because increasing system memory does not address a NULL pointer dereference caused by a kernel API change; memory pressure is unrelated to the driver logic error. Option B is wrong because updating NIC firmware would not fix a kernel-level bug in the bonding driver; firmware handles low-level hardware operations, not kernel data structures. Option D is wrong because recompiling with debugging enabled only adds debug symbols and does not fix the underlying API incompatibility; the module was already recompiled against the new kernel, and debugging would not resolve the NULL pointer dereference in the bonding driver.

Practice this question →
44
MCQeasy

A kernel module has been recompiled. Which command updates the module dependency information?

A.depmod
B.modprobe
C.insmod
D.modinfo
AnswerA

depmod generates modules.dep and map files needed by modprobe.

Why this answer

The `depmod` command is used to generate a list of module dependencies, stored in the modules.dep file, based on the symbols exported by each kernel module. After recompiling a module, this file becomes outdated, and running `depmod -a` (or simply `depmod`) rebuilds the dependency information so that tools like `modprobe` can correctly load modules and their prerequisites.

Exam trap

The trap here is that candidates often confuse `modprobe` (which loads modules and their dependencies) with `depmod` (which builds the dependency database), assuming that the tool that loads modules also updates the dependency information.

How to eliminate wrong answers

Option B is wrong because `modprobe` is used to load or unload kernel modules and their dependencies, but it does not update the dependency database itself; it relies on the pre-existing modules.dep file generated by `depmod`. Option C is wrong because `insmod` inserts a single module into the kernel without resolving dependencies, and it does not update any dependency metadata. Option D is wrong because `modinfo` displays information about a kernel module (such as author, description, and parameters) but does not modify or regenerate dependency information.

Practice this question →
45
MCQeasy

A system administrator needs to add a kernel module to the kernel at runtime without recompiling. Which command should be used?

A.insmod
B.rmmod
C.modprobe
D.depmod
AnswerA

insmod inserts a module directly.

Why this answer

The correct command is `insmod` because it inserts a kernel module into the running kernel without recompiling. It directly loads the specified module file (e.g., `.ko` file) into the kernel, making it available immediately. This is the standard low-level command for adding a single module at runtime.

Exam trap

The trap here is that candidates often confuse `modprobe` with `insmod` because both can load modules, but `modprobe` is the higher-level tool that handles dependencies and is more commonly used in practice, while `insmod` is the direct kernel insertion command specifically for adding a module at runtime without recompiling.

How to eliminate wrong answers

Option B (rmmod) is wrong because it removes a kernel module from the running kernel, not adds one. Option C (modprobe) is wrong because while it can add modules, it also handles dependencies and is typically used for loading modules with automatic dependency resolution, but the question specifies adding a module 'without recompiling' and `insmod` is the direct command for that purpose; `modprobe` is more high-level and can be used for the same task but is not the command that directly inserts a module file into the kernel. Option D (depmod) is wrong because it generates dependency information for kernel modules (creating modules.dep files) but does not load or add any module to the kernel.

Practice this question →
46
MCQmedium

A server with multiple network cards needs a specific kernel module loaded before network configuration. Where should loading be configured for early boot?

A./boot/grub/grub.cfg
B./etc/modprobe.d/
C./etc/sysconfig/modules/
D./etc/modules-load.d/
AnswerD

Files in /etc/modules-load.d/ list modules to be loaded at boot by systemd.

Why this answer

Option D is correct because systemd-based systems use /etc/modules-load.d/ to specify kernel modules that must be loaded early in the boot process, before network configuration. Files in this directory are processed by systemd-modules-load.service, which runs before network services, ensuring the module is available when interfaces are brought up.

Exam trap

The trap here is that candidates often confuse /etc/modprobe.d/ (for module parameters and aliases) with /etc/modules-load.d/ (for specifying modules to load at boot), leading them to choose the wrong directory for early module loading.

How to eliminate wrong answers

Option A is wrong because /boot/grub/grub.cfg is the GRUB configuration file used for bootloader settings, not for loading kernel modules after the kernel is running. Option B is wrong because /etc/modprobe.d/ is for modprobe configuration (e.g., module aliases, options, blacklisting), not for specifying modules to load at boot. Option C is wrong because /etc/sysconfig/modules/ is a Red Hat/CentOS legacy directory for custom module-loading scripts, but it is not the standard systemd location and is not processed by systemd-modules-load.service.

Practice this question →
47
MCQeasy

To list all currently loaded kernel modules, which command is used?

A.lsmod
B.kmod -l
C.modlist
D.modules_loaded
AnswerA

lsmod lists all loaded kernel modules.

Why this answer

The correct command to list all currently loaded kernel modules is `lsmod`. It reads the `/proc/modules` file and displays the module name, size, used count, and a list of dependent modules. This is the standard and most direct method on Linux systems.

Exam trap

The trap here is that candidates may confuse `lsmod` with `modprobe` or `kmod` options, or assume a non-existent command like `modlist` is correct because it sounds plausible.

How to eliminate wrong answers

Option B is wrong because `kmod -l` is not a valid command; `kmod` is a helper program for managing kernel modules, but it does not have a `-l` flag to list loaded modules (the correct command for listing modules via kmod is `kmod list` or `lsmod`). Option C is wrong because `modlist` is not a standard Linux command; it does not exist in the kernel module management tools. Option D is wrong because `modules_loaded` is not a command; it is a conceptual term and there is no such executable or built-in command in Linux.

Practice this question →
48
MCQhard

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?

A.The root filesystem UUID in /etc/fstab is incorrect.
B.The kernel image is missing.
C.The kernel lacks SATA driver support.
D.The initramfs was not regenerated after adding the disk.
AnswerA

Incorrect UUID leads to unknown-block error.

Why this answer

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.

Exam trap

The trap here is that candidates 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.

How to eliminate wrong answers

Option B is wrong because a missing kernel image would cause a different error, such as 'No bootable device' or a GRUB failure, not a VFS mount panic. Option C is wrong because the kernel can identify the block device (8,17), proving SATA driver support is present; a missing driver would result in 'unknown-block(0,0)' or no device node. Option D is wrong because the initramfs is not involved in mounting the root filesystem from /etc/fstab; the initramfs only provides early userspace and drivers, but the root mount is handled by the kernel after pivot_root, and regenerating it would not fix an incorrect UUID in fstab.

Practice this question →
49
MCQmedium

During boot, the system displays 'unable to mount root fs on unknown-block'. What is the most likely cause?

A.Corrupted init binary
B.Missing filesystem driver in initramfs
C.Wrong block device order
D.Incorrect root= parameter
AnswerB

The kernel cannot access the root filesystem because the necessary driver (e.g., ext4) is not loaded; it must be in the initramfs.

Why this answer

The error 'unable to mount root fs on unknown-block' indicates that the kernel cannot find a driver for the filesystem or block device containing the root filesystem. This typically occurs when the initramfs lacks the necessary kernel module (e.g., ext4, xfs, or a storage controller driver like ahci or nvme) to access the root device. The initramfs is responsible for loading essential drivers before the kernel mounts the real root filesystem; if the driver is missing, the mount fails.

Exam trap

The trap here is that candidates confuse a missing driver with a wrong root= parameter, but the error message 'unknown-block' specifically points to a driver/module issue, not a path or UUID mismatch.

How to eliminate wrong answers

Option A is wrong because a corrupted init binary would cause a different failure, such as a panic or kernel oops during init execution, not a block device mount error. Option C is wrong because block device order (e.g., /dev/sda vs /dev/sdb) is irrelevant when the root= parameter explicitly specifies the device; the kernel uses the given device path, not enumeration order. Option D is wrong because an incorrect root= parameter would produce an error like 'VFS: Cannot open root device' or 'unknown-block(0,0)', not the specific 'unknown-block' message, which indicates the driver is missing for a correctly specified device.

Practice this question →
50
MCQmedium

Refer to the exhibit. A system administrator has configured the above in /etc/default/grub. After running update-grub, what will be the boot menu behavior?

A.The menu will be displayed for 10 seconds, then the default entry boots automatically.
B.The boot menu will be hidden for 0 seconds (i.e., not hidden), and the default entry boots immediately.
C.The menu will be displayed but with no timeout; it will wait indefinitely for user input.
D.The boot menu will be hidden unless Shift is pressed, and the default entry will boot after 10 seconds.
AnswerA

GRUB_HIDDEN_TIMEOUT=0 means no hidden menu, so the standard timeout applies and the menu is shown.

Why this answer

Option A is correct because the configuration shown in /etc/default/grub includes GRUB_TIMEOUT=10 and GRUB_TIMEOUT_STYLE=menu (or the default style if unset). After running update-grub, the boot menu will be displayed for 10 seconds, and then the default entry (set by GRUB_DEFAULT) will boot automatically. This is the standard behavior when GRUB_TIMEOUT is set to a positive integer and the timeout style is 'menu'.

Exam trap

The trap here is that candidates confuse GRUB_TIMEOUT with GRUB_HIDDEN_TIMEOUT, assuming a positive timeout always hides the menu or that a hidden menu is the default behavior, when in fact the default GRUB_TIMEOUT_STYLE is 'menu' and the timeout simply controls how long the menu is displayed before auto-booting.

How to eliminate wrong answers

Option B is wrong because GRUB_TIMEOUT=10 does not cause the menu to be hidden for 0 seconds; a hidden menu requires GRUB_TIMEOUT_STYLE=hidden or GRUB_TIMEOUT=0 with GRUB_HIDDEN_TIMEOUT, and the default entry would boot immediately only if GRUB_TIMEOUT=0. Option C is wrong because GRUB_TIMEOUT=10 sets a finite timeout of 10 seconds, not an indefinite wait; an indefinite wait requires GRUB_TIMEOUT=-1. Option D is wrong because hiding the menu unless Shift is pressed requires GRUB_TIMEOUT_STYLE=hidden along with GRUB_HIDDEN_TIMEOUT and GRUB_HIDDEN_TIMEOUT_QUIET, and the timeout of 10 seconds would apply to the hidden menu, not the displayed menu; the configuration shown does not include these hidden-menu directives.

Practice this question →
51
MCQhard

A company runs a high-frequency trading application that requires extremely low latency. The system administrator has compiled a custom Linux kernel with various real-time patches and tuned kernel parameters. After deploying the new kernel, the application performance degrades significantly. The administrator suspects that kernel preemption settings are causing context switch overhead. Which of the following actions should the administrator take to diagnose and optimize the kernel preemption model?

A.Use sysctl to set 'kernel.preempt_model' to 'none'
B.Add 'preempt=none' to the kernel command line
C.Check /proc/sched_debug for preemption counters and adjust the kernel's preemption model by recompiling with CONFIG_PREEMPT_NONE instead of CONFIG_PREEMPT
D.Change the kernel preemption model at runtime by writing to /sys/kernel/preempt_control
AnswerC

The preemption model (none, voluntary, full) is a compile-time config; /proc/sched_debug reveals preemption activity.

Why this answer

Option C is correct because the kernel preemption model is a compile-time configuration, not a runtime parameter. To change from CONFIG_PREEMPT (full preemption) to CONFIG_PREEMPT_NONE (no forced preemption), the administrator must recompile the kernel with the appropriate configuration. Checking /proc/sched_debug can reveal preemption-related counters and context switch statistics, helping confirm that excessive preemption is causing overhead.

Exam trap

The trap here is that candidates assume kernel parameters can be changed at runtime via sysctl or /sys files, but the preemption model is a static compile-time choice unless the kernel is built with CONFIG_PREEMPT_DYNAMIC, which is not indicated in this scenario.

How to eliminate wrong answers

Option A is wrong because there is no sysctl parameter named 'kernel.preempt_model'; the preemption model is not adjustable via sysctl. Option B is wrong because 'preempt=none' is not a valid kernel command-line parameter; the correct parameter would be 'preempt=none' only if the kernel was compiled with support for runtime selection (e.g., CONFIG_PREEMPT_DYNAMIC), but the question states the kernel was compiled with real-time patches and tuned parameters, implying a static build. Option D is wrong because there is no /sys/kernel/preempt_control file; the preemption model cannot be changed at runtime on a standard Linux kernel without dynamic preemption support.

Practice this question →
52
MCQmedium

A system has multiple kernels installed. Which command shows the version of the currently booted kernel?

A.rpm -qa | grep kernel
B.uname -r
C.cat /proc/version
D.ls /boot
AnswerB

uname -r prints just the kernel release of the currently running kernel.

Why this answer

The `uname -r` command specifically displays the kernel release (version) of the currently running operating system. It reads this information directly from the `/proc/sys/kernel/osrelease` virtual file, which is populated by the kernel at boot time. This makes it the most direct and reliable method to identify the active kernel version.

Exam trap

The trap here is that candidates often confuse listing installed kernels (via package managers or `/boot`) with identifying the currently running kernel, leading them to pick options like `rpm -qa | grep kernel` or `ls /boot`.

How to eliminate wrong answers

Option A is wrong because `rpm -qa | grep kernel` lists all installed kernel packages in the RPM database, not the currently booted kernel. Option C is wrong because `cat /proc/version` shows the kernel version along with additional build information (like compiler and build date), but it is not the standard command for quickly retrieving just the version string; `uname -r` is the canonical tool. Option D is wrong because `ls /boot` lists the files in the boot directory, including multiple kernel images and initramfs files, but does not indicate which one is currently loaded.

Practice this question →
53
MCQmedium

A developer compiled a custom kernel version 5.15.10 and ran 'make modules_install' followed by 'make install' on a system using GRUB 2. After rebooting, the system still boots the old kernel. Which of the following is the most likely cause?

A.The kernel version string is too long for GRUB 2
B.The kernel image was not copied to /boot because the disk was full
C.The initramfs was not created for the new kernel
D.The boot loader configuration was not updated
AnswerD

The most common issue is that the boot loader configuration (e.g., GRUB) was not updated to include the new kernel entry.

Why this answer

After running 'make install', the GRUB 2 bootloader configuration file (usually /boot/grub/grub.cfg) is not automatically regenerated. The 'make install' target copies the kernel image and System.map to /boot, but it does not run update-grub or grub-mkconfig to add the new kernel entry. Without an updated bootloader configuration, GRUB 2 continues to boot the old kernel entry, even though the new kernel files are present.

Exam trap

The trap here is that candidates assume 'make install' fully integrates the new kernel into the boot process, when in fact it only places the files and relies on a separate step to update the bootloader configuration.

How to eliminate wrong answers

Option A is wrong because GRUB 2 supports kernel version strings up to 255 characters, and '5.15.10' is well within that limit. Option B is wrong because if the disk were full, 'make install' would fail with an error message, and the system would not silently skip copying; the question states the commands ran without error. Option C is wrong because initramfs is not required for booting a kernel; the kernel can boot without it (though it may lack drivers), and its absence does not prevent GRUB from selecting the new kernel entry.

Practice this question →
54
Multi-Selecthard

Which three steps are required to build a kernel module from source located outside the kernel tree? (Choose three.)

Select 3 answers
A.Run 'make modules_install'.
B.Run 'make' in the module source directory.
C.Run 'depmod -a'.
D.Edit the kernel configuration.
E.Use the kernel's top-level Makefile.
AnswersA, B, C

This installs the compiled module to /lib/modules/$(uname -r)/.

Why this answer

Option A is correct because 'make modules_install' copies the compiled kernel module (.ko file) to the appropriate directory under /lib/modules/$(uname -r)/, making it available for loading. This step is essential after building a module from external source to ensure it is installed in the correct location for the running kernel.

Exam trap

The trap here is that candidates often think editing the kernel configuration or using the top-level Makefile is necessary for external modules, but in reality, external modules only need the kernel headers and a properly written Makefile that invokes the kernel build system.

Practice this question →
55
Multi-Selecthard

Which THREE factors can cause a kernel panic during boot? (Select THREE.)

Select 3 answers
A.Too many kernel modules loaded
B.Corrupted kernel image
C.Hardware incompatibility
D.Filesystem errors on the root partition
E.Missing device drivers for storage controllers
AnswersB, C, E

A corrupted vmlinuz or bzImage can cause a panic during decompression or execution.

Why this answer

A corrupted kernel image (Option B) is a direct cause of kernel panic during boot because the bootloader (e.g., GRUB) loads the kernel into memory, and if the binary is damaged (e.g., due to disk errors or incomplete update), the CPU will attempt to execute invalid instructions, triggering a fatal kernel panic. The kernel performs integrity checks early in startup, and any mismatch between expected and actual code will halt the system with a panic message.

Exam trap

The trap here is that candidates often confuse 'kernel panic' with 'boot failure' and incorrectly select filesystem errors (Option D) as a direct cause, when in fact filesystem issues typically lead to a recovery shell or initramfs failure, not a kernel panic.

Practice this question →
56
MCQmedium

A data center administrator is troubleshooting a server that hangs during boot after a kernel update. The server uses UEFI and GRUB 2. The administrator observes that the server displays the GRUB menu, selects the new kernel entry, but then the screen goes blank and the system does not respond. The administrator can boot the previous kernel from the GRUB menu successfully. Which of the following is the most likely cause of this issue?

A.The initramfs for the new kernel was not generated
B.Secure Boot is enabled and the new kernel is not signed
C.The new kernel's root= parameter points to an invalid device
D.The new kernel includes a graphics driver that conflicts with the hardware, causing the display to blank
AnswerD

A common cause of blank screen after GRUB is a framebuffer or graphics driver issue, often resolved by adding 'nomodeset' to the kernel command line.

Why this answer

Option D is correct because the blank screen after selecting the new kernel, while the old kernel works, strongly indicates a graphics driver conflict. In GRUB 2 with UEFI, the kernel may switch from the UEFI framebuffer to a native graphics driver (e.g., nouveau, i915, amdgpu) that fails to initialize on the specific hardware, causing the display to go blank. The system is not truly hung; it continues booting without console output, which is a known issue with incompatible or buggy kernel graphics drivers.

Exam trap

The trap here is that candidates often assume a blank screen means the kernel didn't load at all, leading them to choose Secure Boot or initramfs issues, but the fact that the old kernel works and the new kernel is selected from GRUB points to a driver-level failure after kernel handoff.

How to eliminate wrong answers

Option A is wrong because if the initramfs were missing, the kernel would panic with a 'Kernel panic - not syncing: VFS: Unable to mount root fs' error, not a blank screen. Option B is wrong because Secure Boot prevents the kernel from loading at all, showing a 'Verification failed' error or refusing to boot the entry, not a blank screen after selection. Option C is wrong because an invalid root= parameter would cause a kernel panic during root mount, typically displaying an error message on the console before the system hangs, not a blank screen immediately after kernel selection.

Practice this question →
57
Multi-Selectmedium

Which two utilities can be used to load kernel modules? (Choose two.)

Select 2 answers
A.modprobe
B.modinfo
C.lsmod
D.depmod
E.insmod
AnswersA, E

modprobe loads modules with automatic dependency resolution.

Why this answer

modprobe is correct because it is the primary utility for loading kernel modules, including handling module dependencies automatically by consulting the modules.dep file generated by depmod. insmod is also correct because it directly inserts a single module into the kernel, though it does not resolve dependencies automatically.

Exam trap

The trap here is that candidates often confuse modinfo or lsmod as module-loading tools because they are commonly used alongside module management, but they only provide information or listing, not loading.

Practice this question →
58
MCQeasy

A system administrator is troubleshooting a hardware issue that occurs during boot. To monitor the kernel messages in real-time, which command should be run?

A.journalctl -f
B.tail -f /var/log/kern.log
C.dmesg -w
D.less /var/log/messages
AnswerC

dmesg -w shows kernel ring buffer messages in real-time; it's the standard tool for kernel messages.

Why this answer

Option C is correct because `dmesg -w` (or `dmesg --follow`) provides real-time monitoring of kernel ring buffer messages, which is essential for troubleshooting hardware issues during boot. The `-w` flag waits for new messages and prints them as they appear, similar to `tail -f`, but specifically for kernel messages. This command directly accesses the kernel ring buffer via `/dev/kmsg`, ensuring you see hardware-related errors, driver messages, and device initialization logs as they occur.

Exam trap

The trap here is that candidates confuse `journalctl -f` (which shows all logs including kernel ones) with the more direct `dmesg -w` for kernel-specific real-time monitoring, especially during early boot when systemd may not be fully operational.

How to eliminate wrong answers

Option A is wrong because `journalctl -f` follows the systemd journal in real-time, which includes kernel messages but also user-space logs; it is not the most direct or minimal command for monitoring kernel messages specifically during boot, and it requires systemd to be running. Option B is wrong because `tail -f /var/log/kern.log` relies on a log file that may not exist or be updated in real-time during early boot (e.g., before the logging daemon starts), and it is not a direct interface to the kernel ring buffer. Option D is wrong because `less /var/log/messages` is a static view of a log file that may contain kernel messages but does not provide real-time monitoring, and the file may not be available or updated during boot.

Practice this question →
59
MCQeasy

A system administrator needs to include a custom kernel module in the initramfs to support a root filesystem on a USB device. Which command should be used to rebuild the initramfs with the updated kernel?

A.dracut
B.update-initramfs
C.mkinitrd
D.grub-mkconfig
AnswerA

dracut is the standard tool for creating initramfs images on many distributions.

Why this answer

Dracut is the correct tool for rebuilding the initramfs on modern Red Hat-based distributions (e.g., RHEL, CentOS, Fedora). It automatically detects and includes kernel modules required for the root filesystem, including those for USB storage devices, and regenerates the initramfs image with the updated kernel module.

Exam trap

The trap here is that candidates often confuse distribution-specific tools, assuming update-initramfs (Debian) or mkinitrd (legacy) are universally applicable, while the question implicitly targets a Red Hat-based environment where dracut is the standard.

How to eliminate wrong answers

Option B is wrong because update-initramfs is the tool used on Debian-based distributions (e.g., Ubuntu), not on Red Hat-based systems where dracut is standard. Option C is wrong because mkinitrd is a legacy tool that has been deprecated in favor of dracut on modern distributions; it does not handle custom kernel modules as reliably. Option D is wrong because grub-mkconfig is used to regenerate the GRUB bootloader configuration file (grub.cfg), not to rebuild the initramfs.

Practice this question →
60
MCQeasy

Refer to the exhibit. Which kernel parameter is responsible for reducing the amount of kernel messages displayed on the console?

A.ro
B.splash
C.quiet
D.BOOT_IMAGE
AnswerC

The 'quiet' parameter suppresses most kernel messages on the console.

Why this answer

The `quiet` kernel parameter suppresses most kernel log messages from being printed to the console during boot, reducing console output to only critical or error-level messages. This is controlled by the kernel's console log level, which `quiet` effectively lowers to KERN_WARNING (4) or higher, filtering out informational and debug messages.

Exam trap

The trap here is that candidates confuse `quiet` with `splash`, thinking both suppress messages, but `splash` only hides them visually while the kernel still generates the same output, whereas `quiet` actually reduces the kernel's console log level.

How to eliminate wrong answers

Option A is wrong because `ro` is a kernel parameter that mounts the root filesystem as read-only during early boot, not related to console message filtering. Option B is wrong because `splash` is a boot parameter used to enable a graphical splash screen (e.g., Plymouth) that hides boot messages visually, but it does not reduce the kernel's actual message output; it merely overlays a graphic. Option D is wrong because `BOOT_IMAGE` is a parameter that records the path or label of the kernel image used for booting, set by the bootloader (e.g., GRUB), and has no effect on kernel message verbosity.

Practice this question →
61
Matchingmedium

Match each Linux filesystem feature to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Journaling filesystem with extents and delayed allocation

High-performance 64-bit journaling filesystem

Copy-on-write filesystem with snapshots and compression

Advanced filesystem with volume management and checksumming

Network filesystem for sharing directories over a network

Why these pairings

These are common Linux filesystems and their key characteristics.

Practice this question →
62
MCQeasy

During boot, the kernel outputs a message indicating that a required device driver is not found. Which command can be used to rebuild the initramfs to include the missing driver?

A.mkinitrd
B.grub-mkconfig
C.mkinitcpio
D.dracut
AnswerD

dracut is the standard tool for building initramfs on many distributions.

Why this answer

Dracut is the standard tool for building initramfs images on modern Red Hat-based distributions (RHEL, CentOS, Fedora). When a required kernel driver is missing during boot, you can use `dracut --force` to rebuild the initramfs, which will automatically include the currently loaded kernel modules and any specified in configuration files. This ensures the missing driver is available early in the boot process.

Exam trap

The trap here is that candidates confuse distribution-specific tools (mkinitcpio for Arch, mkinitrd for old Red Hat) with the cross-distribution standard dracut, which is the correct answer for LPIC-2's focus on modern enterprise Linux.

How to eliminate wrong answers

Option A is wrong because `mkinitrd` is a legacy tool used primarily on older Red Hat systems (pre-RHEL 6) and has been replaced by dracut; it does not handle modern initramfs generation with the same flexibility. Option B is wrong because `grub-mkconfig` is used to regenerate the GRUB bootloader configuration file (grub.cfg), not to rebuild the initramfs image. Option C is wrong because `mkinitcpio` is the initramfs creation tool for Arch Linux, not for the distribution-agnostic LPIC-2 context where dracut is the standard answer.

Practice this question →
63
MCQmedium

An administrator wants to compile a new kernel module that is not yet in the tree. What file should be referenced to ensure the module is built with the same configuration as the current kernel?

A./proc/config.gz
B./boot/config-5.10.0-9-amd64
C./boot/System.map-5.10.0-9-amd64
D./boot/initrd.img-5.10.0-9-amd64
AnswerB

The config file stores all kernel configuration options used to build the kernel.

Why this answer

Option B is correct because /boot/config-5.10.0-9-amd64 contains the exact kernel configuration used to build the currently running kernel. When compiling a new kernel module, referencing this file (typically via 'make oldconfig' or copying it to the source tree as .config) ensures the module is built with the same set of options, such as enabled features, drivers, and module parameters, preventing incompatibilities.

Exam trap

The trap here is that candidates confuse /proc/config.gz with a reliable configuration source, not realizing it is optional and may be absent, while /boot/config-* is the standard, always-present file on Debian-based systems.

How to eliminate wrong answers

Option A is wrong because /proc/config.gz is a compressed representation of the current kernel's configuration, but it is only available if the kernel was built with CONFIG_IKCONFIG_PROC enabled; it is not a guaranteed file on all systems and is not the standard reference file for building modules. Option C is wrong because /boot/System.map-5.10.0-9-amd64 contains kernel symbol addresses used for debugging and resolving kernel oopses, not the kernel build configuration. Option D is wrong because /boot/initrd.img-5.10.0-9-amd64 is an initial ramdisk image used during boot to load necessary drivers and mount the root filesystem, and it has no role in providing kernel build configuration.

Practice this question →
64
Multi-Selecteasy

Which TWO of the following commands can be used to load a kernel module into the running kernel?

Select 2 answers
A.insmod
B.depmod
C.rmmod
D.modprobe
E.modinfo
AnswersA, D

insmod loads a module directly from a file.

Why this answer

insmod and modprobe are the two commands that actually load a kernel module into the running kernel. insmod loads a module directly from a file path, while modprobe loads modules along with their dependencies. The other commands either display information or manage dependencies.

Practice this question →
65
Multi-Selectmedium

Which TWO of the following commands are used to manage kernel modules? (Select TWO.)

Select 2 answers
A.lsmod
B.insmod
C.modprobe
D.rmmod
E.depmod
AnswersB, C

insmod loads a single module directly.

Why this answer

B (insmod) is correct because it directly inserts a kernel module into the running kernel, though it does not resolve dependencies automatically. C (modprobe) is correct because it is the recommended tool for managing kernel modules, as it automatically loads dependencies and handles module parameters via configuration files in /etc/modprobe.d/.

Exam trap

The trap here is that candidates often confuse 'managing' modules with 'listing' or 'removing' them, and may incorrectly select lsmod or rmmod, or fail to recognize that modprobe is the primary management command while insmod is a lower-level alternative.

Practice this question →
66
MCQeasy

After creating a new partition table on /dev/sda, what command should be run to install GRUB2 to the Master Boot Record?

A.grub-mkconfig -o /boot/grub/grub.cfg
B.update-grub
C.grub-install /dev/sda1
D.grub-install /dev/sda
AnswerD

This installs GRUB to the MBR of /dev/sda.

Why this answer

After creating a new partition table on /dev/sda, the Master Boot Record (MBR) resides on the disk device itself, not on a partition. The `grub-install /dev/sda` command installs GRUB2's boot code into the MBR (first 440 bytes) and embeds the core image in the post-MBR gap. This makes the disk bootable by the BIOS.

Exam trap

The trap here is that candidates confuse installing GRUB to a partition (e.g., /dev/sda1) with installing it to the MBR of the whole disk (/dev/sda), because they think the bootloader should reside on the root filesystem partition, but the MBR is a disk-level structure, not a partition-level one.

How to eliminate wrong answers

Option A is wrong because `grub-mkconfig -o /boot/grub/grub.cfg` only generates the GRUB configuration file from templates; it does not install any boot code to the MBR or disk. Option B is wrong because `update-grub` is a wrapper script that calls `grub-mkconfig` to regenerate the configuration file; it performs no installation to the MBR. Option C is wrong because `grub-install /dev/sda1` attempts to install GRUB to a partition (e.g., /dev/sda1), which is incorrect for MBR booting—GRUB must be installed to the whole disk device (e.g., /dev/sda) to write to the MBR, not to a partition block device.

Practice this question →
67
MCQeasy

A system administrator notices that the 'pcspkr' kernel module is causing beeps on the server console. The administrator wants to prevent this module from loading permanently. Which of the following is the correct method to blacklist the module?

A.Add 'install pcspkr /bin/false' to /etc/modprobe.conf
B.Set the kernel parameter 'pcspkr=off' in GRUB
C.Add 'blacklist pcspkr' to /etc/modprobe.d/blacklist.conf
D.Remove the module file from /lib/modules/$(uname -r)/kernel/drivers/input/misc/
AnswerC

This is the standard method to blacklist a kernel module.

Why this answer

Option C is correct because the standard method to permanently prevent a kernel module from loading is to add a 'blacklist' directive to a file in /etc/modprobe.d/. The 'blacklist pcspkr' line tells modprobe not to load the pcspkr module automatically, even if it is requested by hardware detection or dependencies. This is the recommended approach on modern Linux distributions using modprobe's configuration system.

Exam trap

The trap here is that candidates may confuse kernel command-line parameters (like 'modprobe.blacklist=') with module-specific parameters, or think that removing the module file is a valid administrative action, when in fact the proper method is to use the modprobe blacklist configuration.

How to eliminate wrong answers

Option A is wrong because 'install pcspkr /bin/false' would override the module's install command, but it does not prevent the module from being loaded by dependencies or alias resolution; it only replaces the load action with a false return, which may still trigger unwanted side effects and is not the standard blacklist mechanism. Option B is wrong because 'pcspkr=off' is not a valid kernel parameter; the kernel does not have a built-in parameter to disable a specific module by name, and GRUB parameters are used for kernel command-line options, not for module blacklisting. Option D is wrong because removing the module file from the filesystem is not a supported or safe method; it can break package management, prevent future updates, and may cause system instability, and the module could be reinstalled by updates or kernel upgrades.

Practice this question →
68
Multi-Selecteasy

Which three of the following are required steps to compile and install a custom Linux kernel from source? (Choose three.)

Select 3 answers
A.Run 'make modules_install' to install compiled modules
B.Run 'update-grub' to regenerate GRUB configuration
C.Run 'depmod -a' to generate module dependencies
D.Run 'make install' to install the kernel image and update boot loader
E.Run 'make oldconfig' to configure the kernel
AnswersA, D, E

This copies modules to /lib/modules/$(uname -r)/.

Why this answer

Option A is correct because after building kernel modules with 'make', you must run 'make modules_install' to copy the compiled modules into the appropriate directory under /lib/modules/$(uname -r)/, making them available for the kernel to load. This step is essential for any kernel that uses loadable modules, as it populates the module tree with the correct .ko files.

Exam trap

The trap here is that candidates confuse optional or automatic post-install steps (like 'update-grub' or 'depmod -a') with the mandatory compilation and installation steps, leading them to select B or C instead of the correct required steps A, D, and E.

Practice this question →
69
MCQmedium

A system fails to boot with the error shown. Which kernel parameter should be added to the kernel command line to resolve the issue?

A.root=/dev/sda1
B.noprompt
C.rootfstype=ext4
D.rootdelay=10
E.single
AnswerD

Adds a delay before attempting to mount root, allowing the device to become ready.

Why this answer

The error 'unknown-block(8,1)' indicates the root device is not ready when the kernel tries to mount it. Adding rootdelay=10 introduces a delay, giving the device time to become available. The other options are either already present or address different issues.

Practice this question →
70
MCQmedium

A developer compiled a custom kernel, installed it, but the system hangs before init starts. The previous kernel works. Which step was most likely missed?

A.Not updating GRUB configuration
B.Not rebuilding initramfs
C.Not running depmod
D.Not setting the correct root filesystem
AnswerB

The initramfs contains drivers needed early; forgetting to rebuild it is the most likely cause of the hang.

Why this answer

When a custom kernel is compiled and installed, the initramfs must be rebuilt to include the necessary kernel modules for mounting the root filesystem at boot. If the initramfs is not regenerated, the kernel may lack critical drivers (e.g., for storage controllers or filesystems), causing the system to hang before init starts because it cannot access the root device. The previous kernel works because its initramfs was built with the correct modules for that kernel version.

Exam trap

The trap here is that candidates often assume a kernel hang before init is due to a bootloader misconfiguration (GRUB), but the real issue is the missing initramfs, which is required to provide the drivers for the root filesystem that the kernel itself does not have built-in.

How to eliminate wrong answers

Option A is wrong because not updating GRUB configuration would typically result in the system booting the old kernel, not a hang with the new kernel; the new kernel is already selected and booting, so GRUB is not the issue. Option C is wrong because depmod updates module dependencies in /lib/modules/<kernel-version>, but the kernel can still boot without it; the hang occurs before init due to missing root filesystem access, not module loading order. Option D is wrong because if the root filesystem setting were incorrect, the kernel would likely panic with a 'VFS: Unable to mount root fs' message, not hang silently before init; the hang suggests the initramfs is missing or incomplete.

Practice this question →
71
MCQeasy

Refer to the exhibit. Which module is currently in use by another module?

A.usb_storage
B.kvm_intel
C.aesni_intel
D.kvm
AnswerD

kvm is used by kvm_intel.

Why this answer

The `lsmod` command shows that `kvm` has a 'Used by' count of 1, indicating another module is currently using it. The 'Used by' column lists the modules that depend on the given module, so `kvm` is in use by another module (likely `kvm_intel` or `kvm_amd`). This is the correct interpretation because the question asks which module is currently in use by another module, and `kvm` is the one with a non-zero 'Used by' value.

Exam trap

The trap here is that candidates often misinterpret the 'Used by' column as showing which modules are being used by the listed module, rather than which modules are using the listed module, leading them to incorrectly select `kvm_intel` or `usb_storage`.

How to eliminate wrong answers

Option A is wrong because `usb_storage` has a 'Used by' count of 0, meaning no other module is currently using it. Option B is wrong because `kvm_intel` has a 'Used by' count of 0, indicating it is not currently in use by another module; it is a dependency of `kvm` but not used by another module at this moment. Option C is wrong because `aesni_intel` has a 'Used by' count of 0, showing no other module depends on it currently.

Practice this question →
72
MCQmedium

A system administrator wants to change the default kernel boot parameters temporarily to debug a boot issue. Which step should be taken at the GRUB menu to modify kernel parameters for the next boot only?

A.Select the kernel entry and press 'e' to edit the boot parameters.
B.Edit /etc/default/grub and run update-grub to apply changes.
C.Press 'c' to enter the command line and modify parameters.
D.Press 'Esc' to access the advanced options menu.
AnswerA

Pressing 'e' allows temporary editing of boot entries.

Why this answer

Option A is correct because pressing 'e' at the GRUB menu allows you to edit the boot parameters for the selected kernel entry temporarily. This modifies the kernel command line only for the current boot, without persisting changes to disk. After editing, pressing Ctrl+X or F10 boots the system with the modified parameters, making it ideal for debugging boot issues.

Exam trap

The trap here is that candidates confuse the temporary edit (pressing 'e') with the permanent configuration method (editing /etc/default/grub), assuming both achieve the same result for a single boot.

How to eliminate wrong answers

Option B is wrong because editing /etc/default/grub and running update-grub makes permanent changes to the GRUB configuration, affecting all future boots, not just the next boot. Option C is wrong because pressing 'c' enters the GRUB command-line interface, which is used for manual commands like ls or insmod, not for editing kernel boot parameters for the next boot. Option D is wrong because pressing 'Esc' typically exits the GRUB menu or returns to the previous screen, not providing access to an advanced options menu for modifying kernel parameters.

Practice this question →
73
MCQeasy

Refer to the exhibit. What is the root filesystem device as specified in the kernel command line?

A.Could not be determined
B./dev/sda1
C./dev/sda3
D./dev/sda2
AnswerD

The 'root=/dev/sda2' kernel parameter sets /dev/sda2 as the root filesystem.

Why this answer

The kernel command line includes the parameter `root=/dev/sda2`, which explicitly specifies the root filesystem device as `/dev/sda2`. This is the standard way to indicate the partition where the root filesystem is mounted during boot, making option D correct.

Exam trap

The trap here is that candidates may assume the root filesystem is always on the first partition (e.g., `/dev/sda1`) or confuse it with other partitions like swap, but the kernel command line explicitly overrides such assumptions with the `root=` parameter.

How to eliminate wrong answers

Option A is wrong because the kernel command line in the exhibit clearly shows `root=/dev/sda2`, so the root filesystem device can be determined. Option B is wrong because `/dev/sda1` is not referenced in the kernel command line; it might be a common misconception that the root filesystem is always on the first partition, but here it is explicitly set to `/dev/sda2`. Option C is wrong because `/dev/sda3` is not specified in the kernel command line; this could be confused with a swap or other partition, but the root device is explicitly `/dev/sda2`.

Practice this question →
74
MCQmedium

Refer to the exhibit. The system boots successfully, but the root filesystem is mounted as read-only even after the boot process completes. Which of the following is the most likely cause?

A.The kernel command line contains the 'ro' parameter, which remains in effect.
B.The root device /dev/mapper/vg-root does not exist.
C.The root filesystem is damaged and forces read-only mount.
D.SELinux is enforcing and prevents write access to the root filesystem.
AnswerA

The 'ro' parameter causes the root filesystem to be mounted read-only unless remounted rw by init.

Why this answer

The 'ro' parameter in the kernel command line instructs the kernel to mount the root filesystem as read-only during early boot. Even after the boot process completes, if no subsequent remount (e.g., via init scripts or systemd) is performed, the root filesystem remains read-only. This is the most direct and common cause of a root filesystem staying read-only after boot.

Exam trap

The trap here is that candidates often assume a successful boot implies the root filesystem is automatically remounted read-write, overlooking that the 'ro' kernel parameter persists unless explicitly overridden by a remount command in the boot process.

How to eliminate wrong answers

Option B is wrong because if the root device /dev/mapper/vg-root did not exist, the system would fail to mount the root filesystem entirely, resulting in a kernel panic or boot failure, not a successful boot with a read-only mount. Option C is wrong because a damaged filesystem typically triggers a forced fsck and may be remounted read-only if corruption is detected, but the system would not complete a normal boot without intervention; the question states the system boots successfully, implying no critical damage. Option D is wrong because SELinux enforcing mode controls access control policies but does not force the root filesystem to be mounted read-only; it can prevent writes based on security contexts, but the mount state itself is determined by the kernel mount options, not SELinux.

Practice this question →
75
MCQeasy

A new network card driver module is not being loaded at boot. The administrator wants to ensure the module is loaded automatically without modifying the kernel command line. Which file should be used?

A./etc/modules-load.d/<name>.conf
B./lib/modules/$(uname -r)/modules.builtin
C./etc/modprobe.d/<name>.conf
D./etc/rc.local
AnswerA

This directory is used by systemd to load kernel modules at boot. Adding the module name to a new file here will load it automatically.

Why this answer

Option A is correct because /etc/modules-load.d/<name>.conf is the standard configuration directory used by systemd-modules-load.service to load kernel modules at boot without modifying the kernel command line. Files in this directory list module names (one per line) that are loaded automatically during early boot, making it the proper mechanism for ensuring a network card driver module is loaded.

Exam trap

The trap here is confusing /etc/modprobe.d/ (for module options and aliases) with /etc/modules-load.d/ (for specifying modules to load at boot), leading candidates to incorrectly choose option C.

How to eliminate wrong answers

Option B is wrong because /lib/modules/$(uname -r)/modules.builtin is a file that lists modules compiled directly into the kernel (built-in), not loadable modules; it is generated by the kernel build process and cannot be edited to force module loading. Option C is wrong because /etc/modprobe.d/<name>.conf is used to set module parameters or aliases (via modprobe), not to specify which modules to load at boot; it affects how modules are loaded but does not trigger automatic loading. Option D is wrong because /etc/rc.local is a legacy script for local startup commands, but it runs late in the boot process (after network services) and is not the standard mechanism for early module loading; systemd-based systems often disable it by default.

Practice this question →
Page 1 of 2 · 78 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Linux Kernel and System Startup questions.

Start 20-question session