Devices, Filesystems and FHS practice questions

mount -a /dev/sdc1 /mnt/usb

Why it fails: The -a option is used for mounting all filesystems in fstab, not a single device.

mount /mnt/usb /dev/sdc1

Why it fails: The order is wrong; it should be device then mount point.

mount -t ext4 /dev/sdc1 /mnt/usb

Why it fails: The -t ext4 is optional as the kernel can auto-detect the filesystem. Although specifying it is not incorrect, Option C is simpler and the most direct correct answer.

pvcreate /dev/sdb1 /dev/sdc1; lvcreate -L 600G -n lvdata vgdata; vgcreate vgdata /dev/sdb1 /dev/sdc1

Why it fails: The sequence places lvcreate before vgcreate, so the logical volume is created against a volume group that does not yet exist. It is tempting because pvcreate correctly runs first, but the scenario's disks are /dev/sda and /dev/sdb, not /dev/sdc, and the ordering of vgcreate and lvcreate is reversed.

pvcreate /dev/sdb /dev/sdc; vgcreate vgdata /dev/sdb /dev/sdc; lvcreate -L 600G -n lvdata vgdata

Why it fails: pvcreate and vgcreate are applied to whole disks /dev/sdb and /dev/sdc rather than partitions, and /dev/sdc does not exist in this scenario. It is tempting because the command order is otherwise correct, but the stem specifies partitions on /dev/sda and /dev/sdb, so the device arguments are wrong.

vgcreate vgdata /dev/sdb1 /dev/sdc1; pvcreate /dev/sdb1 /dev/sdc1; lvcreate -L 600G -n lvdata vgdata

Why it fails: The command order is inverted: vgcreate runs before pvcreate, so the physical volumes do not yet exist and the volume group cannot be created. It is tempting because the disk names and sizes look plausible, but the scenario's disks are /dev/sda and /dev/sdb, not /dev/sdc, so the referenced devices are also wrong.

The root filesystem is corrupted and needs fsck.

Why it fails: Corruption usually leads to 'fsck' errors, not unknown-block.

The root= parameter in the boot loader points to a non-existent device.

Why it fails: Would show 'no such device' or 'unknown device'.

The initrd is missing or corrupted.

Why it fails: Missing initrd causes 'Kernel panic: No init found'.

sync

Why it fails: Valid but not specific to ext4.

ro

Why it fails: Valid but not specific to ext4; the question says 'for ext4', implying typical options.

noload

Why it fails: Not a standard mount option.

The disk /dev/sdb has an extended partition.

Why it fails: The lsblk output shows /dev/sdb's partitions as primary, with no extended partition container listed. Extended partitions exist only within MBR's four-primary limit, occupying one slot to hold logical partitions beyond it. This option would be correct if the output showed a partition of type extended containing logical children.

The root filesystem is mounted from /dev/sda5.

Why it fails: The root filesystem's mountpoint column shows a different device, so /dev/sda5 cannot be its source. This option tempts because /dev/sda5 is a valid partition that could legitimately host a root filesystem on a single-disk layout, making it the right answer when lsblk confirms that mapping.

The disk /dev/sda has a primary partition sda5.

Why it fails: A fifth partition on a disk with an MS-DOS partition table must be logical, residing inside an extended partition; primary partitions are limited to four, numbered sda1–sda4. The option tempts because GPT disks do allow five or more primary partitions, so sda5 would be primary there — but the lsblk output shows an extended partition.

All filesystems except NFS

Why it fails: Pass 0 means not checked.

/, /boot, and /mnt/data

Why it fails: /mnt/data has pass 0.

/, /boot, and swap

Why it fails: Swap is not checked.

pvcreate /dev/sdc1; vgextend vg_web /dev/sdc1; lvextend -L +300G /dev/vg_web/lv_web

Why it fails: This sequence omits the filesystem resize step (`resize2fs` or `--resizefs`), so the new space is not usable. Incorrect.

pvcreate /dev/sdc; vgextend vg_web /dev/sdc; lvextend -L +300G /dev/vg_web/lv_web; resize2fs /dev/vg_web/lv_web

Why it fails: Using the whole disk `/dev/sdc` without a partition is not standard practice and may cause issues; moreover, the partition step is expected. Incorrect.

At the maintenance prompt, run 'fsck /dev/sda2' and answer yes to all prompts.

Why it fails: Running fsck on a mounted root filesystem risks corrupting ext4 metadata, since the kernel may write to /dev/sda2 concurrently. It is tempting as the direct repair command, but the safe route remounts root read-only or boots a rescue environment first, then runs fsck on the unmounted device.

At the maintenance prompt, run 'fsck -y /dev/sda2' to force repair.

Why it fails: The -y flag auto-answers yes, but fsck still cannot safely repair /dev/sda2 while the root filesystem is mounted read-write. It is tempting because it removes interactive prompts during remote IPMI repair, yet the correct procedure unmounts or remounts root read-only before invoking fsck.

At the maintenance prompt, run 'fsck -a /dev/sda2' to automatically repair.

