LPIC-1 101-500 common mistakes
LPIC-1 101-500 · Understand the traps and how to avoid them.
Asked how to change the default boot entry or GRUB timeout, the candidate answers by editing /boot/grub/grub.cfg directly, or goes looking for /boot/grub/menu.lst, instead of changing /etc/default/grub and re-running grub-mkconfig (or update-grub).
Documentation from the GRUB Legacy era still circulates, and grub.cfg is the file that visibly contains the menu entries, so it looks like the correct place to make the change.
What to do instead
Memorise the split once and for all: /etc/default/grub (GRUB_DEFAULT, GRUB_TIMEOUT) plus the scripts in /etc/grub.d/ are the sources; grub-mkconfig -o /boot/grub/grub.cfg (or update-grub) regenerates the config. Practise one full edit-and-regenerate cycle, and learn GRUB_DEFAULT=saved with grub-set-default and grub-reboot for one-time boots.
On a persistence question ('make the service start at boot', 'change the default runlevel'), the candidate answers with SysV tooling - editing /etc/inittab, chkconfig, update-rc.d - or with 'systemctl start' when the question clearly wants the change to survive a reboot.
Both init systems appear in study material, start/enable/enable --now look interchangeable at a glance, and the runlevel-to-target mapping (3=multi-user.target, 5=graphical.target, 1/s=rescue.target, emergency.target) is easy to half-remember.
What to do instead
Build a two-column SysV/systemd table and drill the runtime-versus-persistent pairs: start/stop versus enable/disable, isolate versus set-default, plus systemctl get-default and systemctl status. Note explicitly that /etc/inittab does not exist on a systemd host and that 'telinit 3' maps to isolating multi-user.target.
Installs a downloaded .deb or .rpm with dpkg -i or rpm -ivh, hits an unmet-dependency error, and then concludes the package is corrupt or reaches for --force / --nodeps instead of switching tool layer.
The question stem usually names the low-level command, and the error message points at the package rather than at the missing dependency-resolution layer, so the tool choice feels correct.
What to do instead
Learn the layering as a rule: dpkg and rpm act on a single file and never fetch anything; apt, dnf and zypper resolve dependencies from configured repositories. Memorise the recovery commands: apt-get -f install (apt install -f), dnf/yum deploys, and apt install ./file.deb on modern apt. Treat --force and --nodeps as answers only when the question explicitly asks for them.
Mixes up package query flags - uses dpkg -l to list a package's files, rpm -qf to list what a package contains, or dpkg -S to show package details - and cannot state whether a command works on a repo name, an installed package or a local file.
The flags are single letters with no mnemonic, they differ between dpkg and rpm, and questions often ask the file-to-package direction, which is the reverse of the mental model most people build first.
What to do instead
Memorise pairs by direction: package to files = dpkg -L / rpm -ql; file to package = dpkg -S / rpm -qf; installed inventory = dpkg -l / rpm -qa; details = dpkg -s / rpm -qi; repo query = apt show / dnf info. Write the 5x2 grid out from memory until it is automatic, and note that rpm -qp* variants act on a local file.
Uses find with the wrong predicate or exec form: 'find / -name *.conf' unquoted (the shell expands the glob and find then errors), or confuses -exec {} \; with -exec {} +, or answers 'locate' for a question that requires matching by size, mtime or owner.
find's expression syntax - tests, operators and actions - is unlike any other command on the exam, so it tends to be memorised as one incantation rather than understood as three parts.
What to do instead
Always structure the command as path, then tests, then action. Drill the quoted form find /etc -name '*.conf', plus -iname, -type f, -size +10M, -mtime -7, -user and -perm; remember -exec {} ; runs once per file while -exec {} + batches. Know that locate reads the updatedb database and can miss recently created files.
Orders redirections incorrectly - writes 'cmd 2>&1 > file' when the intent was 'cmd > file 2>&1' - or uses '>' where the question wanted append, so stderr still lands on the terminal or the existing file is truncated.
The shell evaluates redirections left to right, but the syntax reads like a single 'send everything to the file' statement, so the order looks irrelevant.
What to do instead
Say the rule every time: redirections are processed left to right, and 2>&1 duplicates fd 2 onto wherever fd 1 points at that moment. Drill '> file 2>&1' and bash's '&> file' as correct, '2>&1 > file' as wrong; pair '>>' (append) with '>' (truncate), use tee -a to both display and append, and 2> /dev/null to discard errors.
Reaches for kill -9 by reflex, cannot say what happens to a job started with & when the shell exits, and treats the shell's job number (%1) as if it were the process ID.
SIGKILL appears to 'always work', and the distinction between the shell's job table and the kernel process table is an abstraction that collapses under time pressure.
What to do instead
Learn signal semantics rather than incantations: SIGTERM (15) requests a clean exit, SIGHUP (1) is delivered on terminal hangup (the reason nohup, disown and setsid exist), SIGSTOP/SIGCONT pair with Ctrl-Z, bg and fg. Remember jobs and %1 are local to one shell while ps -ef shows real PIDs, and reserve -9 for processes that ignore SIGTERM.
Computes umask backwards - stating the permissions a new file will receive rather than the bits that are removed - and treats setuid, setgid and the sticky bit as interchangeable answers.
umask is the complement of the creation mode (666 base for files, 777 for directories), which inverts the obvious intuition, and all three special bits sit in the same leading octal digit.
What to do instead
Work every umask question as subtraction: file mode = 666 minus umask, directory mode = 777 minus umask, noting that execute bits are never granted to files at creation. Then bind each special bit to a behaviour: setuid on a binary runs it as the owner (4), setgid on a directory makes new files inherit the group (2), sticky on a directory lets only the owner delete (1) - chmod 4755, 2770, 1777.
Writes /etc/fstab lines from memory with the wrong number or order of fields, puts a bare device name where the question expects a UUID, or cannot explain noauto, ro, defaults or user in the options field.
fstab has six whitespace-separated fields with no labels in the file, and it is nearly always read rather than authored, so the field order is rarely recalled deliberately.
What to do instead
Memorise the six fields (device, mountpoint, fstype, options, dump, pass) with a reference line such as UUID=xxxx /mnt/data ext4 defaults 0 2; root filesystem gets pass 1, other filesystems 2, none and swap 0. Get UUIDs from blkid or lsblk -f, test with mount -a, change options live with mount -o remount,ro /, and remember that a broken fstab can drop the system to emergency mode.
Answers a 'no space left on device' question with du when the real cause is exhausted inodes, and reports df output as though it described the size of a directory tree.
df and du both look like 'disk space' commands and their default units differ, while inode exhaustion produces exactly the same ENOSPC error as a full filesystem.
What to do instead
Lock the split: df -h and df -i answer 'how full is this filesystem / are inodes free'; du -sh answers 'how big is this tree'. Remember that a filesystem can be nearly empty in bytes yet report 100% IUse%, and that deleted-but-open files hide space (check with lsof and look for deleted entries). Practise df -i on a small filesystem to see inode limits in action.