Question 1

System administration: Which command cleanly halts (powers down) a Linux system by changing runlevel to 0?

Accepted Answer

Introduction / Context: Shutting down a Linux system safely ensures filesystems are synced and services are stopped in order. There are several commands and key sequences, but one classic method is to request runlevel 0 (halt) through init/systemd compatibility. Given Data / Assumptions: Legacy SysV-style runlevels: 0 = halt/poweroff, 6 = reboot. We want a clean halt sequence, not just a reboot or terminal key combo. Modern systems may use systemctl poweroff, but init 0 remains widely recognized. Concept / Approach: init 0 transitions the system to runlevel 0, triggering shutdown scripts to stop services, unmount filesystems, and power off. It is safe and orderly. Other syntaxes like shutdown -h now achieve the same end; the distractor options here are incorrect or non-Linux specific. Step-by-Step Solution: From a root shell, run: init 0Alternatively: shutdown -h now or systemctl poweroffWait for the system to stop services and power off. Verification / Alternative check: Observe console messages indicating services stopping and filesystems unmounted. After completion, hardware powers down or halts at a safe state. Why Other Options Are Wrong: shutdown -t: Incomplete/incorrect syntax; -t typically specifies a timeout, not a full command. shutdown -g -y0: A Solaris-style syntax, not Linux standard. Ctrl+Alt+Del: Usually triggers reboot, not halt. None of the above: Incorrect because init 0 is valid. Common Pitfalls: Forgetting required privileges; abruptly powering off without shutdown risks data loss; confusing halt vs reboot runlevels. Final Answer: init 0

Question 2

Creating a boot floppy from UNIX/Linux: Which command writes a raw disk image to a device (e.g., making an installation boot floppy)?

Accepted Answer

Introduction / Context: Before USB installers became standard, administrators frequently created boot floppies from UNIX/Linux by writing raw images to floppy devices. The key requirement is a tool that copies bytes exactly as-is to a block device. Given Data / Assumptions: You have a .img (or similar) boot image file. You are on UNIX/Linux with device nodes such as /dev/fd0 or /dev/sdX. You need a byte-for-byte write, not filesystem-level copy. Concept / Approach: The dd utility performs low-level copying and conversion between files and devices. It is ideal for writing boot images to removable media. rawrite is typically a DOS/Windows tool used from that environment, not UNIX. Step-by-Step Solution: Insert target media (e.g., floppy or USB).Execute: dd if=boot.img of=/dev/fd0 bs=1440k conv=sync,noerrorWait for completion; dd reports bytes transferred.Sync buffers: run sync before removal. Verification / Alternative check: Try booting from the created media; or mount read-only to verify expected contents when applicable. Why Other Options Are Wrong: fdisk: Partitioning tool, not image writer. fsck: Filesystem check/repair, not for imaging. rawrite: DOS/Windows utility, not native to UNIX for this task. None of the above: Incorrect because dd is correct. Common Pitfalls: Accidentally targeting the wrong device (data loss); forgetting to run as root; omitting sync; using cp instead of dd, which won’t create a proper boot sector image. Final Answer: dd

Question 3

Shell wildcards: Which single wildcard matches exactly one character in UNIX shell globbing?

Accepted Answer

Introduction / Context: Shell wildcards (globs) expand patterns to filenames and paths. Knowing how ?, , and character classes work is essential for accurate file selection and scripting. Given Data / Assumptions: We are using typical Bourne-like shells (sh, bash, ksh, zsh) with standard globbing. We need a wildcard that matches one character only. Other glob tokens match sets or arbitrary lengths. Concept / Approach: The ? wildcard matches exactly one character. The * wildcard matches any number of characters, including none. Character classes [ijk] match exactly one character but limited to the listed set; [!ijk] matches one character not in the set. Step-by-Step Solution: Need exactly one arbitrary character → use ?Need zero or more characters → use Need one character from a set → use [abc]Need one character not in a set → use [!abc] Verification / Alternative check: Test with files: touch a1 a2 ab; ls a? matches a1 and a2 but not ab if more characters follow; ls a matches all beginning with a. Why Other Options Are Wrong: : Matches zero or more characters, not exactly one. [ijk]: One character but restricted to i, j, or k only. [!ijk]: One character not i, j, or k. None of the above: Incorrect since ? is correct. Common Pitfalls: Confusing shell globs with regular expressions; expecting ? to match directory separators when globbing (it does not cross /). Final Answer: ?

