LPI Linux Essentials common mistakes
LPI Linux Essentials · Understand the traps and how to avoid them.
Treating the GNU GPL and the LGPL as interchangeable, or claiming the GPL forbids selling software, when asked to match a licence to a described scenario.
Candidates memorise the slogan 'free as in freedom' and assume 'free' means zero price, then cannot distinguish the copyleft scope of GPL from the weaker linking allowance of the LGPL or the permissive terms of MIT/BSD.
What to do instead
Build a comparison table with four rows (GPLv2, GPLv3, LGPL, MIT/BSD) and three columns: copyleft scope, whether linking into proprietary code is allowed, and redistribution obligations. Learn that selling GPL software is permitted as long as source and licence travel with it.
Answering that a Linux distribution consists only of the kernel plus a desktop environment, omitting the package manager, init system, and userland utilities.
Everyday use hides the stack; candidates interact with a GUI and never see that the distro is the integration of kernel, GNU/userland tools, package management, and default configuration.
What to do instead
For two distros you know (e.g. Debian and Fedora), list the kernel, init system, package manager and package format, default filesystem layout, and release model. Be able to explain what a distribution adds on top of the kernel.
Using a relative path when the task requires an absolute one, or forgetting that 'cd ..' moves up one level while 'cd ~' returns to the home directory.
Candidates practise commands only from their home directory, so relative paths happen to work and the distinction between /home/user/docs and docs is never forced.
What to do instead
Practise from /tmp and from /: run pwd, then reach a target with both a relative and an absolute path, and verify with pwd each time. Memorise that . is the current directory, .. the parent, ~ the home directory, and / the root.
Confusing input/output redirection with pipes, e.g. writing 'sort file > grep pattern' instead of 'sort file | grep pattern', or using '>' when append '>>' was needed.
Both operators look like 'send output somewhere', and shell metacharacter semantics are rarely taught explicitly; candidates also overwrite files when they meant to append.
What to do instead
Learn the rule: '|' connects stdout of one command to stdin of the next; '>' and '>>' connect stdout to a file (truncate vs append); '<' feeds a file to stdin; '2>' redirects stderr. Practise a three-stage pipeline such as 'cat /etc/passwd | cut -d: -f1 | sort | head'.
Misusing grep and regular-expression anchors, for example expecting 'grep ^root' to match root anywhere in the line, or using grep when a field-based tool such as cut or awk is required.
Candidates learn grep as 'search for text' without learning that ^ and $ anchor to line boundaries, and they default to grep for column extraction because it is the tool they know best.
What to do instead
Drill anchors and character classes on /etc/passwd: compare 'grep root', 'grep ^root', 'grep root$' and 'grep -v'. Then extract the same field with cut -d: -f1 and awk -F: '{print $1}' so the tool-selection pattern becomes automatic.
Assuming 'chmod 777 file' is the fix for a permission-denied error, rather than diagnosing ownership, group membership, and directory execute bits.
Permission denied is the most common error message a beginner sees, and 777 appears to work immediately, so the habit is reinforced without understanding the rwx triad or that directories need x to be entered.
What to do instead
Decode permissions symbolically and numerically: read the rwx triples, convert 644 and 755 to binary, and check owner and group with ls -l and id. Explain why a directory needs x, why a script needs r plus x, and why 777 is a security problem rather than a solution.
Treating sudo and su as identical, or being unable to explain what the setuid bit does and why it is dangerous.
Both commands elevate privileges in practice, so the difference (sudo runs one command as another user per sudoers policy and logs it; su starts a shell as another user and asks for that user's password) is never tested by daily use.
What to do instead
Write out the semantics of both commands, including which password is requested and what is logged, then inspect a real setuid binary with ls -l (the s in the owner execute position) and note that it runs with the file owner's effective UID.
Mixing up the package manager commands of different distributions, e.g. running 'apt install' on a system that uses dnf, or forgetting that 'apt update' refreshes metadata while 'apt upgrade' installs new versions.
Tutorials are copied from whichever distro the author used, and the two-step metadata/upgrade model of Debian-based systems is easy to conflate.
What to do instead
Memorise one row per family: Debian/Ubuntu uses apt/dpkg with .deb; Fedora/RHEL uses dnf/rpm with .rpm; and note that dnf check-update plays the role of apt update. Practise install, remove, search, and list-installed on both if possible.
Answering questions about process management without distinguishing a PID from a job number, or expecting 'kill' to always terminate a process.
Ctrl-C and Ctrl-Z are learned as 'stop things', so candidates do not realise SIGTERM can be caught and ignored while SIGKILL cannot, and they confuse shell job control with process signals.
What to do instead
Learn the common signals (TERM, KILL, HUP, INT, STOP) with their numbers and behaviour, and practise ps, top, kill -9, and jobs/fg/bg so the PID versus job-number distinction is concrete.
Misreading the second field of /etc/shadow or assuming password hashes are stored in /etc/passwd, and being unable to say what the x placeholder means.
Candidates memorise the seven fields of /etc/passwd from a diagram but never look at the files, so they miss that hashes moved to /etc/shadow, which is readable only by root.
What to do instead
Open both files on a test system: map each colon-separated field of /etc/passwd (name, x, UID, GID, GECOS, home, shell) and /etc/shadow (name, hash, last-change day, min, max, warn, inactive, expire, reserved), and note the meaning of *, ! and empty in the hash field.