20 Boot Process, Kernel & Devices Practice Questions & Answers

1. 1. An administrator is documenting what happens between pressing the power button and the login prompt on a Linux server with UEFI firmware. Which sequence is correct?

   • A.Firmware runs GRUB from its boot entry, GRUB loads the kernel and initramfs into memory, the kernel starts from the initramfs and loads storage drivers, switches to the real root, then runs systemd as PID 1✓ Answer
   • B.Firmware runs GRUB, GRUB mounts the real root filesystem itself and hands it to the kernel, the kernel then builds an initramfs in memory, switches into it, and finally runs systemd as PID 1
   • C.Firmware loads the kernel directly from its boot entry, the kernel loads GRUB to obtain its own parameters, mounts the real root filesystem, unpacks the initramfs, and then runs systemd as PID 1
   • D.Firmware runs GRUB, GRUB starts systemd as PID 1 from the boot partition, systemd loads the kernel and the initramfs, the kernel mounts the real root filesystem, and systemd starts the other units

   The firmware only knows how to run a boot loader named in its boot entry; GRUB then loads both the kernel image and the initramfs into RAM. The kernel uses the initramfs as a temporary root so it has the modules needed to reach the real root device, then performs a switch_root and executes /sbin/init, which on a systemd distribution is systemd running as PID 1 and pulling in the rest of the system.

   Source: bootup(7) systemd boot process documentation; CompTIA Linux+ objectives, System Management: basic boot processReport a problem with this question

2. 2. On an RPM-based server an administrator must make the kernel parameter transparent_hugepage=never take effect at every boot. What is the supported way to do that?

   • A.Edit the linux16 line inside the generated /boot/grub2/grub.cfg by hand, because that file is what the boot loader actually reads while booting
   • B.Add the parameter to GRUB_CMDLINE_LINUX in /etc/default/grub, then regenerate the configuration with grub2-mkconfig -o /boot/grub2/grub.cfg✓ Answer
   • C.Write the parameter into /proc/cmdline, because the kernel reads that file back on every boot in order to rebuild its own command line
   • D.Place the parameter in a new file under /etc/sysctl.d/ and load it with sysctl --system, so that the setting is applied on every boot

   grub.cfg is a generated file: the next kernel update or any run of the configuration generator overwrites hand edits. The source of truth is /etc/default/grub together with the scripts in /etc/grub.d/, and grub2-mkconfig rewrites grub.cfg from them. /proc/cmdline is read-only kernel output, and sysctl tunables are a different mechanism from boot-time kernel parameters.

   Source: GNU GRUB manual, simple configuration handling (/etc/default/grub and grub-mkconfig); grub2-mkconfig(8)Report a problem with this question

3. 3. A server was rebooted after a kernel parameter change, and the administrator wants to confirm which parameters the running kernel actually received. Which source shows that?

   • A./etc/default/grub, because the boot loader copies the values from that file straight into the kernel at hand-off
   • B./boot/grub2/grub.cfg, because the menu entry that was highlighted records what the kernel ended up receiving
   • C./proc/cmdline, because the kernel exposes in that file the exact command line it was started with✓ Answer
   • D./etc/sysctl.conf, because the boot-time kernel parameters are written back into that file by systemd

   The procfs file /proc/cmdline is the kernel reporting its own boot command line exactly as the boot loader handed it over. The GRUB files only describe what should have been passed, so they diverge from reality whenever the configuration was never regenerated or a different menu entry was booted.

   Source: proc(5) manual page, /proc/cmdlineReport a problem with this question

4. 4. A server boots to a graphical login, but the administrator needs a minimal single-user shell for this one boot only, without changing anything permanently. What should be done?

   • A.At the GRUB menu press e, append systemd.unit=rescue.target to the linux line, and boot that entry once✓ Answer
   • B.Run systemctl isolate rescue.target now, which also changes the default target so later boots use it
   • C.Edit /etc/inittab and set the initdefault line to 1, because systemd still reads that file on every boot
   • D.Run systemctl set-default rescue.target from rescue media, then reboot the server into that mode

   Editing the highlighted menu entry in the boot loader changes only the command line passed to the kernel for that single boot, and systemd honours systemd.unit= as the target to activate. set-default rewrites the default.target symlink and therefore persists, isolate switches the running system rather than selecting a boot mode, and systemd does not use /etc/inittab at all.

   Source: systemd(1) kernel command line option systemd.unit=; GNU GRUB manual, editing menu entries at bootReport a problem with this question