Question 4

Networking fundamentals: IPv4 addresses use how many bits for the full address length?

Accepted Answer

Introduction / Context: Internet Protocol version 4 (IPv4) is the classic addressing scheme still widely used across the Internet. Knowing the bit length of IPv4 addresses is a foundational networking concept and explains address exhaustion issues. Given Data / Assumptions: The question refers specifically to IPv4 (not IPv6). IPv4 addresses are commonly written in dotted-decimal notation with four octets. Each octet represents 8 bits. Concept / Approach: IPv4 uses 32 bits in total. The dotted-decimal format (a.b.c.d) corresponds to four 8-bit octets, totaling 32 bits. This supports approximately 4.29 billion unique addresses before factoring in reservations and subnetting. Step-by-Step Solution: Recall: 1 octet = 8 bits.IPv4 has 4 octets → 4 * 8 = 32 bits.Therefore the correct choice is 32-bit addresses. Verification / Alternative check: Observe subnet masks such as 255.255.255.0 which correspond to 24 network bits; CIDR notation /x signifies the number of bits, confirming a 32-bit ceiling (e.g., /32 for a host route). Why Other Options Are Wrong: 16-bit, 8-bit: Too small for IPv4 and do not match dotted-decimal structure. 64-bit: Refers to IPv6 fragments (IPv6 is 128-bit), not IPv4. None of the above: Incorrect because 32-bit is correct. Common Pitfalls: Confusing IPv4 with IPv6; mixing IPv4 CIDR prefix lengths with total address size; assuming dotted notation implies decimal rather than binary-based octets. Final Answer: 32-bit addresses

Question 5

Classic UNIX super-server: Which of the following services is typically NOT managed by inetd/xinetd by default?

Accepted Answer

Introduction / Context: Historically, inetd (and its successor xinetd) acted as a super-server that listened on behalf of many lightweight network services, launching per-connection daemons on demand. Some services, however, are designed to run as standalone daemons. Given Data / Assumptions: We consider default/typical configurations on UNIX/Linux. Legacy small services (e.g., finger, time, talk/ntalk) were often inetd-managed. SSH (Secure Shell) is generally a persistent daemon (sshd). Concept / Approach: inetd/xinetd spawns services on demand for simple, short-lived protocols. SSH typically runs as a standalone daemon (sshd) to handle encrypted sessions efficiently and to support features like key exchange and persistent connections. Although inetd wrappers are possible, they are not the usual or recommended default. Step-by-Step Solution: Identify inetd-style services: time, finger, ntalk → usually in /etc/inetd.conf or xinetd.d/.Identify SSH: managed by system service manager (e.g., systemd service sshd), not inetd by default.Select the service not monitored by inetd: SSH. Verification / Alternative check: Check service definitions: systemctl status sshd vs. legacy inetd/xinetd configuration files; classic examples list finger, talk/ntalk, time/echo under inetd. Why Other Options Are Wrong: time, ntalk, finger: Canonical inetd-managed small services. None of the above: Incorrect because SSH is typically not inetd-managed by default. Common Pitfalls: Assuming that any network service can or should be inetd-managed; while possible, performance and feature needs often dictate standalone daemons like sshd. Final Answer: SSH

Question 6

Email protocols: Which TCP/IP protocol is used to transfer electronic mail from one mail server to another across the Internet?

Accepted Answer

Introduction / Context: Email delivery across the Internet relies on a standard application-layer protocol to relay messages between mail transfer agents (MTAs). Recognizing this protocol helps in troubleshooting mail flow and configuring servers. Given Data / Assumptions: We are focusing on server-to-server message transfer (relay), not local client retrieval. Common TCP/IP protocols are listed as distractors. Terminology: MTA = Mail Transfer Agent (e.g., Postfix, Sendmail, Exim). Concept / Approach: SMTP (Simple Mail Transfer Protocol) moves mail between MTAs over TCP, typically on port 25 (and 587/Submission for client submission). Retrieval by clients uses POP3 or IMAP, which are not listed here. FTP is for file transfers, SNMP for network management, and RPC for generic remote procedure calls. Step-by-Step Solution: Identify the protocol that relays mail between servers → SMTP.Map ports and roles: SMTP on 25 (server relay) and 587 (submission).Choose the matching option. Verification / Alternative check: Examine mail logs showing SMTP transactions (HELO/EHLO, MAIL FROM, RCPT TO, DATA). Network captures reveal SMTP commands over TCP. Why Other Options Are Wrong: FTP: File transfer, not email. SNMP: Device monitoring/management. RPC: Generic remote calls, not mail relay. None of the above: Incorrect because SMTP is correct. Common Pitfalls: Confusing SMTP (server relay) with client mailbox access (POP3/IMAP); assuming SMTP provides message encryption by default (STARTTLS is an extension). Final Answer: SMTP

