由于fstab文件是存放在系统根目录下的，因此需要挂载原来系统的根分区，从上面可知根分区对应的设备名为/dev/sda3，接着在修复模式创建的临时根分区下创建一个挂载点，然后挂载原来系统的根分区。操作过程如下所示：
sh-3.1# pwd
/
sh-3.1# mkdir temp
sh-3.1# mount /dev/sda3 /temp
sh-3.1# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev 515644 0 515644 0% /dev
/tmp/loop0 79872 79872 0 100% /mnt/runtime
/dev/sda3 2972268 259916 2558932 10% /temp
这样以来，原有根分区的文件全部挂载到了/temp目录下，接着就可以创建我们需要的fatab文件了。
sh-3.1# vi /temp/etc/fstab
LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
LABEL=/cicro /cicro ext3 defaults 1 2
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
LABEL=/home /home ext3 defaults 1 2
LABEL=/opt /opt ext3 defaults 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
LABEL=/tmp /tmp ext3 defaults 1 2
LABEL=/usr /usr ext3 defaults 1 2
LABEL=/var /var ext3 defaults 1 2
LABEL=SWAP-sda9 swap swap defaults 0 0
配置完毕，保存退出，然后重启系统。
sh-3.1#reboot
2、root文件系统破坏，导致系统无法启动
Linux下普遍采用的是ext3文件系统，ext3是一个具有日志记录功能的日志文件系统，可以进行简单的容错和恢复，但是在一个高负荷读写的ext3文件系统下，如果突然发生掉电，就很有可能发生文件系统内部结构不一致，导致文件系统破坏。
Linux在启动时，会自动去分析和检查系统分区，如果发现文件系统有简单的错误，会自动修复，如果文件系统破坏比较严重，系统无法完成修复时，系统就会自动进入单用户模式下或者出现一个交互界面，提示用户介入手动修复，现象类似下面所示：
checking root filesystem
/dev/sdb5 contains a file system with errors, check forced
/dev/sdb5:
Unattached inode 68338812
/dev/sdb5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
(i.e., without -a or -p options)
FAILED
/contains a file system with errors check forced
an eror occurred during the file system check
****dropping you to a shell;the system will reboot
****when you leave the shell
Press enter for maintenance
(or type Control-D to continue):
give root password for maintenance
从这个错误可以看出，系统根分区文件系统出现了问题，系统在启动时无法自动修复，然后进入到了一个交互界面，提示用户进行系统修复。
这个问题发生的机率很高，引起这个问题的主要原因就是系统突然掉电，引起文件系统结构不一致。一般情况下解决此问题的办法是采用fsck命令，进行强制修复。
根据上面的错误提示，当按下“Control-D”组合键后系统自动重启，当输入root密码后进入系统修复模式，在修复模式下，可以执行fsck命令，具体操作过程如下：
[root@localhost /]#umount /dev/sdb5
[root@localhost /]#fsck .ext3 -y /dev/sdb5
e2fsck 1.39 (29-May-2006)
/ contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Inode 6833812 ref count is 2, should be 1. Fix? yes
Unattached inode 6833812
Connect to /lost+found? yes
Inode 6833812 ref count is 2, should be 1. Fix? yes
Pass 5: Checking group summary information
Block bitmap differences: -(519--529) -9273
Fix? yes
…… ……
/: ***** FILE SYSTEM WAS MODIFIED *****
/: 19/128520 files (15.8% non-contiguous), 46034/514048 blocks
上面就是fsck修复受损文件系统的过程，fsck详细用法在本书第四章有详细的讲述，这里不在多讲。需要注意的是，在执行fsck的时候，一定要先卸载要修复的分区，然后再执行修复操作，切记！