5. 5. On a systemd-based distribution, after the kernel has switched to the real root filesystem, what determines which services are brought up?

   • A.GRUB hands systemd a service list taken from /etc/default/grub, and systemd then starts each service named in that list in order
   • B.The kernel reads the runlevel field in /etc/inittab and runs the scripts in the matching /etc/rc?.d directory in numbered order
   • C.The kernel executes systemd as PID 1, and systemd activates the units pulled in by default.target, a symlink under /etc/systemd/system✓ Answer
   • D.The initramfs keeps running as PID 1 and launches the services listed in /etc/initramfs-tools before it hands over the root

   The kernel's last boot act is to execute the first user-space process, PID 1, which on these distributions is systemd. systemd then resolves default.target, a symlink it follows into the unit directories, and activates everything that target wants, which is how the run level equivalent is chosen.

   Source: systemd(1) and bootup(7); systemd.special(7) description of default.targetReport a problem with this question

6. 6. Why does a distribution ship an initial RAM filesystem instead of letting the kernel mount the root filesystem directly?

   • A.Because the kernel cannot run any user-space program until a separate RAM image has supplied it with a copy of systemd
   • B.Because the boot loader can address only a small part of the disk, so the RAM image supplies the rest of the kernel
   • C.Because the root filesystem has to be checked for errors and only code inside the RAM image is allowed to run fsck
   • D.Because the modules needed to reach the root device, such as storage and volume drivers, are not built into the kernel image✓ Answer

   A general purpose kernel is shipped small and modular, so the drivers for the particular controller, device mapper target or encrypted volume holding root are loadable modules living on the root filesystem itself. The initramfs breaks that circle: it is unpacked into RAM, provides those modules, assembles the root device and then switches over to it.

   Source: Linux kernel documentation, initrd/initramfs (admin-guide); dracut(8) description of the initramfs roleReport a problem with this question

7. 7. On a Debian-based server a new storage controller driver was installed, and after a reboot the boot stops in an emergency shell reporting that the root device does not exist. What is the most likely fix?

   • A.Reinstall the boot loader with grub-install, because an emergency shell means the boot loader lost its device map
   • B.Rebuild the initial RAM filesystem with update-initramfs -u -k all, so the new driver is present when root is mounted✓ Answer
   • C.Recreate the swap area with mkswap and enable it, because the kernel cannot finish booting without active swap
   • D.Run e2fsck on the root filesystem from rescue media, because a missing root device usually points to a damaged superblock

   The initramfs is a snapshot: a driver installed into /lib/modules afterwards is not inside it, so the early boot environment cannot see the root device and drops to the emergency shell. Regenerating the image, which on Debian-based systems is done with update-initramfs, embeds the new module; the equivalent step on RPM-based systems is dracut -f.

   Source: update-initramfs(8) and initramfs-tools(7)Report a problem with this question

8. 8. An administrator runs lsmod and sees: Module Size Used by nvme_core 155648 3 nvme loop 32768 0 The command rmmod nvme_core then fails. What does the third column show here?

   • A.The module is still in use, with three references and the nvme module depending on it, so it stays loaded until those are released✓ Answer
   • B.The module was compiled into the kernel image, so it still appears in the listing but can never be unloaded while the system is running
   • C.The module is blacklisted in /etc/modprobe.d, and a blacklisted module cannot be unloaded until that entry has been removed
   • D.The module was loaded from a path outside /lib/modules, so rmmod refuses to unload it and insmod must be used instead

   lsmod prints the contents of /proc/modules: module name, size, the use count, and the names of modules that depend on it. rmmod removes only an idle module, so a nonzero use count makes it fail; releasing the dependent module first, or using modprobe -r to unload the module together with its now-unused dependencies, is the way forward.

   Source: lsmod(8) and proc(5) /proc/modules; rmmod(8) and modprobe(8) -rReport a problem with this question

