Concepts·LPIC-1

LPIC-1 exam format and topic weights

LPIC-1 is two separate exams, 101-500 and 102-500, both required and each scored on its own. It is also the only certification on this site whose objectives name both dpkg and rpm, which is why every page here uses two machines. This guide covers the exam structure, then shows how a script - or a candidate under time pressure - works out which package family a machine belongs to before touching anything.

Start Here Guide 1 of 33 Beginner

PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
TimeAbout 14 min

Exam structure and topic weights are LPI's published objectives for 101-500 and 102-500, linked below. Nothing on this page is derived from this site's practice questions - a question bank is edited, and a guide that quotes one goes quietly out of date.

RPM packagingrpm 4.19.1.1, dnf 4.20.0

Both package families, because LPI names dpkg and rpm in the objectives themselves. Every output is captured on the host it belongs to.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
LPIC1-A01	192.168.0.76	Ubuntu 26.04 LTS	Debian-family host - dpkg and apt, which objective 102.4 names	2 Core	4 GB	50 GB
LPIC1-B01	192.168.0.77	AlmaLinux 10.2	RPM-family host - rpm and dnf, which objective 102.5 names	2 Core	4 GB	50 GB

This guide includes

Use this before booking either paper. This matters because LPIC-1 is two separate exams and both are required - and the login shell on these hosts is not bash, which a scripting paper punishes.

meeting the two machines, and what each says about itself
reading the file a script actually parses, rather than the human-facing tool
asking which family you are on the way a portable script asks
checking what $SHELL really is, before trusting anything to it

Before you start

The two machines, and what each says about itself
hostnamectl answers four questions at once.
bash Example session
```
$hostnamectl | grep -E 'Operating System|Kernel|Architecture|Virtualization'   Virtualization: microsoft Operating System: Ubuntu 26.04 LTS           Kernel: Linux 7.0.0-30-generic     Architecture: x86-64$hostnamectl | grep -E 'Operating System|Kernel|Architecture|Virtualization'      Virtualization: microsoft    Operating System: AlmaLinux 10.2 (Lavender Lion)              Kernel: Linux 6.12.0-211.7.3.el10_2.x86_64        Architecture: x86-64
```
Note
One command, four facts, and it is on every systemd machine. Distribution, kernel, architecture and virtualization. Under exam pressure that beats remembering which of uname, lsb_release and /etc/os-release gives you which piece.

Virtualization: microsoft is a real answer, not noise. It tells you the machine is a guest, which matters the moment a task involves a disk that is not there or a network interface with an unexpected name. On bare metal the field is simply absent.

LPI is the only vendor of the four this site covers that names dpkg AND rpm in its own objectives - 102.4 and 102.5, separately, both examinable. So two machines is not a teaching preference. Showing one family and asserting the other would skip an examined objective, and the two genuinely differ in package names, output shapes and file locations.

The hostnames are provisioning artefacts. A guide saying "the Debian-family host" means the first of these; the OS column is what matters. AlmaLinux stands in for the whole RPM family and everything shown behaves identically on Rocky and RHEL - where it would not, the guide says so.

Expected resultUbuntu 26.04 LTS on kernel 7.0.0-30-generic and AlmaLinux 10.2 on 6.12.0-211.7.3.el10_2 - both x86-64, both reporting the hypervisor they run under.

Success conditionYou can identify an unfamiliar machine in one command.
The file a script actually reads
hostnamectl is for humans. /etc/os-release is for programs.
bash Example session
```
$cat /etc/os-release | grep -E '^(ID|ID_LIKE|VERSION_ID|PRETTY_NAME)='PRETTY_NAME="Ubuntu 26.04 LTS"VERSION_ID="26.04"ID=ubuntuID_LIKE=debian$cat /etc/os-release | grep -E '^(ID|ID_LIKE|VERSION_ID|PRETTY_NAME)='ID="almalinux"ID_LIKE="rhel centos fedora"VERSION_ID="10.2"PRETTY_NAME="AlmaLinux 10.2 (Lavender Lion)"$ls /etc/*-release; echo "--- the RPM family keeps a second, older file"/etc/almalinux-release/etc/os-release/etc/redhat-release/etc/system-release--- the RPM family keeps a second, older file
```
Note
ID_LIKE is the field that makes a script portable. AlmaLinux answers almalinux to ID, which no hand-written list of distributions will contain next year. ID_LIKE="rhel centos fedora" says "treat me as one of these", and testing it is how you support Rocky and Oracle without naming them.

Quoting is inconsistent between distributions and it will bite you. Ubuntu writes ID=ubuntu, AlmaLinux writes ID="almalinux". The file is designed to be sourced by the shell - . /etc/os-release - which strips the quotes for you. Parsing it with grep | cut does not, and that is where the stray quote in a comparison comes from.

