Concepts·LPIC-2

The lab: one disk, and a client that proves things

Two practical facts every later page depends on. This host has one disk, so the RAID and LVM topics run on loop devices rather than a disk shelf nobody has - and none of the services on the syllabus is installed yet, which is the starting point each guide builds from.

Start Here Guide 3 of 29 Intermediate

PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
Block devicesone 50 GB disk
TimeAbout 13 min

Two service hosts and a client. Every service here is proven from a machine that is not running it.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
LPIC2-A01	192.168.0.78	Ubuntu 26.04 LTS	Primary service host - BIND, Apache, Samba, Postfix. Topic 204 RAID runs on loop devices; this machine has no spare disk	2 Core	4 GB	50 GB
LPIC2-B01	192.168.0.79	AlmaLinux 10.2	Second service host - nginx, NFS, DNS secondary, and the other family's spelling of each service	2 Core	4 GB	50 GB
LPIC2-C01	192.168.0.80	Ubuntu 26.04 LTS	Client - resolves, mounts and connects, so every service is proven from a machine that is not running it	2 Core	4 GB	50 GB

This guide includes

Use this before the storage and service guides. This matters because there is one disk - so every storage page runs on loop devices, and nothing is installed until you install it.

checking what block devices exist before planning any storage work
finding why the storage guides run on loop devices
seeing the starting state, a machine with nothing installed on purpose

Before you start

what-lpic-2-asks

One disk, so storage runs on loop devices
Check what block devices exist before planning topic 204 around them.
bash Example session
```
$lsblk -dno NAME,SIZE,TYPE | grep disk; echo "--- one disk, no spares"fd0    4K disksda   50G disk--- one disk, no spares$sudo losetup -f; echo "--- so RAID and LVM are taught on loop devices, which a reader can also do"/dev/loop0--- so RAID and LVM are taught on loop devices, which a reader can also do
```
Note
Topic 204 was meant to have spare raw disks. This machine has none, so mdadm RAID, LVM and the filesystem work run on loop devices backed by files - the same approach the LFCS storage track takes.

And that is the better lesson anyway. A reader following along has no spare disk either, so everything in this track is reproducible on a laptop. Every tool involved - mdadm, LVM, mkfs, blkid - treats a loop device as a real block device and cannot tell the difference.

Where it does differ is worth stating. A loop device cannot reproduce a real disk's read error or its performance characteristics. What it reproduces exactly is the state machine - array assembly, failure, spare promotion, rebuild - which is what the objective examines.

losetup -f reports the first FREE device without allocating it, which is how a script picks one safely. losetup -a lists what is already attached, and a machine carrying leftover loop devices from an abandoned experiment is a common source of confusion.

Expected resultOne 50 GB sda and the floppy node, no spare disks - and /dev/loop0 free for the storage work.

Success conditionYou know what topic 204 will actually be demonstrated on.
Nothing is installed yet, on purpose
The starting state is a machine with no services on it.
bash Example session
```
$for s in named httpd nginx smbd nfs-kernel-server postfix; do printf '%-22s %s\n' "$s" "$(command -v $s >/dev/null && echo installed || echo 'not installed')"; donenamed                  not installedhttpd                  not installednginx                  not installedsmbd                   not installednfs-kernel-server      not installedpostfix                not installed
```
Note
An empty machine is the honest starting point. A lab with everything pre-installed hides half of each objective - the half about installing, enabling and confirming the thing is actually running, which is where the marks are.

201 rewards reading; 202 rewards having configured it. Kernel, storage and capacity planning can be studied from a book. DNS, Apache, Samba, NFS and Postfix cannot. That asymmetry is worth more than any topic weight when you plan your time.

So the pages are ordered and say so. A guide needing a resolver declares the DNS guide as a prerequisite rather than failing halfway down, and every page that installs something removes it again - so the machine you meet on page eleven is the one described here.

command -v is the right check, not ls /usr/sbin. It answers the real question - is this runnable - and its exit status is what a script should test.

Expected resultAll six - named, httpd, nginx, smbd, nfs-kernel-server, postfix - report not installed.

Success conditionYou know the lab starts empty, and every service page installs what it needs.

Troubleshooting

A storage exercise needs a spare disk and the machine has none.

Why: This lab has one 50 GB disk with everything on it, which is the normal state of a real server.

Fix:Use a loop device: truncate -s 512M /var/tmp/disk.img then losetup -fP --show <file>. To the kernel it is a block device - it partitions, takes a filesystem, mounts and appears in fstab exactly like a disk.
A guide's commands fail because the service is not installed.

Why: The lab starts with nothing installed on purpose - named, httpd, nginx, smbd, nfs-kernel-server and postfix are all absent.

Fix:Install what a page needs at the start and remove it at the end. Check with command -v or dpkg -l rather than assuming a previous exercise left it behind.
A service is proved to work by testing it on the server itself.

Why: Testing from the machine that runs it exercises loopback and nothing else - not the interface, not the firewall, not the route.

Fix:Always test from the client host. That is why this lab has three machines: two that run services and one that consumes them.

Official sources

← All LPIC-2 guides