9. 9. Loading a driver with insmod /lib/modules/$(uname -r)/kernel/drivers/net/example.ko fails with unknown symbol errors, while modprobe example loads the same driver cleanly. Why?

   • A.insmod loads the module into user space, where kernel symbols are not visible, while modprobe loads it into kernel space
   • B.modprobe loads a signed copy of the module while insmod loads the unsigned file, and unsigned modules fail the symbol check
   • C.insmod only works on modules already listed in /etc/modules-load.d, and every other module has to be loaded using modprobe
   • D.modprobe reads the dependency map and loads the modules the driver needs first, while insmod loads only the single file it is given✓ Answer

   insmod is a minimal tool: it inserts exactly the file path it is handed and resolves nothing, so any symbol provided by another module is reported as unknown. modprobe takes a module name, consults the dependency information built by depmod, and inserts the prerequisites in order before the requested module.

   Source: modprobe(8) and insmod(8) manual pagesReport a problem with this question

10. 10. A vendor driver file was copied into /lib/modules/$(uname -r)/extra/, but modprobe still reports that the module cannot be found. Which command should be run next?

    • A.insmod, so that the module is registered with the kernel and becomes visible to modprobe on later loads
    • B.dracut -f, so that the module is added to the initial RAM filesystem and modprobe can then locate it
    • C.modinfo, so that the module metadata is written into the kernel and modprobe is able to resolve the name
    • D.depmod, so that the module dependency map which modprobe searches is rebuilt and includes the new file✓ Answer

    modprobe does not scan the module tree at run time; it looks the name up in the index files that depmod generates, chiefly modules.dep and its binary form. Until depmod is run for that kernel the freshly copied file is invisible, which is why dropping a module into place is always followed by depmod.

    Source: depmod(8) and modules.dep(5)Report a problem with this question

11. 11. A module is listed as blacklist ex_drv in /etc/modprobe.d/local.conf, yet after a reboot lsmod still shows it loaded. What explains this, and what fixes it?

    • A.Blacklisting stops only loading by name, so another module pulled it in as a dependency; use install ex_drv /bin/false instead✓ Answer
    • B.A blacklist entry needs a matching alias line to work, so an alias for the same module must be added in that same file
    • C.Files in /etc/modprobe.d are read only by insmod, so the entry has to be moved into /etc/modules-load.d to take effect
    • D.The initial RAM filesystem overrides modprobe rules entirely, so the module has to be removed from the kernel package itself

    A blacklist line only suppresses loading when that module name is requested directly or matched as an alias; it does not stop the module being loaded because some other module declares it as a dependency. Mapping the name to a command that does nothing with install ex_drv /bin/false, or passing modprobe.blacklist= on the kernel line, blocks it in every case.

    Source: modprobe.d(5), blacklist and install directivesReport a problem with this question

12. 12. A driver works on a server, but it never appears in lsmod output and rmmod reports that it is not currently loaded. What is the most likely explanation?

    • A.The driver was loaded with insmod rather than modprobe, and modules loaded that way are hidden from /proc/modules
    • B.The driver is blacklisted, so the kernel still provides its functions but does not register the module as being loaded
    • C.The driver is built into the kernel image rather than loaded at run time, so there is no separate module to list or remove✓ Answer
    • D.The driver is loaded inside the initial RAM filesystem only, and modules loaded there are dropped after the switch_root

    When a feature is selected as built-in at kernel build time it becomes part of the kernel image itself, so it has no entry in /proc/modules and cannot be unloaded; only features built as loadable modules can be listed and removed. modinfo or the modules.builtin file for the running kernel confirms which of the two a given driver is.

    Source: modinfo(8); Linux kernel Kbuild documentation on built-in versus loadable modulesReport a problem with this question

