Configure local storage practice questions

vgextend vgdata /dev/sdb, pvcreate /dev/sdb, lvextend

Why wrong: Running vgextend before pvcreate fails because LVM cannot add a device that lacks a valid physical volume label to a volume group. pvcreate writes the indispensable metadata header that identifies /dev/sdb as an LVM PV; without it, vgextend reports the device as not found or not a physical volume. The correct sequence is to initialize the disk first, then join it to the volume group, and only then extend any LV.

pvcreate /dev/sdb, lvextend, vgextend vgdata /dev/sdb

Why wrong: After pvcreate, /dev/sdb is a physical volume but it has not yet been added to vgdata, so the volume group has no new free extents available. An lvextend attempt at this point will fail because the LV's volume group cannot allocate from a PV that is not a member. The vgextend must occur before lvextend to make that free space visible to the logical volume being expanded.

lvextend, vgextend vgdata /dev/sdb, pvcreate /dev/sdb

Why wrong: Because lvextend is executed first, it looks for free extents in vgdata before any new disk has been prepared or added, so it cannot find space and aborts. vgextend after that would add /dev/sdb to the VG, but the LV extension already failed, and pvcreate last would merely initialize the disk after the operations that needed it had run. This order violates every dependency in the LVM workflow and cannot succeed.

mdadm --add /dev/md0 /dev/sdc

Why wrong: The `--add` option alone does not reduce the existing mirror: it merely attaches /dev/sdc to /dev/md0 as a spare. Since /dev/sdb is still active and healthy, the RAID1 remains in a two-disk configuration, and the new disk will not participate in a rebuild. The old disk must first be explicitly marked as failed and removed so that the array enters a degraded state, allowing `--add` to trigger a recovery onto /dev/sdc.

mdadm --remove /dev/md0 /dev/sdb --add /dev/sdc

Why wrong: Without a preceding `--fail`, the `--remove` command is invalid: mdadm will reject the removal of a fully functional component because that would compromise the mirror's redundancy. Even if `--add` is appended, the kernel's md driver treats the operation as adding a spare rather than rebuilding a replacement. The sequence must start with `--fail` to update the array's state, and the whole compound command should use `--manage` to invoke the proper management interface.

mdadm --replace /dev/md0 --with /dev/sdc

Why wrong: There is no `--replace` operation in the standard mdadm CLI: the tool does not provide a direct 'replace' subcommand or flag. To swap a disk, you must issue a sequence of state changes via `--manage`, specifically `--fail`, then `--remove`, then `--add`. Relying on a nonexistent `--replace` option will simply cause mdadm to exit with an error and leave the array unchanged, so this command is not a valid replacement method.

To create a filesystem label

Why wrong: Creating a filesystem label is a separate filesystem metadata operation, typically performed with e2label or tune2fs for ext2/3/4, and it sets a human-readable volume name. It does not alter the kernel's partition table state, nor does it make a newly created partition visible to the system. partprobe, in contrast, works at the partition-table level, not the filesystem layer, so this option confuses two distinct administrative tasks.

To repair a damaged partition table

Why wrong: Repairing a damaged partition table is a disk-rescue procedure that involves interactive utilities like fdisk, gdisk, or testdisk, which rewrite the partition entries on the storage device. partprobe cannot repair anything; it only instructs the kernel to re-read the partition table after changes have already been made by another tool. While a re-read is sometimes necessary after a repair, the command itself does not perform repair, making this option incorrect.

To format the partition with a filesystem

Why wrong: Formatting a partition with a filesystem is accomplished by mkfs (or filesystem-specific variants like mkfs.xfs, mkfs.ext4), which writes the superblock, inode tables, and other filesystem structures onto the partition. partprobe does not create or modify any filesystem; it simply updates the kernel's in-memory representation of the partition layout. Attempting to use partprobe for formatting would leave the partition unformatted, so this option is clearly wrong.

lvextend, then resize2fs

