19.4 开机过程的问题解决
最后更新于:2022-04-01 22:16:06
## 19.4 开机过程的问题解决
很多时候,我们可能因为做了某些设置,或者是因为不正常关机 (例如未经通知的停电等等) 而导致系统的 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 的那个核心项目上面使用这个参数来处理:
![通过 rd.break 尝试救援 root 密码](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-05-13_5735737d4d85e.jpg)图19.4.1、通过 rd.break 尝试救援 root 密码
改完之后按下 [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 的方法](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-05-13_5735737d6b698.jpg)图19.4.2、直接开机使用 bash 的方法
如上图的完整截图,你会发现由于是最默认的 bash 环境,所以连 PATH 都仅有 /bin 而已~所以你不能下达 reboot !同时, 由于没有 systemd 或者是 init 的存在,所以真的使用绝对路径来下达 reboot 时,系统也是无法协助你重新开机啦! 此时只能按下 reset 或者是强制关机后,才能再次开机!所以...感觉上还是 rd.break 比较保险...
同时请注意,鸟哥上面刻意忘记处理 /.autorelabel 的文件创建~你如果按照鸟哥上述的方法实作的话,嘿嘿!此时应该是无法登陆的喔! 请重新开机进入 rd.break 模式,然后使用 SELinux 改为 permissive 的方法来实验看看。等到可以顺利以 root 登陆系统后, 使用 restorecon -Rv /etc 来瞧一瞧,应该会像下面这样:
```
[root@study ~]# getenforce
Permissive
[root@study ~]# 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
[root@study ~]# vim /etc/selinux/config
SELINUX=enforcing
[root@study ~]# setenforce 1
```
### 19.4.3 因文件系统错误而无法开机
如果因为设置错误导致无法开机时,要怎么办啊?这就更简单了!最容易出错的设置而导致无法顺利开机的步骤,通常就是 /etc/fstab 这个文件了,尤其是使用者在[实作 Quota/LVM/RAID](../Text/index.html) 时,最容易写错参数, 又没有经过 mount -a 来测试挂载,就立刻直接重新开机,真要命!无法开机成功怎么办?这种情况的问题大多如下面的画面所示:
![文件系统错误的示意图](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-05-13_5735737d83837.jpg)图19.4.3、文件系统错误的示意图
看到最后两行,他说可以输入 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 了。
';