220-1102 Question 272
Single answer/etc/fstabA Linux workstation has a secondary ext4 data drive that should be mounted automatically at /data after every reboot. A technician adds a new line to /etc/fstab, but after restarting, the system drops into emergency mode because the mount entry is invalid. The technician wants to verify and troubleshoot the new /etc/fstab entry without rebooting again. Which command should the technician run first to safely test all entries in /etc/fstab and identify mount errors?
- A
mount -a
- B
fsck -A
- C
systemctl default
- D
mkfs.ext4 /dev/sdb1
Show answer and explanation
Correct answer: A
Explanation
When troubleshooting /etc/fstab, best practice is to test changes immediately with "mount -a" before rebooting. This helps catch common problems such as an incorrect UUID, wrong filesystem type, invalid mount options, or a missing mount point directory. On systems using systemd, invalid critical mount entries in /etc/fstab can cause boot failures or emergency mode. Administrators commonly use persistent identifiers such as UUIDs in /etc/fstab to avoid device-name changes across reboots. The manual pages for fstab(5) and mount(8) support this workflow: edit the file carefully, then run "mount -a" to validate the configuration before restarting.
- A. Correct.
Correct. The command "mount -a" tells Linux to attempt to mount all filesystems listed in /etc/fstab that are not marked with options preventing automatic mounting. This is the standard and safest first step after editing /etc/fstab because it lets the technician validate the syntax and mount definitions immediately without rebooting. If there is a problem with the new entry, the command typically returns an error that helps identify the issue.
- B. Incorrect.
Incorrect. "fsck -A" checks filesystems listed in /etc/fstab, but it is not the correct first command for validating whether a newly added mount entry is syntactically correct or can be mounted properly. It focuses on filesystem consistency checks rather than testing mount configuration. A technician might choose this if they suspect corruption, but that does not address the primary problem described.
- C. Incorrect.
Incorrect. "systemctl default" attempts to switch to the default systemd target, but it does not test or validate /etc/fstab entries in a direct or safe troubleshooting workflow. This choice reflects a misunderstanding of systemd targets versus filesystem mount validation.
- D. Incorrect.
Incorrect. "mkfs.ext4 /dev/sdb1" would create a new ext4 filesystem on the specified partition, destroying existing data on that partition. This is not a troubleshooting step for an invalid /etc/fstab entry. Someone might choose it if they assume the issue is an unformatted disk, but the scenario specifically indicates the problem is the mount entry configuration.