Why wrong: resize2fs is an ext2/3/4 specific tool; it reads and writes ext-family metadata and will refuse to touch an XFS filesystem. Although the order—extend the LV first, then resize the filesystem—would be correct for an ext filesystem, using resize2fs on XFS fails because XFS has a completely different on-disk structure. The correct XFS equivalent is xfs_growfs, not resize2fs.

xfs_growfs, then lvextend

Why wrong: This sequence is invalid because when xfs_growfs runs, the logical volume has not yet been extended, so the XFS filesystem sees only its original capacity and cannot acquire any new blocks. If xfs_growfs executes before lvextend, it either no-ops (the filesystem already matches the device size) or, at best, expands to the old device ceiling; the later lvextend adds space to the LV but leaves the filesystem unaware of it. The kernel only reports the block device's current size to xfs_growfs, so the LV must be extended first.

resize2fs, then lvextend

Why wrong: This option is wrong twice over: resize2fs is the wrong tool for XFS (it only handles ext2/3/4 filesystems), and the filesystem resize is attempted before the LV is extended, so there is no surplus space to grow into. Running resize2fs first would fail because the device has no free space beyond the current filesystem, and even a subsequent lvextend cannot repair that failed resize. The correct order and tool are lvextend followed by xfs_growfs.

lvcreate -n vgdata -L 2G lvdata

Why wrong: This command fails because the argument after -n becomes the logical volume name, so it would name the LV 'vgdata', while 'lvdata' is treated as the volume group name. Since no volume group named lvdata exists, lvcreate errors out; conversely, the intended VG 'vgdata' is never specified. The correct order is -n lvdata ... vgdata.

lvcreate -n lvdata -s 2G vgdata

Why wrong: Using -s indicates a snapshot creation, not a regular logical volume, and it requires that the following argument (after -L or -l is specified) be an existing logical volume to snapshot. Here -s 2G is syntactically invalid because -s does not take a size; snapshot size must be supplied via -L. Also the final argument vgdata is a volume group, not a source logical volume, so the snapshot source is missing.

lvcreate -l 2G -n lvdata vgdata

Why wrong: The -l option specifies logical extents or a percentage of space (e.g., -l 100%FREE), not a raw size like 2G. Passing -l 2G is invalid because the value for -l expects a number of extents or a percent expression, and the unit 'G' is only accepted by -L. To create a 2G logical volume, -L 2G is required.

mkfs.swap /dev/sdb1

Why wrong: mkfs.swap /dev/sdb1 is invalid because no such command exists in the util-linux or e2fsprogs suites. The mkswap utility is specifically designed for creating swap areas, while mkfs tools (like mkfs.ext4 or mkfs.xfs) target regular filesystems. Attempting to run this would simply fail with 'command not found'.

swapon /dev/sdb1

Why wrong: swapon /dev/sdb1 is wrong for this task because it only activates an existing swap device—it does not create the swap area. If the partition hasn't been initialized with mkswap, swapon will fail with an error indicating that the device is not a swap space. You must first run mkswap to initialize, then swapon to enable it.

swapoff /dev/sdb1

Why wrong: swapoff /dev/sdb1 is the opposite of what you need because it deactivates an active swap device, removing it from the kernel's swap pool. It does not set up or initialize a new swap partition, and it would either error out if the device isn't currently enabled or simply disable it if it was somehow not yet initialized. This command is used when you want to discontinue using a swap area, not to create one.

df -h

Why wrong: df -h is filesystem-centric: it reads mounted filesystem statistics to report capacity and usage of the underlying block device, but it does not query LVM metadata. An inactive logical volume, or an LV not formatted with a filesystem, will not be shown at all, and even for mounted LVs, the size displayed is the filesystem size, not necessarily the LV size. Therefore it cannot reliably show the current size of a logical volume.

lsblk

Why wrong: lsblk displays the block device tree, including device-mapper names like /dev/mapper/vg-name-lvname and their sizes, but it does so from the kernel's view of block devices, not from LVM's own metadata. It lacks LVM-specific attributes such as LV state, mirror/RAID status, stripes, or the ability to list an inactive LV that has not been activated. Thus it falls short of being a command that directly and fully views logical volume size and attributes.

vgdisplay

