Which is fine; if you have an IP-based KVM where you can get console access without actually being at the facility. But not so great when a screwed up fstab file requires you to go physically visit the location.
So how do we verify that our fstab file makes sense prior to a reboot? The answer lies in the mount command. There are (3) useful options that can be passed to the mount command which will help us check the fstab file prior to a reboot.
-f - FAKE IT (Causes everything to be done except for the actual system call). This tells mount to do everything, but don't actually change anything.
-a - Mount all filesystems mentioned in fstab.
-v - Be verbose about it.
Here's an example where everything is fine and dandy.
# mount -fav
mount: /dev/md0 already mounted on /boot
mount: devpts already mounted on /dev/pts
mount: tmpfs already mounted on /dev/shm
mount: proc already mounted on /proc
mount: sysfs already mounted on /sys
mount: /dev/md4 already mounted on /var/log
nothing was mounted
Same example, except that I screwed up the name of /dev/md4 in the fstab file:
# mount -fav
mount: /dev/md0 already mounted on /boot
mount: devpts already mounted on /dev/pts
mount: tmpfs already mounted on /dev/shm
mount: proc already mounted on /proc
mount: sysfs already mounted on /sys
/dev/md4x on /var/log type ext3 (rw,noatime)
nothing was mounted
Now, there's probably a better way to do this, but this serves as at least a moderate check against shooting yourself in the foot.
6 comments:
Hey, this article was exactly what I needed -- thanks. Now I'm feeling okay about what happens after the power goes out.
This situation is also addressed by Amazon's cloud hosting. If your fstab is hosed, you de-attach the boot volume from the server in question, attach it to working Linux server, fix it, and try again.
Thanx. What I needed :)
Appreciate the help! Wasn't aware of the -a parameter on mount.
Thanks!
Thanks!
Thank you, it helps me
Post a Comment