/etc/redhat-release predates all of this and is still shipped for compatibility. It is one unstructured line meant for people, and scripts that grep it break every time the wording changes. Know it exists, because questions reference it; use os-release for anything you write.

lsb_release -a is the other answer, and is frequently NOT installed by default - which makes it a poor first choice on a machine you have just met.

Expected resultID=ubuntu on one; ID="almalinux" with ID_LIKE="rhel centos fedora" on the other - and the RPM host carrying a second, older redhat-release file.

Success conditionYou know which file to test in a portable script.
Which family am I on, the way a portable script asks
Do not parse a name. Test for the tool.
bash Example session
```
$if command -v apt-get >/dev/null; then echo "debian family"; elif command -v dnf >/dev/null; then echo "rpm family"; fidebian family$if command -v apt-get >/dev/null; then echo "debian family"; elif command -v dnf >/dev/null; then echo "rpm family"; firpm family
```
Note
This is the shape the exam wants, and the shape that survives contact with reality. It asks a question with exactly one right answer - is the Debian toolchain present? - rather than comparing a distribution name against a list that goes stale.

command -v rather than which. command -v is a POSIX shell builtin, always available, and reports what the shell will actually run. which is a separate program that may not be installed, behaves differently across distributions, and does not know about builtins or functions. The next guide shows them disagreeing on this very machine.

>/dev/null because you want the exit status, not the output. The whole test is whether the command succeeded. This is the single most common idiom in Topic 105 scripting questions, and writing it without the redirect leaves stray output in the middle of your script.

Order the branches carefully. A machine can have both - apt installed on an RPM host, for instance - so test for the one you expect to be authoritative first, or test for the file /etc/debian_version instead, which is present only on the Debian family.

Expected resultdebian family from one host and rpm family from the other, from the same line of shell.

Success conditionYou can branch on package family without maintaining a list of distributions.
The login shell, which a scripting paper punishes
Check what $SHELL actually is before trusting any $BASH_VERSION example.
zsh Example session
```
$echo "SHELL=$SHELL"; echo "BASH_VERSION=${BASH_VERSION:-(empty - this is not bash)}"; bash -c 'echo "under bash -c: $BASH_VERSION"'SHELL=/usr/bin/zshBASH_VERSION=(empty - this is not bash)under bash -c: 5.3.9(1)-release
```
Note
These hosts log in to zsh, and that is not unusual any more. $BASH_VERSION is empty, a .bashrc you edit is never read, and a bash-only construct typed at the prompt fails for a reason that has nothing to do with the topic you were studying. Hours get lost to this.

Topic 105 is Shells and Scripting, and the shebang decides. A script beginning #!/bin/bash runs under bash whatever your login shell is - which is why the third command prints a version where the second prints nothing. Guides on this path that depend on the difference run bash -c explicitly and say so.

$SHELL is your LOGIN shell, not the shell you are in. It comes from /etc/passwd and does not change when you start a different shell. To find what is actually running: ps -p $$ -o comm=. The exam distinguishes these, and so should you.

Which means echo $SHELL is worth ten seconds on any machine you did not build - before you write a script for it, and certainly before you blame the script.

Expected resultSHELL=/usr/bin/zsh, an empty BASH_VERSION, and 5.3.9(1)-release once the same question is asked under bash -c.

Success conditionYou will not be caught by a shell that is not the one you assumed.

Troubleshooting

A script works when pasted into the terminal and fails when run as a file.

Why: The login shell on these hosts is zsh, and the script's shebang decides the interpreter. Syntax that zsh accepts interactively can be invalid to whatever the shebang names.

Fix:Put #!/bin/bash at the top and make the file executable. Confirm what you are typing into with echo $SHELL and what the script runs under with ps -p $$.
echo $BASH_VERSION prints nothing, so bash looks absent.

Why: The variable is only set by bash itself. An empty value means the current shell is not bash - not that bash is missing.

Fix:bash --version reports the installed version regardless of the login shell. On these hosts it is 5.3.9 while $SHELL is /usr/bin/zsh.
A portable script takes the wrong branch on AlmaLinux, Rocky or CentOS.

Why: It matches on ID alone, which is distribution-specific, rather than on ID_LIKE.

Fix:Source /etc/os-release and test ID_LIKE as well - AlmaLinux reports ID_LIKE="rhel centos fedora". Never parse hostnamectl, which is formatted for humans.
Preparation feels endless because both papers are being revised at once.

Why: 101-500 and 102-500 are separate exams, booked and scored independently, and each has its own topic list.

Fix:Prepare and sit one at a time. Failing one does not affect the other, and the certificate arrives when both are passed.

Official sources

← All LPIC-1 guides

LPIC-1 exam format and topic weights

This guide includes

Before you start

The two machines, and what each says about itself

The file a script actually reads

Which family am I on, the way a portable script asks

The login shell, which a scripting paper punishes

Troubleshooting

Official sources