Why wrong: vgdisplay is aimed at the volume group layer: it reports total and free physical extent counts, VG size, and the number of LVs and PVs, but it does not break down individual logical volume sizes. You would need to run lvdisplay or lvs to inspect a specific LV's size and properties. Therefore vgdisplay is the wrong tool for viewing the current size of an LV.

Setting the partition's UUID

Why wrong: Setting the partition's UUID is not a valid action during partition creation because UUIDs are metadata generated by filesystem utilities such as mkfs or tune2fs, not by partition table tools like parted. On MBR disks, partitions have no UUID concept at all; even on GPT disks, the partition unique GUID is automatically assigned and not typically user-specified at creation time. Moreover, most Linux UUIDs (for mounting via fstab) refer to the filesystem UUID, which exists only after formatting, not partitioning.

Mounting the partition to a directory

Why wrong: Mounting the partition to a directory is not a partition creation step because mounting requires an existing block device with a valid filesystem on it. Partition tools like parted only define the partition table entries and disk layout; they do not and cannot mount devices. The correct workflow is to create the partition, format it with mkfs to create a filesystem, and then mount it separately using mount(8) or an /etc/fstab entry.

mount /dev/sdb1 /mnt

Why wrong: mount associates an existing filesystem with a mount point in the directory hierarchy; it never creates or formats a filesystem. The device must already contain a valid filesystem, otherwise mount returns an error like 'wrong fs type, bad option, bad superblock'. Therefore, while this command is useful after formatting, it cannot initialize a filesystem on /dev/sdb1.

parted /dev/sdb

Why wrong: parted is an interactive or scriptable partitioning tool that creates, deletes, resizes, and checks partitions on a whole disk, manipulating the partition table only. It does not write any filesystem metadata to the partition; after running parted, a separate mkfs step is still required. Also note the argument is the whole disk (/dev/sdb), not the partition, reinforcing its role as a partition-table editor.

fdisk /dev/sdb

Why wrong: fdisk is a classic partitioning utility that edits the MBR or GPT partition table on the whole disk, allowing you to create and delete partitions. It does not create filesystems at all; fdisk only defines the partition boundaries and types. Running it on /dev/sdb would change partition layout, but the filesystem on any partition remains untouched, so it cannot initialize a filesystem.

pvcreate /dev/sdc; vgcreate vgdata /dev/sdc; lvcreate -L 5G -n lvdata vgdata; mkfs.ext4 /dev/vgdata/lvdata; echo '/dev/vgdata/lvdata /mnt/data ext4 defaults 0 0' >> /etc/fstab

Why wrong: The pvcreate and vgcreate commands are unnecessary and incorrect because vgdata is already present in the system. Running vgcreate vgdata /dev/sdc will fail with a 'volume group already exists' error, and pvcreate on /dev/sdc reinitializes a physical volume that may already be part of vgdata, potentially destroying existing PV metadata or causing LVM to lose track of the VG. Even if those commands succeeded, recreating the volume group is not the requested task; you should simply create the new LV inside the existing vgdata and then format and mount it. The later steps in the option are valid, but the erroneous initial commands prevent the whole sequence from working.

mkfs.ext4 /dev/sdc; lvcreate -L 5G -n lvdata vgdata; mount /dev/vgdata/lvdata /mnt/data; echo '/dev/vgdata/lvdata /mnt/data ext4 defaults 0 0' >> /etc/fstab

Why wrong: The fatal flaw here is running mkfs.ext4 directly on /dev/sdc, the raw physical volume, instead of on the logical volume device. This would format the entire disk as ext4 and overwrite the LVM physical volume metadata, making /dev/sdc unrecognizable to LVM; consequently, the subsequent lvcreate vgdata command would fail because vgdata would no longer have a valid PV backing it. Even if the lvcreate somehow succeeded, the mount command would attempt to mount an LV that was never formatted with a filesystem, and the fstab entry pointing to /dev/vgdata/lvdata would never be valid. The correct order must be LV creation first, then mkfs on the LV, then mounting and adding to fstab.

mdadm --manage /dev/md0 --fail /dev/sdb --remove /dev/sdc

