Red Hat Certified System Administrator (RHCSA) #5: Local Storage 1 — Partitions, swap, LVM basics
#4 Booting and the system covered systemd, GRUB2, and even password recovery. Now we enter local storage — the area with the most tasks on RHCSA, and the one that decides whether you pass. This is the first post on it: we take a single empty disk, create partitions, add swap, build LVM, and mount a file system permanently — running the whole flow by hand from start to finish.
The crux of storage work is whether it survives a reboot. If you run mkswap but don’t write it into fstab, swap vanishes after a reboot; if you mount but don’t write it into fstab, the mount comes undone. So this post covers not just the commands that create things but also the process of making them permanent in fstab, as a single package.
Check the disks first #
Before any work, look first at which disks the system has and where the free space is. Touching the wrong disk is hard to recover from, so we won’t skip the verification step.
lsblk shows block devices as a tree, which is the best way to grasp the whole picture.
# Block device tree. See disks, partitions, and mount points at a glance
lsblk
# Show the file system type and UUID as well
lsblk -fIn the output, the disk type is the whole disk, and the indented part beneath it is a partition. An empty MOUNTPOINT means it isn’t mounted yet.
fdisk -l shows disk sizes and the partition table format (MBR/GPT) in detail.
# Show the partition tables of all disks in detail
fdisk -l
# Look at a specific disk only
fdisk -l /dev/vdbIn this post we’ll assume the empty additional disk is /dev/vdb. In the real exam you must first check the name of the empty disk in your own environment with lsblk. Depending on the environment, the name differs — /dev/sdb, /dev/nvme0n1, and so on.
Creating a partition #
Let’s split a partition on the empty disk by hand. The tools are fdisk (interactive) and parted, and on the exam you can use whichever one your hands know better.
Creating with fdisk #
fdisk works through an interactive menu. At each step you enter a one-letter command.
fdisk /dev/vdbThe flow you type inside fdisk is as follows.
Command (m for help): n # create a new partition
Partition type: p # primary (it's the default, so Enter works too)
Partition number (1-4): 1 # number 1
First sector: (Enter) # the start sector is the default
Last sector: +2G # set the size to 2GiB
Command (m for help): t # change the partition type (optional)
Hex code: 82 # 82 = Linux swap, 8e = Linux LVM, 83 = Linux
Command (m for help): p # preview the current partition table
Command (m for help): w # write to disk and exitSpecify the size in the +size form, like +2G, and it grabs that much starting from the start sector. For the type code, change it to 82 for swap or 8e for a partition you’ll use with LVM. The type is just a marker, so it works even without changing it, but it’s better to set it to leave the LVM/swap intent clear.
You must write with w at the end for it to actually take effect. Exiting with q throws the changes away, so be careful.
Creating with parted #
parted lets you give a command on a single line, which is good for scripts. For a large disk (over 2TiB) or when you need GPT, use parted.
# Create a GPT label (for an empty disk)
parted /dev/vdb mklabel gpt
# Create a partition from 1MiB to 2GiB
parted /dev/vdb mkpart primary 1MiB 2GiB
# Check the current state
parted /dev/vdb printTelling the kernel about the partition change #
If the kernel doesn’t recognize the change after you alter the partition table, the following command makes it re-read.
# Notify the kernel of the partition table change
partprobe /dev/vdb
# Check whether the new partition shows up
lsblk /dev/vdbNow a partition device like /dev/vdb1 exists. We’ll put swap or a file system on top of it.
Adding swap #
swap is space that uses the disk as auxiliary memory when physical memory runs short. On RHCSA, “create a swap partition and enable it permanently” is a regular task.
The flow is create partition → mkswap → swapon → register in fstab. We’ll use /dev/vdb1, the partition we made above with type 82 (Linux swap), as swap.
# Format the partition as swap. Note down the UUID from the output
mkswap /dev/vdb1
# Turn swap on right now
swapon /dev/vdb1
# Check the list of currently enabled swap
swapon --show
free -hUp to here it’s temporary. After a reboot the swapon comes undone, so you have to register it in /etc/fstab to make it permanent.
# Check the UUID of the swap partition
blkid /dev/vdb1Add the UUID that blkid reports to /etc/fstab as a single line.
UUID=put-the-actual-UUID-here none swap defaults 0 0| Field | swap entry value | Meaning |
|---|---|---|
| Device | UUID=... | swap area (specifying by UUID recommended) |
| Mount point | none | swap has no mount point |
| Type | swap | states it’s a swap area |
| Options | defaults | default options |
| dump | 0 | not a dump target |
| fsck | 0 | not checked at boot |
After registering, always verify. The following command re-reads fstab and activates swap, and any syntax error in fstab will surface here.
# Enable all swap listed in fstab (for verification)
swapon -a
swapon --showThe device name (/dev/vdb1) can change depending on the order disks are added, so make it a habit to write UUIDs in fstab.
LVM basics #
The most common storage task on RHCSA is create an LVM and mount it. LVM (Logical Volume Manager) is a layered structure for bundling and splitting disks flexibly.
| Layer | Abbr. | Description | Create command |
|---|---|---|---|
| Physical Volume | PV | the physical unit LVM uses (partition/disk) | pvcreate |
| Volume Group | VG | a storage pool bundling PVs | vgcreate |
| Logical Volume | LV | the actual volume carved out of a VG | lvcreate |
The flow is prepare physical device → create PV → create VG → create LV → create file system → mount in fstab. You can use a whole disk as a PV without a partition, but on the exam you usually use a partition made with type 8e (Linux LVM) as the PV. Here we’ll assume /dev/vdb2 as the LVM partition.
Creating a PV #
# Initialize the partition as a PV
pvcreate /dev/vdb2
# Check the PV list and details
pvs
pvdisplay /dev/vdb2Creating a VG #
Bundle PVs to make a VG. The VG name is often specified in the exam question, so we’ll make it exactly as the question requires.
# Create a VG named vgdata and add the PV
vgcreate vgdata /dev/vdb2
# Check the VG list and details (check free capacity, PE count)
vgs
vgdisplay vgdataWhen running vgcreate, you can set the PE (Physical Extent) size with the -s option. If the question asks for something like “extent size 16MiB,” create it with vgcreate -s 16M vgdata /dev/vdb2.
Creating an LV #
Carve the actual volume, the LV, out of the VG. Specify the size with -L as an absolute size (e.g., 2G), or with -l as an extent count or ratio (e.g., 100%FREE).
# Create an LV of size 2GiB named lvweb
lvcreate -L 2G -n lvweb vgdata
# Specify by extent count (50)
lvcreate -l 50 -n lvweb vgdata
# Use all the remaining capacity of the VG
lvcreate -l 100%FREE -n lvweb vgdata
# Check the LV list and details
lvs
lvdisplay /dev/vgdata/lvwebThe LV’s device path is /dev/vgdata/lvweb or /dev/mapper/vgdata-lvweb. In later commands you treat this path like a disk.
A taste of lvextend #
LVM’s biggest advantage is that you can grow the capacity later.
# Add 1GiB to the LV and grow the file system on top of it too
lvextend -L +1G -r /dev/vgdata/lvwebThe -r option grows the file system on top at the same time as it extends the LV. Extension and reduction, plus LUKS encryption, are covered in depth in #6 Local storage 2. Here, just remember that “an LV can be grown later” and move on.
Creating a file system and mounting permanently #
Even after you’ve made an LV, you can’t use it without a file system on top. We’ll finish with the order format (mkfs) → create mount point → register in fstab → verify.
Creating the file system #
RHEL 9’s default file system is XFS. Use XFS when the exam has no special requirement, and ext4 when it asks for ext4.
# Create an XFS file system (RHEL default)
mkfs.xfs /dev/vgdata/lvweb
# If you need ext4
mkfs.ext4 /dev/vgdata/lvwebCreate the mount point and mount temporarily #
# Create the location to mount on
mkdir -p /mnt/web
# Try mounting temporarily
mount /dev/vgdata/lvweb /mnt/web
# Check the mount state and capacity
df -h /mnt/webThis too is temporary. It comes undone after a reboot, so you have to register it in fstab.
Register permanently in fstab by UUID #
For mounting too, writing the UUID rather than the device name is safer. First check the UUID.
# Check the LV's UUID
blkid /dev/vgdata/lvwebAdd the following single line to /etc/fstab.
UUID=put-the-actual-UUID-here /mnt/web xfs defaults 0 0| Field | Mount entry value | Meaning |
|---|---|---|
| Device | UUID=... | the device to mount (specified by UUID) |
| Mount point | /mnt/web | the directory to mount on |
| Type | xfs | the file system type |
| Options | defaults | default mount options |
| dump | 0 | not a dump target |
| fsck | 0 | XFS isn’t checked at boot (0) |
With LVM, the device path (/dev/vgdata/lvweb) is stable, so writing the path is fine too, but RHCSA grading only checks whether the mount survives a reboot, so either UUID or LV path works as long as it’s correct. Here we’ll keep the UUID habit.
Always verify #
Once you’ve edited fstab, you must verify the syntax before rebooting. An error in fstab drops the system into emergency mode at boot and can cost you the exam.
# Unmount the temporary mount first
umount /mnt/web
# Mount everything listed in fstab (verification)
mount -a
# Check that it mounted correctly
df -h /mnt/web
lsblk -fIf mount -a finishes without error and /mnt/web shows up in df, fstab is sound. If time allows, actually checking that the mount survives after a reboot is the surest confirmation.
The whole flow at once #
Collecting RHCSA’s most frequent task — creating an LVM file system on an empty disk and mounting it permanently — line by line gives the following.
# 1) Check the disk
lsblk
# 2) Create the partition (inside fdisk: n, t=8e, w)
fdisk /dev/vdb
partprobe /dev/vdb
# 3) Build LVM
pvcreate /dev/vdb2
vgcreate vgdata /dev/vdb2
lvcreate -L 2G -n lvweb vgdata
# 4) Create the file system
mkfs.xfs /dev/vgdata/lvweb
# 5) Create the mount point and register in fstab (UUID)
mkdir -p /mnt/web
blkid /dev/vgdata/lvweb # check the UUID, then write it into fstab
# 6) Verify
mount -a
df -h /mnt/webOnce these 6 steps stick in your hands, half of the storage area is done.
Exam points #
- Check the empty disk’s name first. Pin down the target disk exactly with
lsblk, and don’t touch the wrong disk (especially the root disk). - fdisk only takes effect when you write with
w. Exiting withqthrows changes away. After changes, notify the kernel withpartprobe. - swap is mkswap → swapon → fstab. You must register it in fstab as
none swap defaults 0 0for it to survive a reboot. - The LVM order is pvcreate → vgcreate → lvcreate. Make VG/LV names exactly as the question requires.
- For sizes,
-L(absolute),-l(extent/ratio). “All the rest” is-l 100%FREE. - Creating isn’t the end — go through mkfs and fstab. Handle format, mount, fstab registration, and
mount -averification as one package. - UUID instead of the device name. Get the UUID with
blkidand write it into fstab, and it stays safe even if the device order changes. - Once you’ve edited fstab, always verify with
mount -a. If there’s an error, the next boot falls into emergency mode.
Wrap-up #
What this post locked in:
- Checking disks. See the whole picture with
lsblk, the partition table withfdisk -l - Creating partitions.
fdisk(interactive) orparted(one line); types are swap82, LVM8e; after changes,partprobe - swap. Make it permanent with
mkswap→swapon→ fstab (none swap defaults 0 0) - LVM.
pvcreate→vgcreate→lvcreate; extension islvextend -r(details in #6) - File system and mounting.
mkfs.xfs→mount→ fstab (UUID) →mount -averification - The trap that decides whether you pass — settings that vanish after a reboot because you created them but didn’t write them in fstab
Storage work is used as-is in RHEL practice too. Pairing it with the broader operations context in the RHEL intermediate track firms up the feel.
Next — Local storage 2 #
In this post we built the fundamentals of creating an LVM and mounting it. Next is the work of growing capacity and protecting data on top of that.
In #6 Local storage 2: LVM extension and LUKS encryption, we’ll add a PV to a VG to grow the pool, extend an LV with lvextend while growing the XFS,ext4 file system together, and build a LUKS-encrypted volume with cryptsetup set to open automatically at boot — all typed out by hand.