Question 7

Linux user management: default group assignment when creating a new account  You have just added a new user named 'kara' using standard Linux tools (for example, useradd). By default, to which primary group is this user typically added?

Accepted Answer

Introduction / Context: When a new account is created in Linux, the system assigns both a user ID and a primary group. Many modern distributions implement a “user private group” model, where each user gets a primary group with the same name as the username. Understanding this default is important for permissions and collaborative workflows. Given Data / Assumptions: The account name created is kara. Standard user creation tools such as useradd or adduser are used with default settings. A typical Linux distribution policy (user private group scheme) is assumed. Concept / Approach: Under the user private group (UPG) scheme, the system creates a group with the same name as the user and sets it as the primary group. This simplifies default umask and collaborative permission handling, preventing unintended group write access while allowing flexible project groups via supplementary groups. Step-by-Step Solution: Create the account: useradd kara (defaults applied).System checks group database for group named kara; if not present, it creates it.The new user's primary group (GID) is set to the group named kara.Verify with: id kara or getent passwd kara and getent group kara. Verification / Alternative check: Run id kara. The output typically shows gid=... (kara) confirming the primary group name equals the username. On older or non-UPG systems, the default group might be users, but mainstream distributions have long defaulted to UPG. Why Other Options Are Wrong: root: Ordinary users are not placed in the root group by default. group/user: These are generic words, not standard default primary groups on modern systems. None of the above: Incorrect because the expected default is the group with the same name as the user, here kara. Common Pitfalls: Assuming the default group is users on every distribution or forgetting that enterprise policies may override defaults. Always verify with id username when unsure. Final Answer: kara

Question 8

chmod practice: remove execute for the user and grant read to group and others  For a file named 'letter', which command removes the user's execute permission while adding read permission for the group and others (without altering other bits)?

Accepted Answer

Introduction / Context: Unix/Linux file permissions control access for the user (owner), group, and others. The chmod command supports symbolic changes that precisely add or remove specific rights without overwriting other bits. This question checks your ability to translate a verbal permission change into the correct chmod syntax. Given Data / Assumptions: Target file: letter. Required changes: remove execute from user; add read to group and others. No other permissions should be changed. Concept / Approach: Symbolic modes allow granular updates: u, g, o designate classes; + adds a permission; - removes it. You can combine multiple operations in one command by separating them with a comma, and chmod applies them left to right to the file's mode bits. Step-by-Step Solution: Translate “remove execute for user” to: u-x.Translate “add read for group and others” to: go+r.Combine both with a comma and supply the filename: chmod u - x, go + r letter.Confirm with: ls -l letter to observe updated permissions. Verification / Alternative check: Before and after comparisons using ls -l show x removed from the user field and r added to the group and others fields. No other bits should change because symbolic mode modifies only specified bits. Why Other Options Are Wrong: chmod go + x, u - x: adds execute for group/others, the opposite of the requirement. chmod g - x, uo + r: removes execute from group, not user. chmod go + r, u + x: adds execute to user, contradicting the removal requirement. None of the above: incorrect because option with u - x, go + r is correct. Common Pitfalls: Using an absolute numeric mode (like 744) which may inadvertently change other bits, or reversing + and - signs under time pressure. Always read the requirement carefully. Final Answer: chmod u - x, go + r letter

Question 9

Automated installations on Red Hat–style systems  Which tool is used to generate configuration for automated installs on matching hardware (Kickstart-based approach)?

Accepted Answer