Why wrong: The command uses valid mdadm actions, but it removes /dev/sdc after failing /dev/sdb. That removes the wrong device from /dev/md0 while leaving the failed /dev/sdb still present in the array. If /dev/sdc is healthy and still online, mdadm will refuse to remove it until it has been failed or may remove an active device, risking data loss on that device. The --remove action must always target the exact device that was just marked failed.

mdadm --fail /dev/md0 /dev/sdb; mdadm --remove /dev/md0 /dev/sda

Why wrong: This two-command sequence correctly fails /dev/sdb with the --fail action, but the subsequent --remove command references /dev/sda instead of /dev/sdb. Since /dev/sda was never failed, mdadm will not remove it from the array, and the failed /dev/sdb remains as a faulty spare or active disk. The proper remove step must use the same component device name that was failed, i.e. /dev/sdb, not a different disk.

mdadm --manage /dev/md0 --fault /dev/sdb --remove /dev/sdb

Why wrong: The --fault option is not a valid mdadm action or flag; mdadm expects --fail (or -f) to mark a device as faulty. Because --fault is unrecognized, mdadm aborts with an error and neither fails nor removes /dev/sdb. Even though --manage is a valid prefix, the invalid option prevents the entire command from executing, so this attempt does nothing to the array.

Add /dev/sdb as a physical volume, extend the root volume group, extend the root logical volume, and grow the filesystem. Then move /var/lib/mysql to a new directory on the extended space.

Why wrong: Extending the root volume group and logical volume simply adds free space to the existing root filesystem; it does not create a dedicated mount point for /var/lib/mysql, so database growth can still fill the root volume and affect the entire OS. Moving the database directory to a new folder on the same expanded filesystem provides no isolation, no snapshot capability for MySQL specifically, and does not take advantage of a separate LVM volume that could be managed independently. This approach also fails to address the need to keep the database online during the data migration, as moving directories while MySQL is running can produce an inconsistent copy.

Use lvreduce to shrink the root LV by 10GB, then lvextend to create a new LV for /var/lib/mysql, format with ext4, mount, and copy data.

Why wrong: Shrinking a filesystem with lvreduce is inherently risky and requires the filesystem itself to be reduced before the LV is shrunk; because the root filesystem is typically XFS in RHEL, and XFS cannot be shrunk at all, this command would fail before any space is freed. Additionally, you do not create a new logical volume with lvextend — lvextend grows an existing LV, while the correct command to create one is lvcreate. Using ext4 instead of XFS and shrinking a live root filesystem would also require significant downtime, and the procedure as described never safely copies /var/lib/mysql while the database is running.

Partition /dev/sdb with a single partition, format with ext4, mount at /var/lib/mysql, and copy the data. Then update /etc/fstab.

Why wrong: Partitioning /dev/sdb and formatting it with ext4 yields a plain block device that cannot be resized or managed with LVM snapshots, making it far less flexible than a logical volume and harder to adapt as database storage grows. Mounting the raw partition directly at /var/lib/mysql and then copying data while the database is running risks a corrupted or inconsistent dataset, because the copy is not coordinated with MySQL's flush and the service is not briefly stopped. The option also lacks the temporary /mnt step, so there is no safe window to finalize the switch; an ext4 filesystem on a raw partition works but is not the LVM-based solution expected of an RHEL administrator.

The 'pvs' command can repair corrupted metadata.

Why wrong: The pvs command is exclusively a reporting tool that presents a formatted summary of physical volume attributes by reading existing LVM metadata. It has no write, repair, or rewrite capability, so it cannot fix corrupted metadata. Repair operations require dedicated LVM utilities such as pvck for checking and pvcreate/pvchange for reinitializing or adjusting metadata.

The 'fsck' tool is used to verify LVM metadata.

Why wrong: The fsck utility is a filesystem consistency checker for filesystems such as ext4 and XFS, which reside on top of logical volumes. It has no knowledge of LVM metadata structures, which live on physical volumes in the volume group descriptor area. Therefore, fsck can never validate or verify LVM metadata; only LVM-specific commands like pvck can interpret those structures.

