Hi Folks!
I accidentally overwrote in /etc/fstab file. Can you guys please tell me, what impact it would have created, when I restarted the machine(RHEL6).
I executed this command :
# blkid /dev/vda5 > /etc/fstab
It will not boot.
I powered off the Virtual Machine and started again, it started, but I don't know the state of machine after start.
Because I had to leave, so I am curious to know.
Any storage that is mounted by the OS uses /etc/fstab to control where it is mounted and with what parameters set.
Essentially, nothing will mount, and as said previously, your node won't boot.
Backups rock!
But it did, that's strange after power-off and starting it again, it started again. Is there a backup file or so that OS creates it for itself.
Just spun up a CentOS box to check, and you're right, the box does boot, you just can't do much with it as it does not have anything mounted filesystem-wise.
The good news is that you could recreate the /etc/fstab file manually and as long as it matched the original, with everything mounted in the correct place, you could carry on using your server as if nothing had happened, after a reboot of course.
1 Like
Thanks a lot!
that was useful, lets hope we will get more informative answers.
Have you no backups? or at least a copy of config files...
It will be difficult to guess the entries of your fstab unless you havent done anything special... that means accepted the defaults at install time.
No I didn't.
But I am amusing that Linux don't have any preliminary feature for the back-up.
It can't be that vulnerable.
If you delete your registry Hive files, Windows won't boot properly either. How vulnerable, right?
Unlike your registry however, it can be rewritten from scratch by hand in a reasonable amount of time. Use things like fdisk and such to find all your partitions, mount them in a restore disk to figure out which is which, and write entries into your fstab like so:
# /etc/fstab: static file system information.
#
# noatime turns off atimes for increased performance (atimes normally aren't
# needed; notail increases performance of ReiserFS (at the expense of storage
# efficiency). It's safe to drop the noatime options if you want and to
# switch between notail / tail freely.
#
# See the manpage fstab(5) for more information.
#
# <fs> <mountpoint> <type> <opts> <dump/pass>
# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
/dev/sda1 /boot ext2 noatime 1 2
/dev/sda3 / ext3 noatime 0 1
/dev/sda5 /var ext3 noatime 0 1
/dev/sda6 /usr ext3 noatime 0 1
/dev/sdb1 /home ext4 noatime 0 1
/dev/sda2 none swap sw 0 0
/dev/cdrw /mnt/cdrom iso9660 noauto,ro,user 0 0
/dev/fd0 /mnt/floppy auto noauto,user 0 0
# NOTE: The next line is critical for boot!
proc /proc proc defaults 0 0
# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# POSIX shared memory (shm_open, shm_unlink).
# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
# use almost no memory if not populated with files)
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
Of course, yours won't be exactly the same. The partition types, device names, and numbers will all differ, not to mention you won't have the same layout either. But that's how it works.
And when you've written the new fstab file, don't forget to back it up! 
The possibility of overwriting important files is one of the reasons I tell new Linux admins to avoid routinely using the root account, but instead creating an account with sudo privileges for normal day-to-day stuff, at least it doesn't let you change important files without using sudo, so there isn't the same possibility of accidentally overwriting system files.
For future reference, if anything like this should ever happen again, typing
mount
will give you the info you need to rewrite the fstab. I would suggest never rebooting or restarting after overwriting something critical - Unix-style systems are easy to get under the hood of, but not always so forgiving of human error.
cat /etc/mtab
would also be helpful.
Assuming you don't have a backup, you'll probably need to run fdisk/cfdisk and get an idea of what partitions are set up, and go from there.
It would have been helpful if immediately upon submission of that command the shell had forked an assistant:
All joking aside, that won't be your last mistake. They happen to everyone from time to time. The difference is whether you're prepared to recover. You should not only have backups but a tested recovery procedure.
Regards,
Alister
After it boots, I would do this... (as root)
fdisk -l
This will print you your partitions like this:
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 300873727 150435840 83 Linux
/dev/sda2 300875774 312498175 5811201 5 Extended
/dev/sda5 300875776 312498175 5811200 82 Linux swap / Solaris
From here, build a new /etc/fstab from scratch, it's pretty basic...
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
/dev/sda1 / ext4 errors=remount-ro 0 1
/dev/sda5 none swap sw 0 0
Main things to note...
1) /etc/mtab check it for proc etc.
2) Is my fs ext3 or ext4 or ??? check /etc/mtab.
3) Swap? well the fdisk will tell you if you had it...
4) Any other mounts that I care about, eg. /var etc.
/etc/mtab will help you alot!
Hope this helps 
Aaron.
hi nix,
if you have overwritten the fstab file , the good part is to restore it from backup if you dont have any backup in system. If you are not restoring it from backup , it will give adverse effects if there were any SAN mounts or NFS mounts etc.
So try to restore , if you dont have backup...you have to convince yourself.......
Heh, maybe there should be a utility like vipw,vigr for /etc/fstab
You could say the same about anything in /etc/ really... And so design some massive system for maintaining /etc/, creating a swallowed-a-spider-to-kill-the-fly situation -- what do you do when that breaks down, cry?
Restore from backup, of course, because piling software on software hasn't actually made it more reliable, just made an illusion of it.