13. 13. The value in /proc/sys/net/ipv4/ip_forward was changed with sysctl -w net.ipv4.ip_forward=1 and took effect at once, but it was gone after a reboot. What makes such a setting persistent?

    • A.Adding the directive to /etc/default/grub and regenerating the boot loader configuration so the kernel receives it
    • B.Running sysctl -p once, which copies every current run-time value into the kernel image for all subsequent boots
    • C.Writing the directive into a file under /etc/sysctl.d/, so it is applied at boot and by sysctl --system afterwards✓ Answer
    • D.Editing the file under /proc/sys directly with a text editor, since files edited there are preserved across reboots

    The files under /proc/sys are a live window into kernel variables: a write changes the running kernel and nothing more, because procfs is not stored on disk. Persistence comes from configuration read at boot, namely the drop-in files under /etc/sysctl.d/ and /etc/sysctl.conf, which sysctl --system re-reads on demand.

    Source: sysctl(8) and sysctl.d(5); proc(5) description of /proc/sysReport a problem with this question

14. 14. A team wants a local filesystem whose own design lets them take cheap point-in-time snapshots of a subvolume and detect silent data corruption with checksums. Which filesystem type has those properties?

    • A.ext4, whose journal keeps a second copy of every data block so an earlier state can be restored on demand
    • B.tmpfs, which keeps a shadow copy of the data in memory and compares it against the on-disk copy on each read
    • C.xfs, whose extent-based allocator retains prior versions of each extent so a snapshot can be rolled back later
    • D.btrfs, whose copy-on-write design writes new blocks instead of overwriting and checksums data and metadata✓ Answer

    Copy-on-write means a modified block is written to a new location while the old one is still referenced, so a snapshot is just another reference to the existing blocks and costs almost nothing to create. Btrfs also stores checksums for data as well as metadata, which is what lets it detect corruption that the hardware never reported. A journal, by contrast, protects metadata consistency after a crash; it is not a snapshot mechanism.

    Source: btrfs(5) and btrfs-filesystem(8) documentation, copy-on-write, subvolumes and checksumsReport a problem with this question

15. 15. df -h on a server lists a filesystem mounted on /run with the type tmpfs. What is true of the data stored there?

    • A.It is written to a hidden partition on the boot disk and restored into /run automatically during the next boot
    • B.It is held in memory backed by swap and vanishes on reboot, so nothing under /run survives a restart of the server✓ Answer
    • C.It is stored in the journal of the root filesystem and replayed into /run once root is mounted read-write
    • D.It is a compressed image unpacked from the initial RAM filesystem and written back out to /boot at shutdown time

    tmpfs is a pseudo-filesystem with no block device behind it: its pages are held in the page cache and may be pushed out to swap under pressure, and the whole filesystem is discarded when it is unmounted or the machine restarts. That volatility is exactly why the hierarchy standard puts transient run-time state such as PID files and sockets under /run.

    Source: tmpfs(5) manual page; Filesystem Hierarchy Standard, /run run-time variable dataReport a problem with this question

16. 16. ls -l in /dev produces these two lines: brw-rw---- 1 root disk 8, 0 Sep 1 09:12 sda crw-rw-rw- 1 root root 1, 3 Sep 1 09:12 null What do the first character and the paired numbers tell the administrator?

    • A.sda is a block device and null a character device, and the numbers are the major and minor device numbers✓ Answer
    • B.sda is a backup device and null a cache device, and the numbers are the block size and the inode count
    • C.sda is a bus device and null a console device, and the numbers are the bus address and the interrupt line
    • D.sda is a buffered file and null a compressed file, and the numbers are the file size and the link count

    In a long listing the first character is the file type, where b marks a block device accessed in fixed-size blocks and c marks a character device accessed as a byte stream. Device nodes have no size field, so ls prints the major number, which identifies the driver, and the minor number, which identifies the particular device that driver handles.

    Source: Filesystem Hierarchy Standard, /dev device files; ls(1) file types and mknod(2) major and minor numbersReport a problem with this question