Introduction / Context: Enterprise environments often require installing the same Linux configuration across many machines. Red Hat–style distributions support Kickstart, which automates installation using an answer file (ks.cfg). Utilities exist to help create this file for repeatable deployments on identical or similar hardware. Given Data / Assumptions: We are discussing Red Hat–style automated installs. Goal: create configuration for unattended installations. Hardware is similar or identical among targets, simplifying automation. Concept / Approach: Kickstart installations rely on a configuration file specifying language, keyboard, partitioning, packages, and post-install scripts. Tools such as mkkickstart (and later system-config-kickstart) help generate the ks.cfg file. The installer then consumes this file over the network, local media, or via HTTP to drive a hands-free installation. Step-by-Step Solution: Choose a utility to produce a Kickstart file: mkkickstart.Customize settings: time zone, partitions, package groups, and post scripts.Host ks.cfg via HTTP/NFS or place it on boot media.Boot targets with installer parameters referencing the Kickstart file (for example, ks=http://server/ks.cfg). Verification / Alternative check: Validate by performing a test install on one machine, ensuring identical outcomes on subsequent systems. Logs and Anaconda output confirm the Kickstart file was parsed and applied. Why Other Options Are Wrong: bzimage.img: refers to a kernel image artifact, not an install automation tool. tar: a general archiving tool, not specific to automated installs. ghost: a proprietary disk imaging product from another ecosystem, not native to Red Hat Kickstart. None of the above: incorrect because mkkickstart is the relevant utility. Common Pitfalls: Confusing imaging (bit-for-bit clones) with scripted installs, forgetting to match driver and storage settings for target hardware, and omitting post-install configuration tasks in the Kickstart file. Final Answer: mkkickstart

Question 10

Basic file management on Linux/Unix  Which command is used to delete (remove) a file from the filesystem?

Accepted Answer

Introduction / Context: Every Unix/Linux user needs to manage files from the shell. Deleting files is a routine operation and is performed with a specific utility that removes directory entries. Knowing the correct command prevents confusion with copy, move, or rename operations. Given Data / Assumptions: The task is to remove a file (not a directory). We are operating in a typical POSIX shell environment. Permissions allow the deletion (write and execute on the parent directory). Concept / Approach: On Unix-like systems, rm removes directory entries for files. If the last link to a file is removed and no process holds it open, the storage is reclaimed by the filesystem. For directories, rmdir or rm -r is used. Options such as -i prompt for confirmation, -f forces removal, and -r recursively removes directories and their contents. Step-by-Step Solution: Identify the target: for example, notes.txt in the current directory.Run rm notes.txt to remove the file.Use rm -i notes.txt if you want an interactive confirmation.Verify deletion by listing the directory: ls. Verification / Alternative check: If the file persists, check permissions on the parent directory and confirm no alias or function overrides rm. Also verify that the filename is correct (quote paths with spaces). Why Other Options Are Wrong: rename: not a standard standalone command on all systems; renaming does not delete. delete: not the POSIX-standard tool for removal. cp: copies files; it does not remove them. None of the above: incorrect because rm is the correct deletion command. Common Pitfalls: Using rm -r carelessly, globbing patterns that match more files than intended, or lacking proper backups. Consider rm -i or trash utilities for safety. Final Answer: rm

Question 11

Lightweight file transfer over IP networks  Which TCP/IP protocol provides simple, minimal-overhead file transfers, often used for bootstrapping devices?

Accepted Answer

Introduction / Context: There are several protocols for transferring files across networks. Full-featured options like FTP support authentication and directory listings, but some scenarios (for example, PXE boot, firmware loading) need a minimal, simple protocol with very low overhead and a trivial implementation. Given Data / Assumptions: The requirement is minimal capability and minimal overhead. Use cases include boot environments and embedded devices. Security and advanced features are not the focus. Concept / Approach: TFTP (Trivial File Transfer Protocol) uses UDP and a very small command set for file read/write. Its simplicity makes it ideal for environments where a full network stack or user interaction is unavailable, such as network booting via PXE. TFTP typically operates on UDP port 69 and depends on external mechanisms for access control and security. Step-by-Step Solution: Identify the minimal transfer requirement: trivial, no advanced features.Select TFTP over FTP because TFTP is lightweight and UDP-based.Typical workflow: a client requests a boot image from a TFTP server during PXE boot.Confirm that the environment supports TFTP (server running, firewall allowed). Verification / Alternative check: Review PXE boot logs or attempt a transfer with tftp client to validate that small binaries can be fetched without authentication or directory traversal complexity. Why Other Options Are Wrong: TELNET: remote terminal protocol; not a file transfer mechanism. FTP: feature-rich but heavier, uses TCP and additional control/data channels. RARP: resolves IP address from a MAC address; not file transfer. None of the above: incorrect because TFTP matches the description. Common Pitfalls: Using TFTP on untrusted networks without safeguards, misunderstanding that it lacks authentication, and confusing firewalls due to dynamic UDP port usage. Final Answer: TFTP

Question 12

Locating Linux kernel headers and sources for module builds  On a traditional system preparing to build a modularized kernel, where are the kernel headers and source commonly located?

Accepted Answer

Introduction / Context: Compiling a kernel or out-of-tree kernel modules requires matching headers and often the full source tree. Historically, distributions placed the kernel source and headers in a conventional directory to simplify builds and documentation references. Given Data / Assumptions: The system uses a traditional layout (not containerized or using distribution-specific variants). Packages kernel-headers and kernel-source (or kernel-devel) are installed. We are preparing to build a modularized kernel or modules. Concept / Approach: Older and many instructional references point to /usr/src/linux as the canonical path for the Linux source tree or a symlink to the active kernel source. While modern distributions may use versioned directories (for example, /usr/src/kernels/), the commonly taught location remains /usr/src/linux in fundamentals courses and legacy documentation. Step-by-Step Solution: Install kernel headers and source (or kernel-devel) via the package manager.Verify presence or symlink: ls -l /usr/src and check for linux.Point build systems (for example, make) to that tree as needed.Ensure the source matches the running kernel version to avoid ABI mismatches. Verification / Alternative check: Run uname -r to get the running kernel version and ensure your headers under /usr/src/linux or /usr/src/kernels match. If not, install the appropriate kernel-devel package. Why Other Options Are Wrong: /usr/local: general local installs; not the standard kernel source path. /usr/sre/redhat: misspelled/nonstandard path. /usr/bin: executable binaries, not source trees. None of the above: incorrect because /usr/src/linux is the conventional answer. Common Pitfalls: Building against mismatched headers, removing the linux symlink, or assuming the headers are installed by default. Always align versions for reliable builds. Final Answer: /usr/src/linux

Question 13

Quick file viewing utilities: show the end of a file  Which command displays the last 10 lines of a file by default?

Accepted Answer

Introduction / Context: Log inspection and troubleshooting often require viewing the most recent lines of a growing file. Unix provides a simple utility that, by default, shows the last 10 lines and can follow a file as it grows in real time, making it indispensable for monitoring logs and long-running processes. Given Data / Assumptions: We want to see the last few lines of a text file. Default behavior is acceptable (10 lines). Standard Unix command set is available. Concept / Approach: The tail command prints the end of files. With no options, it outputs the last 10 lines. Adding -n changes the number of lines, and -f follows the file, printing appended data in real time, which is ideal for tailing logs during service restarts or deployments. Step-by-Step Solution: Run tail /var/log/some.log to see the last 10 lines.Use tail -n 50 file to see the last 50 lines.Use tail -f file to follow new lines as they are written.Combine with grep: tail -f file | grep pattern for live filtering. Verification / Alternative check: Compare with head (first lines) to understand the difference. cat shows the whole file, which is inefficient for very large logs when only the end is needed. Why Other Options Are Wrong: grep: searches text; it does not specifically show the last lines. head: shows the first lines, not the last. cat: dumps entire file to standard output. None of the above: incorrect because tail fits perfectly. Common Pitfalls: Forgetting -n when a different count is required, using tail -f without stopping it in scripts, and tailing the wrong rotated log file. Use tail -F to handle log rotations gracefully. Final Answer: tail

Question 14

vi editor navigation: move forward to the end of the current/next word  In the vi editor's normal mode, which single-key command moves the cursor forward to the end of a word?

Accepted Answer

Introduction / Context: Efficient text editing in vi (and Vim) relies on motion commands. Learning single-key motions for word-wise navigation speeds up editing dramatically. This question focuses on the motion that moves the cursor forward to the end of a word. Given Data / Assumptions: We are in vi normal mode (not insert mode). The goal is to move to the end of the current or next word. Default word boundaries are assumed (simple word definition). Concept / Approach: vi provides word motions: w moves to the beginning of the next word, b moves backward to the beginning of the previous word, and e moves forward to the end of the current or next word. These motions can be combined with operators like d (delete) and c (change) for powerful text manipulation (for example, de deletes to the end of the word). Step-by-Step Solution: Enter normal mode (press Esc if needed).Press e to move the cursor to the end of the current word; pressing e again advances to the end of the next word.Use counts to jump multiple words: 3e moves to the end of the third word forward.Combine with operators, for example, ce to change from the cursor to the end of the word. Verification / Alternative check: Open any text in vi and try w, b, and e to feel the difference between beginning-of-word and end-of-word motions. Observe how punctuation and whitespace affect movement under default settings. Why Other Options Are Wrong: c: begins a change operation; not a motion by itself for cursor movement. d: begins a delete operation; not a pure motion. b: moves backward to the beginning of the previous word, not forward to the end. None of the above: incorrect because e is correct. Common Pitfalls: Confusing e with w, forgetting to be in normal mode, or using motions without counts when large jumps are needed. Practice in normal mode to build muscle memory. Final Answer: e

Question 15

Mounting NFS file systems on Unix/Linux  Which command is used to mount a remote NFS export into the local directory tree?

Accepted Answer

Introduction / Context: Network File System (NFS) allows directories to be shared across machines. On the client side, the standard way to attach a remote NFS export to a local mount point is with the system's mount utility. Recognizing the correct tool avoids confusion with server daemons and legacy helper names. Given Data / Assumptions: A remote NFS server exports a directory (for example, server:/share). We need to mount it locally (for example, at /mnt/share). Appropriate NFS client packages are installed. Concept / Approach: The mount command is the general-purpose utility for attaching filesystems. With NFS, you either specify the -t nfs or rely on autodetection. Systemd-based systems may also use mount units or fstab entries, but the underlying action still uses mount to bind the remote export into the local namespace. Step-by-Step Solution: Create a local mount point: mkdir -p /mnt/share.Run: mount -t nfs server:/share /mnt/share.Verify with: df -h or mount | grep /mnt/share.For persistence, add a line to /etc/fstab with the nfs type and options. Verification / Alternative check: Confirm access by listing contents (ls /mnt/share). If mounting fails, check firewall, exports on the server (/etc/exports), and version negotiation (for example, vers=3 or vers=4). Why Other Options Are Wrong: nfsmount: largely historical/legacy helper; modern systems use mount directly. knfsd: refers to kernel NFS server daemon side, not the client command. All of the above: inaccurate because the correct, current client command is mount. None of the above: incorrect because mount is correct. Common Pitfalls: Forgetting to create the mount point, missing user-space rpcbind or nfs-utils on older setups, and neglecting to specify correct mount options for performance and security. Final Answer: mount

Question 16

Bootloader configuration after compiling a new kernel (LILO-based systems)  After building a new kernel image, which configuration file must be edited (and updated) so the system can boot the new kernel using LILO?

Accepted Answer

Introduction / Context: On systems that use LILO (Linux Loader) rather than GRUB, adding a new kernel requires updating the bootloader configuration so the boot menu knows about the new image and its initrd. Knowing the correct configuration file and update procedure is essential for a successful reboot. Given Data / Assumptions: Bootloader is LILO, not GRUB. A new kernel image (for example, /boot/vmlinuz-new) and possibly a new initrd have been generated. Root privileges are available to modify bootloader settings. Concept / Approach: LILO reads its configuration from /etc/lilo.conf. After editing this file to add or update an image stanza pointing to the new kernel (and initrd), you must run the lilo command to write the boot sector map. Without re-running lilo, changes will not take effect and the system may still boot the old kernel. Step-by-Step Solution: Copy new kernel to /boot and ensure a unique filename.Edit /etc/lilo.conf to add an image= line, label, root, and optional initrd.Run lilo and check for “Added label” messages and errors.Reboot and select the new label from the boot menu. Verification / Alternative check: Run lilo -v for verbose output; confirm that the new kernel is listed. If using GRUB instead of LILO, the file would be different (for example, /boot/grub/grub.conf or later /boot/grub2/grub.cfg managed by tools). Why Other Options Are Wrong: /boot/lilo.conf: nonstandard; LILO configuration is typically under /etc/lilo.conf. /etc/conf.modules: old module configuration file; unrelated to LILO menu entries. /etc/named.boot: DNS server (BIND) configuration; unrelated to bootloaders. None of the above: incorrect because /etc/lilo.conf is correct for LILO. Common Pitfalls: Forgetting to rerun lilo after editing the config, mis-typing the kernel path, or omitting a required initrd line for modular kernels. Always keep the old kernel as a fallback entry. Final Answer: /etc/lilo.conf

Linux Questions