Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm using Ubuntu 10.04 and i accidently removed all the entries from the fstab files while doing a backup (Yeah, I know ;)).

I would like to know if there is a way to rebuild it with the current mount options, since I did not restart the server since the deletion. If there is no such program, could anybody help me rebuild it.

Using this, I have found the command to show the current setup, but I don't know what to do with it.

$ sudo blkid
/dev/sda1: UUID="3fc55e0f-a9b3-4229-9e76-ca95b4825a40" TYPE="ext4" 
/dev/sda5: UUID="718e611d-b8a3-4f02-a0cc-b3025d8db54d" TYPE="swap" 
/dev/sdb1: LABEL="Files_Server_Int" UUID="02fc2eda-d9fb-47fb-9e60-5fe3073e5b55" TYPE="ext4" 
/dev/sdc1: UUID="41e60bc2-2c9c-4104-9649-6b513919df4a" TYPE="ext4" 
/dev/sdd1: LABEL="Expansion Drive" UUID="782042B920427E5E" TYPE="ntfs" 


$ cat /etc/mtab
/dev/sda1 / ext4 rw,errors=remount-ro 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
none /sys sysfs rw,noexec,nosuid,nodev 0 0
none /sys/fs/fuse/connections fusectl rw 0 0
none /sys/kernel/debug debugfs rw 0 0
none /sys/kernel/security securityfs rw 0 0
none /dev devtmpfs rw,mode=0755 0 0
none /dev/pts devpts rw,noexec,nosuid,gid=5,mode=0620 0 0
none /dev/shm tmpfs rw,nosuid,nodev 0 0
none /var/run tmpfs rw,nosuid,mode=0755 0 0
none /var/lock tmpfs rw,noexec,nosuid,nodev 0 0
none /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
none /var/lib/ureadahead/debugfs debugfs rw,relatime 0 0
/dev/sdc1 /home ext4 rw 0 0
/dev/sdb1 /media/Files_Server ext4 rw 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,noexec,nosuid,nodev 0 0
/dev/sdd1 /media/Expansion\040Drive fuseblk rw,nosuid,nodev,allow_other,blksize=4096,default_permissions 0 0
gvfs-fuse-daemon /home/yvoyer/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,user=yvoyer 0 0
/dev/sdd1 /media/Backup500 fuseblk rw,nosuid,nodev,sync,allow_other,blksize=4096,default_permissions 0 0
/dev/sr0 /media/DIR-615 iso9660 ro,nosuid,nodev,uhelper=udisks,uid=1000,gid=1000,iocharset=utf8,mode=0400,dmode=0500 0 0
gvfs-fuse-daemon /home/cdrapeau/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,user=cdrapeau 0 0

share|improve this question
add comment

3 Answers 3

up vote 4 down vote accepted

You can copy the lines started with /dev/sd** from mtab and paste them in to a new text file and change /dev/sd** with UUID or LABEL. For example from your config:

use

UUID="3fc55e0f-a9b3-4229-9e76-ca95b4825a40" / ext4 rw,errors=remount-ro 0 0

instead

/dev/sda1 / ext4 rw,errors=remount-ro 0 0

The line above also works, but UUID is the new standart and if your grub configured with UUID, it might can't understand which partition is what.

if partition has Label you can use the LABEL instead UUID, for example:

LABEL="Files_Server_Int" /media/Files_Server ext4 rw 0 0

IMO copy your mtab to a new file and remove the lines started with "none" and change the /dev/sd** part with blkid output equivelants. If UUID exist, use the UUID instead of /dev/sd**. If LABEL exist use the LABEL instead of UUID.

Do not remove anything else except "none" lines. Save the file, change the file name to fstab and copy in to /etc.

This might help to restore your fstab.

share|improve this answer
    
What happens if I change the label later, wouldn't be better to use the UUID that never change (to my knowledge) compared to the label that can be changed? –  yvoyer Nov 22 '11 at 16:45
    
Not sure enough about what happens on grub side.. But if you make change in partition label, you must made same change in fstab and reinstall grub. If you don't, that partition can't be mounted anymore. Certainly using UUID is solid rock solution for now. But somehow, some distros using labels instead of uuids, I don't know why... –  Sencer H. Nov 23 '11 at 16:44
    
Could someone please place this information into a comment against the selected answer by RecNes Thanks. Unfortunately I have bitter experience of UUID's failing due to the value being modified. Its an extreme case, so I am adding this in case someone else out there gets into a problem. During a power failure (probably caused due to a localised lightning strike) the UUID values on my internal disks became modified ! It was only possible to realise this was the problem after it happened a second time. The solution however isn't that hard, it is just a matter of using the output of ls /dev/disk/ –  DaveM Nov 26 '12 at 12:23
add comment

The "contents" of mtab (it is dynamically generated) is 100% compatible with the fstab format.

First of all, copy this current file somewhere SAFE, right now:

cp /etc/mtab ~/mtab_working

Then copy it to a fresh fstab and remove everything that's not essential for booting; you will be left with:

/dev/sda1 / ext4 rw,errors=remount-ro 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
none /dev/pts devpts rw,noexec,nosuid,gid=5,mode=0620 0 0
none /dev/shm tmpfs rw,nosuid,nodev 0 0
/dev/sdc1 /home ext4 rw 0 0

And then just add stuff back (while the rebooted system is up) until you have all you need.

You have some time to read the fstab and mount man pages while it reboots :)

share|improve this answer
add comment

You can try to write the file in the following format:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
/dev/sda8       /               ext4    errors=remount-ro 0       1
/dev/sda6       /boot           ext4    defaults        0       2
# swap was on /dev/sda7 during installation
UUID=718e611d-b8a3-4f02-a0cc-b3025d8db54d none            swap    sw              0       0

In this example, I have only two partitions / and /boot

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.