17. 17. lsblk reports the following on a server: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:0 0 476.9G 0 disk └─nvme0n1p2 259:2 0 475G 0 part / How should the two names be read?

    • A.nvme0n1 is the partition table of the first namespace and nvme0n1p2 is a second disk on the same controller
    • B.nvme0n1 is the loopback view of a disk image and nvme0n1p2 is the same data exposed as a raw block device
    • C.nvme0n1 is a device-mapper target and nvme0n1p2 is the physical disk that the target has been layered onto
    • D.nvme0n1 is the whole device and nvme0n1p2 is its second partition, as the p suffix and the part type show✓ Answer

    Kernel naming distinguishes the whole block device from the divisions inside it: on NVMe the namespace device gains a p and a number for each partition, and on SCSI or SATA style names the number is appended directly, as in sda and sda1. The TYPE column states which is which, printing disk for the device itself and part for a partition of it.

    Source: lsblk(8); Linux kernel admin-guide documentation on block device and partition namingReport a problem with this question

18. 18. A data-acquisition box appears as /dev/ttyUSB0 on one boot and /dev/ttyUSB1 on the next, depending on which adapter is detected first, and a script has to address the same box every time. What gives it a stable name?

    • A.A line in /etc/fstab mapping the device's serial number to a fixed name, which the kernel reads as each device appears
    • B.An entry in /etc/modprobe.d pinning the driver to one port, so that the kernel always numbers that adapter first
    • C.A rule in /etc/udev/rules.d matching the device's own attributes and creating a fixed SYMLINK for it✓ Answer
    • D.A directive in /etc/sysctl.d fixing the numbering order that the kernel uses when it enumerates USB devices

    Kernel device numbers are assigned in detection order and are therefore not stable. The device manager receives an event for every device that appears and evaluates its rule files, so a rule that matches attributes belonging to that unit, such as its vendor, model and serial, can create a predictable symlink; udevadm info shows the attributes available to match on.

    Source: udev(7) rules files in /etc/udev/rules.d and udevadm(8)Report a problem with this question

19. 19. A newly installed network card is unusable and ip link shows no matching interface. lspci -k prints the card's entry with Subsystem and Kernel modules lines, but no "Kernel driver in use" line. What does that indicate?

    • A.The card failed its own power-on self test, so the firmware disabled the slot and the operating system cannot claim it
    • B.No driver has claimed the device, so the module is missing, blacklisted, or absent from the running kernel's modules✓ Answer
    • C.The interface exists but is administratively down, so the driver released it and reports no name back to the kernel
    • D.The PCI bus has run out of addresses, so the kernel enumerated the card but could not assign any resources to it

    lspci -k prints the driver bound to each device on the line "Kernel driver in use", and its absence means the kernel sees the hardware but nothing has attached to it. The usual causes are a module that is not installed for this kernel, a blacklist entry in /etc/modprobe.d, or a signature rejection under Secure Boot; dmesg shows which of those it was.

    Source: lspci(8), the -k option reporting kernel drivers and modules handling each deviceReport a problem with this question

20. 20. A package installation on a server is rejected with a message that the package architecture does not match the system. Which command identifies the architecture that the kernel and packages have to match?

    • A.uname -r, which prints the running kernel release and with it the architecture it was compiled against
    • B.uname -m, which prints the machine hardware name of the running kernel, such as x86_64 or aarch64✓ Answer
    • C.lsblk -f, which prints the architecture recorded in the filesystem metadata of the root block device
    • D.dmesg -T, which prints the architecture the firmware reported to the kernel at the start of this boot

    uname -m reports the machine hardware name, which is the architecture string that binary packages and kernel packages are built for, and lscpu prints the same information with more detail. A package built for a different architecture cannot run on this kernel, which is why the package manager refuses it rather than installing it.

    Source: uname(1) machine hardware name; lscpu(1); rpm and dpkg package architecture matchingReport a problem with this question

Practice questions written to the published CompTIA Linux+ exam objectives and to standard Linux administration practice. CompTIA and Linux+ are marks of CompTIA, and Linux is a registered trademark of Linus Torvalds; this site is not affiliated with or endorsed by CompTIA. The real exam mixes multiple-choice items with performance-based questions that ask you to carry out a task in a simulated environment — those cannot be reproduced in a four-option format, so this bank covers the knowledge half and you should practise on a real system alongside it. CompTIA revises and version-numbers the objectives periodically: confirm the current objectives, exam code and requirements with CompTIA before testing. About the CompTIA Linux+ certification →