LVM metadata is stored in /etc/lvm directory.

Why wrong: The /etc/lvm directory holds LVM configuration files such as lvm.conf and runtime settings, but the authoritative volume group metadata is never stored there. Instead, it is written to the VGDA on each physical volume, allowing the devices to carry their own metadata. Treating /etc/lvm as a metadata store confuses configuration with on-disk state; you can safely move PVs to another system and the metadata will be read from the devices.

1. vgcreate, 2. pvcreate, 3. lvcreate, 4. mkfs, 5. mount

Why wrong: This order is invalid because vgcreate itself requires that the underlying devices are already initialized as LVM physical volumes. Running vgcreate first will fail—the commands that add devices to a volume group expect each device to contain an LVM metadata header written by pvcreate. You must run pvcreate on each block device first to label it as a PV, and only then can vgcreate create a VG spanning those PVs.

1. pvcreate, 2. lvcreate, 3. vgcreate, 4. mkfs, 5. mount

Why wrong: This order fails at step 2 because lvcreate requires an existing volume group (VG) to allocate logical extents from; the VG is the pool that logical volumes are carved out of. While pvcreate is correctly placed first, lvcreate must wait until after vgcreate has aggregated the physical volumes into that pool. Running lvcreate before vgcreate produces an error like "Volume group not found" because the VG name has no corresponding LVM metadata yet.

1. pvcreate, 2. vgcreate, 3. mkfs, 4. lvcreate, 5. mount

Why wrong: This order is invalid because mkfs at step 3 tries to format a logical volume that has not been created yet—lvcreate at step 4 is the tool that actually creates the LV block device. Without an existing LV, mkfs has no device node to target and will fail with an error such as "No such file or directory" when specifying the LV path. The correct progression is to allocate the LV first, then build the filesystem on it, so mkfs must come after lvcreate.

First, run swapon /dev/sdc1 to activate the swap. Then, run mkswap /dev/sdc1 to format it. Finally, add an entry to /etc/fstab.

Why wrong: Running swapon before mkswap is invalid because swapon requires an existing valid swap signature on the device; on a fresh partition, there is no signature, so the command fails. Even if a stale signature were present, mkswap executed afterward would overwrite it, rendering the currently active swap area corrupt and unusable. Consequently, after mkswap completes, the swap is never reactivated before the fstab entry is added, meaning it will not be active until the next reboot at best, and at worst the fstab entry points to a device that is not currently enabled.

First, add an entry to /etc/fstab for /dev/sdc1. Then, run mkswap /dev/sdc1. Finally, run swapon /dev/sdc1.

Why wrong: Adding an fstab entry before the partition is formatted as swap is dangerous because systemd reads fstab at boot and attempts to run swapon on /dev/sdc1 before mkswap has created a swap signature. This will cause a swapon failure, potentially delaying boot or dropping the system into emergency mode if swap is marked as required. Although running mkswap and swapon manually afterward can recover the situation, a reboot in the interim will fail to activate the swap, and the fstab entry remains problematic until fixed.

First, run mkswap /dev/sdc1. Then, add an entry to /etc/fstab. Finally, run swapon /dev/sdc1.

Why wrong: This is incorrect because the standard order is to activate swap with swapon before editing fstab. While it can work, it is considered a mistake as it may lead to issues if swapon fails and the fstab entry remains.

service: Manages file system mount points

Why wrong: File system mount points are not managed by service units; they are the responsibility of mount units (.mount), which represent a mount point as defined in /etc/fstab or via systemd.mount. A .mount unit encapsulates the device, filesystem type, mount options, and ordering constraints relative to network or other mounts. Confusing this role with service units conflates process execution with filesystem lifecycle management, which systemd intentionally separates.

timer: Groups units to define synchronization points

Why wrong: This description incorrectly assigns the grouping and synchronization role of target units to timer units. Timer units are entirely scheduling mechanisms: they specify time-based triggers that activate a single associated service, and they have no mechanism for grouping multiple units or defining synchronization points. The capability to organize units into coordinated states belongs exclusively to target units, whose purpose is to aggregate dependencies and ordering across many units.

