/lib
shared libraries and kernel modules→ usr/lib/lib holds code that programs share. A library is a file of ready-made functions that many programs load instead of each carrying its own copy. Almost every command depends on at least one, and the kernel’s drivers are kept here too, as modules.
Programs are in /bin. What they need in order to run is here.
Why it exists
Every directory at the top of the tree is there for a reason. This is the problem /lib solves.
The C library is used by nearly every program on the system. Keeping one shared copy saves disk and memory, and a security fix to it reaches every program at once.
Kernel modules — drivers for network cards, filesystems and more — sit under /lib/modules and are loaded only when the hardware is present.
What you find inside
Not everything, but the entries worth recognising. Each is marked as a directory, a file, a link or a device.
- x86_64-linux-gnudirectoryThe shared libraries for this CPU type, on Debian-family systems.
- libc.so.6fileThe C library — the one almost everything depends on.
- modulesdirectoryKernel modules, in one directory per kernel version.
- firmwaredirectoryFirmware files that drivers load into hardware.
- systemddirectorysystemd’s own programs and the unit files shipped by packages.
At the terminal
Four commands that show what this directory is doing on a real machine.
ldd /bin/lsList the libraries a program needs, and where each was found.
ls /lib/modulesList the kernel versions that have modules installed.
lsmodList the kernel modules loaded right now.
uname -rPrint the running kernel’s version — the name of its modules directory.
Handle with care
What goes wrong here, and what someone securing or attacking the machine looks at.
Deleting or replacing a file here can break every program that uses it — including the shell and the package manager needed to fix it.
A malicious library loaded into every process sees everything those processes do. /etc/ld.so.preload should normally not exist; if it does, find out why.