I modified /etc/fstab
.
I verified the new devices and I can mount them with the mount
command.
How may I validate the modifications made to /etc/fstab
?
You can simple run: mount -a
-a Mount all filesystems (of the given types) mentioned in fstab.
This command will mount all (not-yet-mounted) filesystems mentioned in fstab and is used in system script startup during booting.
mount -a
by rereading /etc/fstab
would also reload /etc/mtab
so he should be fine with that only.
mount
man page: Note that it is a bad practice to use mount -a for fstab checking. The recommended solution is findmnt --verify.
(see answer by rockwotj)
sudo findmnt --verify --verbose
is the best way I've found
findmnt
told me that fuse.sshfs seems unsupported by the current kernel
, which is not true because I was able to mount the sshfs share with mount -a
Commented
Mar 8, 2021 at 3:10
errors=remout-ro
for example, i have to boot using another live cd to investigate
The mount command take an --fake
or -f
for short. The following command should do what you need:
mount -fav
The following is in the documentation for -f
option:
Causes everything to be done except for the actual system call; if it's not obvious, this ``fakes'' mounting the filesystem. This option is useful in conjunction with the -v flag to determine what the mount command is trying to do.
(Note this is Linux - check before using elsewhere: FreeBSD uses -f
for 'force' - exactly the opposite meaning.)
mount --fake -a
but it seems to return exit code($?)=0
always. Umm..
successfully mounted
even when the mount point dosent exist
Commented
Nov 23, 2018 at 8:33
mount -fav
validated it as correct. As soon as I did a mount -a
it found an error.
Commented
Aug 11, 2019 at 20:42
Note that if you add a swap file to your fstab, mount -a
won't turn it on: you'll want to run swapon -a
.
I found this /problem/ but the solution didn't meet my requirements.
When rebooting with any invalid entries in the /etc/fstab, such as missing file systems that fsck cannot check; the system will fail to boot. That can be much more difficult to deal with if you have a headless box.
This is my solution to checking /etc/fstab to avoid this boot problem:
# cat /usr/local/bin/check-fstab-uuid-entries.sh
#!/usr/bin/env bash
for x in $(grep ^UUID /etc/fstab|cut -d \ -f 1|cut -d = -f 2)
do
if [ ! -h /dev/disk/by-uuid/$x ];then
echo $(grep $x /etc/fstab) ..... not found
fi
done
mount -fav
...
Commented
Jan 30, 2022 at 5:18
TBH even fake mounting doesn't safely validate the fstab for bad fs type entries.
you can have entries that have correct uuid's, directories etc but if you specify a noexistant FS type this will halt your boot next time.
[root@grumpy ~]# grep backup /etc/fstab UUID=5ed48e5e-7251-4d49-a273-195cf0432a89 /mnt/backup noatime,nodiratime,xfs defaults,nodev,nosuid 0 0 [root@grump ~]# [root@grumpy ~]# mount -fav | grep backup /mnt/backup : successfully mounted [root@grumpy ~]#
mount -a is safe method to check /etc/fstab otherwise wrong entry could break the system
It is also advised to keep a backup copy of original /etc/fstab file. it could be copied to home directory of root
I open another term or tab and run: tail -f /var/log/kern.log
Sometimes errors show there that don't show when mounting.