Red Hat Certified System Administrator (RHCSA) #5: Local Storage 1 — Partitions, swap, LVM basics

11 min read

#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 -f

In 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/vdb

In 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/vdb

The 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 exit

Specify 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 print

Telling 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/vdb

Now 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 -h

Up 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/vdb1

Add the UUID that blkid reports to /etc/fstab as a single line.

UUID=put-the-actual-UUID-here   none   swap   defaults   0 0
Fieldswap entry valueMeaning
DeviceUUID=...swap area (specifying by UUID recommended)
Mount pointnoneswap has no mount point
Typeswapstates it’s a swap area
Optionsdefaultsdefault options
dump0not a dump target
fsck0not 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 --show

The 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.

LayerAbbr.DescriptionCreate command
Physical VolumePVthe physical unit LVM uses (partition/disk)pvcreate
Volume GroupVGa storage pool bundling PVsvgcreate
Logical VolumeLVthe actual volume carved out of a VGlvcreate

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/vdb2

Creating 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 vgdata

When 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/lvweb

The 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/lvweb

The -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/lvweb

Create 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/web

This 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/lvweb

Add the following single line to /etc/fstab.

UUID=put-the-actual-UUID-here   /mnt/web   xfs   defaults   0 0
FieldMount entry valueMeaning
DeviceUUID=...the device to mount (specified by UUID)
Mount point/mnt/webthe directory to mount on
Typexfsthe file system type
Optionsdefaultsdefault mount options
dump0not a dump target
fsck0XFS 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 -f

If 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/web

Once 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 with q throws changes away. After changes, notify the kernel with partprobe.
  • swap is mkswap → swapon → fstab. You must register it in fstab as none swap defaults 0 0 for 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 -a verification as one package.
  • UUID instead of the device name. Get the UUID with blkid and 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 with fdisk -l
  • Creating partitions. fdisk (interactive) or parted (one line); types are swap 82, LVM 8e; after changes, partprobe
  • swap. Make it permanent with mkswapswapon → fstab (none swap defaults 0 0)
  • LVM. pvcreatevgcreatelvcreate; extension is lvextend -r (details in #6)
  • File system and mounting. mkfs.xfsmount → fstab (UUID) → mount -a verification
  • 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.

X