Filesystem Hierarchy & Package Management
Learn the Filesystem Hierarchy Standard every distro follows, and how apt, dnf, and pacman solve the same dependency-resolution problem with different syntax.
Learning Objectives
- → Navigate the Linux Filesystem Hierarchy Standard (FHS) and explain what belongs in /etc, /var, /usr, /opt
- → Explain how a package manager resolves dependencies and tracks installed files
- → Compare apt (Debian/Ubuntu), dnf (Fedora/RHEL), and pacman (Arch) at a conceptual level
- → Distinguish hard links from symbolic links, and inodes from filenames
- → Query installed packages and the files they own without modifying the system
The Filesystem Hierarchy Standard (FHS)
Every mainstream Linux distribution follows the same top-level layout, so knowledge of one distro transfers almost entirely to the next.
| Path | Purpose |
|---|---|
| /bin, /usr/bin | Essential user binaries |
| /sbin, /usr/sbin | System binaries (historically root-only) |
| /etc | System-wide configuration files (plain text) |
| /var | Variable data: logs, caches, spool, databases |
| /home | User home directories |
| /opt | Optional/third-party software bundles that don't fit the standard layout |
| /tmp | Temporary files, cleared on reboot |
| /proc, /sys | Virtual filesystems exposing kernel and process state, not real disk data |
Inodes, Filenames, and Links
A filename is just a directory entry pointing at an inode — the real record of a file's metadata (permissions, owner, size, timestamps, and pointers to the actual data blocks on disk). This is why:
- A hard link is a second directory entry pointing at the same inode — delete the original name and the data survives until the last link is removed.
- A symbolic link (symlink) is a separate tiny file that stores a path, not an inode reference — delete the target and the symlink becomes "broken" or "dangling."
stat <file> shows a file's inode number and link count directly.
Package Managers: The Same Job, Different Syntax
| Distro family | Package manager | Package format | Example install |
|---|---|---|---|
| Debian/Ubuntu | apt (front-end) / dpkg (back-end) | .deb | apt install nginx |
| Fedora/RHEL/CentOS | dnf (front-end) / rpm (back-end) | .rpm | dnf install nginx |
| Arch | pacman | compressed tarball | pacman -S nginx |
Every package manager solves the same three problems:
- Dependency resolution — installing
nginxalso pulls in the exact library versions it needs - Repository tracking — packages come from signed, versioned repositories rather than random downloads
- Clean removal — uninstalling a package removes exactly the files it installed, nothing more, nothing less
Querying What's Installed (safe, read-only)
You don't need root to ask questions about installed packages:
dpkg -l— list all installed packagesdpkg -L <package>— list every file owned by a packagedpkg -S <path>— reverse-lookup which package owns a given file path
The rpm/dnf equivalents are rpm -qa, rpm -ql <package>, and rpm -qf <path>.
Mount Points and Virtual Filesystems
/proc and /sys aren't stored on disk at all — the kernel generates their contents on the fly. /proc/<pid>/ exposes a live view of every running process; cat /proc/cpuinfo reads live hardware info without needing a dedicated command.
Common Pitfalls
- Confusing
/opt(third-party bundled software) with/usr/local(locally-compiled software meant to follow the FHS layout) - Hand-editing a file that belongs to a package — the next update silently overwrites your changes; use a
.d/config directory or override mechanism instead - Assuming a broken symlink means the whole filesystem is corrupted — it usually just means the target moved or was deleted
- Treating
dpkg -loutput width as fixed — always check theii/rc/unstatus column, sincercmeans "removed but config remains," not "installed"
System-wide logs, caches, and spool files all live under the same top-level directory, separate from configuration and separate from binaries.
Which directory conventionally holds system-wide log files?
A symlink stores a path, not an inode reference. If that path stops existing, the symlink still exists but points at nothing.
A symbolic link that points to a deleted file is called a:
dpkg's lowercase and uppercase flags do very different things: one lists packages, the other lists the files a package owns.
Which dpkg command lists every file owned by an installed package?
💪 Exercises & Challenges
Filesystem Hierarchy & Package Management MCQ
Test your understanding of Filesystem Hierarchy & Package Management.
Audit Installed Packages
Using only dpkg -l, dpkg -L, and dpkg -S (each run as a single command — no chaining), answer: (1) roughly how many packages are installed on a typical Debian-based server, (2) which package owns /bin
Find It Without Root
You have read-only access to an unfamiliar server and need to answer three questions in under 60 seconds using nothing but FHS knowledge: 1. Where would you look first for an application's configurat