很多时候，我们可能因为做了某些设置，或者是因为不正常关机 （例如未经通知的停电等等） 而导致系统的 filesystem 错乱，此时，Linux 可能无法顺利开机成功，那怎么办呢？难道要重灌？当然不需要啦！ 进入 rescue 模式去处理处理，应该就 OK 的啦！下面我们就来谈一谈如何处理几个常见的问题！
19.4.1 忘记 root 密码的解决之道
大家都知道鸟哥的记忆力不佳，容易忘东忘西的，那如果连 root 的密码都忘记了，怎么办？ 其实在 Linux 环境中 root 密码忘记时还是可以救回来的！只要能够进入并且挂载 / ， 然后重新设置一下 root 的密码，就救回来啦！
只是新版的 systemd 的管理机制中，默认的 rescue 模式是无法直接取得 root 权限的喔！还是得要使用 root 的密码才能够登陆 rescure 环境耶！ 天哪！那怎办？没关系，还是有办法滴～通过一个名为“ rd.break ”的核心参数来处理即可喔！只是需要注意的是， rd.break 是在 Ram Disk 里面的操作系统状态，因此你不能直接取得原本的 Linux 系统操作环境。所以，还需要 chroot 的支持！ 更由于 SELinux 的问题，你可能还得要加上某些特殊的流程才能顺利的搞定 root 密码的救援喔！
现在就让我们来实作一下吧！（1）按下 systemctl reboot 来重新开机，（2）进入到开机画面，在可以开机的菜单上按下 e 来进入编辑模式， 然后就在 linux16 的那个核心项目上面使用这个参数来处理：
改完之后按下 [crtl]+x 开始开机，开机完成后屏幕会出现如下的类似画面，此时请注意，你应该是在 RAM Disk 的环境，并不是原本的环境， 因此根目录下面的东西跟你原本的系统无关喔！而且，你的系统应该会被挂载到 /sysroot 目录下，因此，你得要这样作：
Generating "/run/initramfs/rdsosreport.txt"
Enter emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.
switch_root:/# # 无须输入密码即可取得 root 权限！
switch_root:/# mount # 检查一下挂载点！一定会发现 /sysroot 才是对的！
.....（前面省略）.....
/dev/mapper/centos-root on /sysroot type xfs （ro,relatime,attr,inode64,noquota）
switch_root:/# mount -o remount,rw /sysroot # 要先让它挂载成可读写！
switch_root:/# chroot /sysroot # 实际切换了根目录的所在！取回你的环境了！
sh-4.2# echo "your_root_new_pw" | passwd --stdin root
sh-4.2# touch /.autorelabel # 很重要！变回 SELinux 的安全本文～
sh-4.2# exit
switch_root:/# reboot
上述的流程你应该没啥大问题才对～比较不懂的，应该是 （1）chroot 是啥？ （2）为何需要 /.autorelabel 这个文件？
- chroot 目录：代表将你的根目录“暂时”切换到 chroot 之后所接的目录。因此，以上表为例，那个 /sysroot 将会被暂时作为根目录， 而我们知道那个目录其实就是最原先的系统根目录，所以你当然就能够用来处理你的文件系统与相关的帐号管理啰！
- 为何需要 /.autorelabel：在 rd.break 的 RAM Disk 环境下，系统是没有 SELinux 的，而你刚刚更改了 /etc/shadow （因为改密码啊！）， 所以“这个文件的 SELinux 安全本文的特性将会被取消”喔！如果你没有让系统于开机时自动的回复 SELinux 的安全本文， 你的系统将产生“无法登陆”的问题 （在 SELinux 为 Enforcing 的模式下！）加上 /.autorelabel 就是要让系统在开机的时候自动的使用默认的 SELinux type 重新写入 SELinux 安全本文到每个文件去！。
不过加上 /.autorelabel 之后，系统在开机就会重新写入 SELinux 的 type 到每个文件，因此会花不少的时间喔！如果你不想要花太多时间， 还有个方法可以处理：
- 在 rd.break 模式下，修改完 root 密码后，将 /etc/selinux/config 内的 SELinux 类型改为 permissive
- 重新开机后，使用 root 的身份下达“ restorecon -Rv /etc ”仅修改 /etc 下面的文件；
- 重新修改 /etc/selinux/config 改回 enforcing ，然后“ setenforce 1 ”即可！
19.4.2 直接开机就以 root 执行 bash 的方法
除了上述的 rd.break 之外，我们还可以直接开机取得系统根目录后，让系统直接丢一个 bash 给我们使用喔！ 使用的方法很简单，就同样在开机的过程中，同在 linux16 的那一行，最后面不要使用 rd.break 而是使用“ init=/bin/bash ”即可！ 最后开机完成就会丢一个 bash 给我们！同样不需要 root 密码而有 root 权限！
但是要完整的操作该系统是不可能的，因为我们将 PID 一号更改为 bash 啦！所以，最多还是用在救援方面就是了！ 而且，同样的，要操作该系统你还是得要 remount 根目录才行啊！否则无法更改文件系统啦！基本上，这个系统的处理方法你应该是要这样作的：
如上图的完整截图，你会发现由于是最默认的 bash 环境，所以连 PATH 都仅有 /bin 而已～所以你不能下达 reboot ！同时， 由于没有 systemd 或者是 init 的存在，所以真的使用绝对路径来下达 reboot 时，系统也是无法协助你重新开机啦！ 此时只能按下 reset 或者是强制关机后，才能再次开机！所以…感觉上还是 rd.break 比较保险…
同时请注意，鸟哥上面刻意忘记处理 /.autorelabel 的文件创建～你如果按照鸟哥上述的方法实作的话，嘿嘿！此时应该是无法登陆的喔！ 请重新开机进入 rd.break 模式，然后使用 SELinux 改为 permissive 的方法来实验看看。等到可以顺利以 root 登陆系统后， 使用 restorecon -Rv /etc 来瞧一瞧，应该会像下面这样：
[[email protected] ~]# getenforce
Permissive
[[email protected] ~]# restorecon -Rv /etc
restorecon reset /etc/shadow context system_u:object_r:unlabeled_t:s0
->system_u:object_r:shadow_t:s0
restorecon reset /etc/selinux/config context system_u:object_r:unlabeled_t:s0
->system_u:object_r:selinux_config_t:s0
[[email protected] ~]# vim /etc/selinux/config
SELINUX=enforcing
[[email protected] ~]# setenforce 1
19.4.3 因文件系统错误而无法开机
如果因为设置错误导致无法开机时，要怎么办啊？这就更简单了！最容易出错的设置而导致无法顺利开机的步骤，通常就是 /etc/fstab 这个文件了，尤其是使用者在实作 Quota/LVM/RAID 时，最容易写错参数， 又没有经过 mount -a 来测试挂载，就立刻直接重新开机，真要命！无法开机成功怎么办？这种情况的问题大多如下面的画面所示：
看到最后两行，他说可以输入 root 的密码继续加以救援喔！那请输入 root 的密码来取得 bash 并以 mount -o remount,rw / 将根目录挂载成可读写后，继续处理吧！其实会造成上述画面可能的原因除了 /etc/fstab 编辑错误之外，如果你曾经不正常关机后，也可能导致文件系统不一致 （Inconsistent） 的情况， 也有可能会出现相同的问题啊！如果是扇区错乱的情况，请看到上图中的第二行处， fsck 告知其实是 /dev/md0 出错， 此时你就应该要利用 fsck.ext3 去检测 /dev/md0 才是！等到系统发现错误，并且出现“clear [Y/N]”时，输入“ y ”吧！
当然啦，如果是 XFS 文件系统的话，可能就得要使用 xfs_repair 这个指令来处理。这个 fsck/xfs_repair 的过程可能会很长，而且如果你的 partition 上面的 filesystem 有过多的数据损毁时，即使 fsck/xfs_repair 完成后，可能因为伤到系统盘，导致某些关键系统文件数据的损毁，那么依旧是无法进入 Linux 的。此时，就好就是将系统当中的重要数据复制出来，然后重新安装，并且检验一下，是否实体硬盘有损伤的现象才好！不过一般来说，不太可能会这样啦～ 通常都是文件系统处理完毕后，就能够顺利再次进入 Linux 了。