minute: 0-23

Why wrong: This option incorrectly assigns the hour field's range to the minute field. The minute field actually permits values from 0 through 59, because there are 60 minutes in an hour, while the range 0–23 applies to the hour field, reflecting the 24 hours in a day. Using a value like 30 in the minute field is valid, but a value of 30 in the hour field would be invalid because 30 exceeds the maximum hour value of 23.

fdisk

Why wrong: fdisk is a partition-manipulation tool that creates, deletes, and resizes MBR or GPT partition entries. It only edits the disk's partition table; it does not write LVM metadata or LVM labels to any partition. Even after you use fdisk to carve out a partition (e.g., /dev/sdb1), that partition remains a raw device until pvcreate is explicitly run against it to initialize it as an LVM physical volume.

vgcreate

Why wrong: vgcreate is a higher-level LVM command that creates a volume group by combining one or more already-initialized physical volumes into a storage pool. It expects device arguments to be existing PVs with valid LVM labels; running vgcreate on a raw partition will fail because the partition lacks PV metadata. Therefore, vgcreate cannot initialize a partition as a physical volume — it only consumes PVs that pvcreate has already prepared.

lvcreate

Why wrong: lvcreate operates at the highest level of the LVM stack: it allocates logical volumes from available extents inside a volume group. A volume group is itself composed of physical volumes, so lvcreate presupposes both pvcreate and vgcreate have already been executed. Because lvcreate merely carves out a logical block device from an existing VG's free space, it has no ability to write PV labels or initialize a partition as a physical volume.

fdisk -l

Why wrong: fdisk -l operates on the partition table of a disk, displaying the layout of partitions (e.g., /dev/sda1) with start/end sectors and partition types. It does not query the filesystem superblock, so it cannot report used or available space on mounted filesystems. Because it works at the disk/partition layer, it is the wrong tool for answering 'how much space is left?'—that requires a filesystem-level utility.

du -sh

Why wrong: The du command summarizes file and directory space usage, not filesystem capacity. When invoked as du -sh /var, it walks the directory tree and totals the sizes of all files, reporting the aggregated space consumed by that specific path in human-readable form. It does not know about the total capacity or free space of the underlying filesystem, so it cannot show available space—it only shows how much that subtree occupies.

lsblk

Why wrong: The lsblk command enumerates all block devices (disks, partitions, LVM volumes) in a tree, showing device names, sizes, types, and any mount points. It is primarily a hardware/device layout tool; its size column reflects the raw device size (e.g., 500G for /dev/sda), not the filesystem's used or free space. While it may display mount points, it does not report the amount of disk space used or available for a mounted filesystem, making it unsuitable for this question.

/etc/rc.local

Why wrong: /etc/rc.local is incorrect because it is a local startup script, not a configuration file that lists filesystems. It is executed once during the boot process and may contain arbitrary shell commands, such as mount commands, if an administrator adds them. However, it is not inherently consulted by the kernel or mount utilities for determining which filesystems to mount, and on systemd-based systems it is an optional legacy feature that may not even run unless enabled. Therefore, it does not hold the actual list of filesystems to be mounted.

/etc/filesystems

Why wrong: /etc/filesystems is incorrect because it does not contain mount points or persistent mount entries; instead, it is a plain list of filesystem types (e.g., ext4, xfs, vfat). The mount command references this file when no explicit filesystem type is given, to probe which filesystems are supported by the kernel. It is a discovery/autodetection aid, not a table of what should be mounted where. Consequently, it cannot be the file containing the list of filesystems to be mounted at boot.

/etc/mtab

Why wrong: /etc/mtab is incorrect because it is a runtime record of the filesystems that are currently mounted at any given moment, not a persistent configuration. It is updated dynamically by the kernel and mount operations, and on modern systems it is often a symlink to /proc/self/mounts. Because it reflects transient state—including manually mounted filesystems and temporary mounts—it is not used by the system at boot to determine which filesystems should be mounted. The static boot-time configuration belongs to /etc/fstab, not /etc/mtab.