Why it fails: The -a flag still operates on /dev/sda2 while root is mounted read-write, so ext4 metadata can be corrupted by concurrent kernel writes. It is tempting because automatic repair suits unattended remote consoles, but fsck must first run against an unmounted or read-only-remounted root filesystem.

dumpe2fs -h

Why it fails: dumpe2fs -h reads the ext2/3/4 superblock directly from the block device, which requires root or disk-group membership, so it fails the no-superuser requirement. It is the correct tool when elevated privileges are available and you need detailed filesystem metadata.

findfs UUID=...

Why it fails: findfs UUID=... resolves a UUID to its device node, not the reverse, so it cannot display a filesystem's UUID. It is the right command when you already know the UUID and need to identify which device carries it, for example in fstab troubleshooting.

Convert /var to use LVM by backing up, reformatting, and restoring data.

Why it fails: Converting /var to LVM would require unmounting the filesystem to migrate data, which violates the requirement that the server remain online during the process. This option is tempting because LVM allows dynamic resizing and addition of physical volumes without altering existing paths, making it a correct choice when the filesystem can be taken offline for the initial migration.

Create a symbolic link from /var/www/uploads to /dev/sdb1.

Why it fails: A symlink pointing at the block device /dev/sdb1 is not a mounted filesystem, so writes fail; the device must be mounted first. It tempts because symlinks do preserve existing paths, and would work if the target were the mount point of the mounted /dev/sdb1.

Move /var/www/uploads to /mnt/uploads and create a symbolic link from /var/www/uploads to /mnt/uploads.

Why it fails: The uploads directory is on /var which is full; moving to /mnt is okay, but the symlink doesn't free space on /var unless the data is moved off. However, the data would still physically reside on /var if moved incorrectly. The correct procedure would be to copy to new filesystem, then use bind mount.

ext4: File system optimized for large storage arrays and high concurrency

Why it fails: Incorrect — this describes XFS, not ext4.

swap: File system that stores file metadata in a tree structure

Why it fails: Incorrect — swap is not a file system but a dedicated partition or file for virtual memory.

netstat: Query DNS name servers for host information

Why it fails: This definition describes nslookup, not netstat. nslookup queries DNS servers for domain name or IP resolution.

nslookup: Display network connections and routing tables

Why it fails: This definition describes netstat, not nslookup. netstat displays active network connections, routing tables, and interface statistics.

traceroute: Test connectivity to a remote host

Why it fails: This definition describes ping, not traceroute. ping tests connectivity, while traceroute shows the path taken.

/usr/bin

Why it fails: Incorrect: /usr/bin contains user binaries, not essential for boot.

/usr/local/bin

Why it fails: Incorrect: /usr/local/bin is for locally installed software, not essential for boot.

/bin

Why it fails: Incorrect: /bin contains user binaries, some of which are essential, but /sbin is specifically for system binaries.

mkfs -t ext4 /dev/sdb1

Why it fails: Incorrect: This command would work but is not the most direct; mkfs.ext4 is the standard command.

mke2fs -t ext4 /dev/sdb1

Why it fails: Incorrect: This also works but is not the standard command; mkfs.ext4 is preferred.

mkfs.ext2 /dev/sdb1

Why it fails: Incorrect: mkfs.ext2 creates an ext2 filesystem, not ext4.

The device field

Why it fails: Incorrect: If the device field were missing, it wouldn't mount at all.

The options field

Why it fails: Incorrect: Options can be set to defaults or blank, but if omitted, mount uses defaults.

The mountpoint field

Why it fails: Incorrect: If mountpoint were missing, it wouldn't mount.

blkid /dev/sda

Why it fails: Incorrect: blkid shows filesystem UUID, not partition GUID.

lsblk -f /dev/sda

Why it fails: Incorrect: lsblk shows block devices but not partition type GUIDs.

fdisk -l /dev/sda

Why it fails: Incorrect: fdisk does not support GPT partition UUID display.

fsck -n /dev/sda1

Why it fails: Incorrect: -n means no repair, only check.

fsck -y /dev/sda1

Why it fails: Incorrect: -y assumes 'yes' to all repairs, not interactive.

fsck -a /dev/sda1

Why it fails: Incorrect: -a attempts automatic repairs without interaction.

lsblk

Why it fails: Incorrect. `lsblk` lists block devices but is less focused on partition-specific details compared to `fdisk -l`.

df

Why it fails: Incorrect. `df` shows disk usage of mounted filesystems, not block device information.

mount

Why it fails: Incorrect. `mount` shows currently mounted filesystems, not raw block device attributes.

/lib

Why it fails: /lib is a required directory under /, but it is not one of the three chosen because the question asks for exactly three and /var is also required.

/home

Why it fails: /home is not a required directory; it is recommended but optional, so it is incorrect.

ext2

Why it fails: Incorrect: ext2 does not have journaling.

VFat

Why it fails: VFat maintains a file allocation table and provides no journal, so it cannot replay metadata after an unclean shutdown and is not a journaling filesystem. It is the correct choice for small removable media needing broad cross-platform compatibility, such as USB sticks and memory cards, where journaling overhead and features like permissions are unnecessary.