LAB(1) Linux Foundations LAB(1)

Lab

Add a second disk and make it stick

Time: 40 minutes | Environment: RHEL 9 VM, with a second virtual disk attached

Before you start

Everything you do here happens on the second disk. You will not touch the disk the system boots from. If a command in this lab ever shows sda where you expected sdb, stop and ask.

Scenario

Your team's application is filling up the server's main disk with log files. Rather than resize anything, you've been given a second disk to mount at /data so the logs live somewhere separate. Your job: make that disk usable, and make sure it comes back automatically after a reboot.

This is one of the most common tasks in the job. It's five steps and every one of them has a verification you can run.

Steps

1. Find the new disk

Before changing anything, look at what's there.

lsblk

You should see something like this — your main disk with partitions under it, and a second disk with nothing under it:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   40G  0 disk
├─sda1   8:1    0    1G  0 part /boot
└─sda2   8:2    0   39G  0 part /
sdb      8:16   0    1G  0 disk

sdb is your target — 1 G, TYPE disk, no partitions, no mount point. Write the name down. Every command below uses it, and using sda by mistake will destroy your system.

Disks are named in the order the kernel finds them: sda, sdb, sdc. On newer hardware you may see nvme0n1 instead. The principle is the same.

2. Create a partition

A bare disk can't hold a filesystem yet — it needs at least one partition. We'll use gdisk, which is interactive: it asks questions, you answer, and nothing is written until you confirm.

sudo gdisk /dev/sdb

At the Command (? for help): prompt, enter these in order:

Type Meaning
n new partition
Enter accept partition number 1
Enter accept the default start sector
Enter accept the default end sector (uses the whole disk)
Enter accept the default type (Linux filesystem)
p print — check it before committing
w write changes to disk
Y confirm

You should see: The operation has completed successfully.

Verify:

lsblk /dev/sdb

There should now be an sdb1 nested under sdb.

If lsblk doesn't show the new partition, run sudo partprobe /dev/sdb to make the kernel re-read the partition table.

3. Put a filesystem on it

The partition exists but has no structure — nowhere to record filenames, sizes, or permissions. mkfs creates that structure. RHEL 9's default is XFS.

sudo mkfs -t xfs /dev/sdb1

You should see: several lines of geometry output ending without any error.

Verify:

lsblk -f /dev/sdb

sdb1 should now show FSTYPE of xfs and a UUID. Copy that UUID somewhere — you'll need it in step 5.

Note the target: /dev/sdb1, the partition, not /dev/sdb, the disk. Formatting the whole disk would wipe the partition table you just made.

4. Mount it, temporarily

A filesystem isn't reachable until it's attached to a directory. That directory is the mount point, and it has to exist first.

sudo mkdir /data
sudo mount /dev/sdb1 /data

You should see: no output at all. On the command line, silence means success.

Verify:

df -h /data

You should see /dev/sdb1 mounted on /data with roughly 1 G available.

Now prove it actually works:

sudo touch /data/testfile
ls -l /data

This mount will not survive a reboot. mount affects the running system only. That's what step 5 fixes.

5. Make it persistent

/etc/fstab lists filesystems to mount at boot. Back it up before editing — this is a habit worth forming, not just a lab step.

sudo cp /etc/fstab /etc/fstab.bak
sudo vim /etc/fstab

Add one line at the end, using the UUID from step 3:

UUID=your-uuid-here  /data  xfs  defaults  0 0

The six fields are: what to mount, where, filesystem type, options, dump flag, fsck order.

Use the UUID, not /dev/sdb1. Device names can change if disks are added or reordered; the UUID belongs to the filesystem and doesn't move.

Verify before you reboot — this is the important part:

sudo umount /data
sudo mount -a
df -h /data

mount -a mounts everything in fstab. If your line has an error, you'll see it now, at a prompt where you can fix it — instead of at next boot, where a bad entry can drop the machine into emergency mode.

Only once mount -a is clean:

sudo reboot

After logging back in:

df -h /data
ls -l /data

/data should be mounted, and testfile should still be there.

Done when

If it doesn't work

Symptom Likely cause Fix
lsblk shows no sdb Disk not attached to the VM Shut down, add the disk in VM settings, boot
New partition missing from lsblk Kernel hasn't re-read the table sudo partprobe /dev/sdb
mkfs says "device is busy" Already mounted sudo umount /dev/sdb1, then retry
mount → "mount point does not exist" Skipped mkdir sudo mkdir /data
mount -a → "can't find UUID" Typo, or wrong UUID copied Re-check lsblk -f; UUIDs are long, copy carefully
System boots to emergency mode Bad fstab line Log in as root, mount -o remount,rw /, fix or restore /etc/fstab.bak, reboot
Everything gone after reboot Formatted sdb instead of sdb1 Restore your snapshot

Going further (optional)

  1. Mount options. Unmount, change defaults to defaults,noexec in fstab, mount -a, then copy a script to /data and try to run it. What happens, and why might a sysadmin want that on a logs partition?

  2. Break it on purpose. You have a snapshot. Change the UUID in fstab to something wrong and reboot. Watch what the system does, then recover using the emergency-mode row in the table above. Recovering from a bad fstab under mild pressure is a genuinely useful thing to have done once, in a room where it doesn't matter.

  3. Look ahead. Run sudo pvs, sudo vgs, sudo lvs. On a default RHEL install these may be empty or show the system volume group. You've just built a fixed-size disk — it can't grow. LVM is the layer that lets storage be resized and span multiple disks, and it's the natural next topic.