重置密码修复Linux系统

故障现象

近些天，机房的设备接二连三遭遇些不顺，不是被人把服务器供电搞断，就是碰到存储故障导致存储连接丢失，一波接一波的虚机不断被伤害，有的虚机重启后一切正常，有的虚机变成了只读文件系统，有的则干脆在磁盘检查报未预期的不一致错误，几番折腾下来，一直对存储不太重视的我，对存储的“情感”更进了一步。

首先是变为只读文件系统的一类，即操作系统正常运行中，突然与存储失去了联系，Windows与Linux容忍的时间是不一样的，超出了最大容忍时间，操作系统就会将磁盘变为只读文件系统，确保数据无法写入，否则引发异常。此时，无论Windows还是Linux在表面上看都正常运行着，网络也通畅，读多写少的业务可能都察觉不到有异常，写入较多的业务则会较为敏感，会在各个操作界面抛出异常。

解决这类问题，最简单易行的办法就是重启虚机。重启后有两种可能，其一是一切正常；其二则是出现磁盘自检并且需要人工干预，这是因为与存储失联的容忍时间内还有未写入磁盘的数据，造成元数据信息不一致。当然，也有更高要求的环境需要不重启进行重新挂载，这不仅要求更高超的技术水平，同时也依赖底层硬件支持在线刷新连接状态方可。本例所遇到的环境并没那么严谨，直接采用重启这一“粗暴”途径。

重新启动后，Linux系统直接抛出UNEXPECTED INCONSISTENCY错误，也就是文件系统自检发现不一致。

故障解决

在操作系统中，为了增加系统性能而采用的Cache机制，分为write-through和write-back两 种。Writethrough也叫直写模式，在数据保存时，同时写入缓存Cache和后端存储。此模式缺点在于数据写入磁盘的IO速度较慢，必须等待写入磁盘成功才算完毕。

Write-back也叫回写模式，在数据保存时只写入缓存Cache，只在数据被替换出缓存时，被修改的缓存数据才会被写到后端存储。此模式的优点是数据写入Cache速度快，不需要等存储反馈落盘成功就算完毕，缺点是数据未被写入存储时出现系统掉电或死机等情况，就会导致这一现象（如图1）。

图1 文件系统待修复界面及操作

遇到这一问题不用太担心，只要输入正确的根用户密码，执行fsck-y /dev/VolGroup00/LogVol01即可完成磁盘修复，再次重启就能正常进入操作系统了。在这一命令中，fsck是检查文件系统并修复错误的命令，-y对提出的所有问题假定一个“yes”的响应，若不使用该选项，则每检查到一个错误的文件都需要人工响应是否修复，/dev/VolGroup00/LogVol01即待检测修复的目标文件系统。

然而，接下来处理的另一个虚机遇到的问题又有些棘手——根用户密码始终不正确。询问了相关同事，所有可能的密码都验证失败，必须另想办法。

第一个想到的是单用户模式重置密码，在GRUB启动菜单里移动光标至kernel项一行，按e编辑kernel菜单项，在行末尾输入single，更改后按回车返回Linux启动菜单项界面，然后按b即通过刚修改的行引导Linux从而进入单用户模式。可是，相同的磁盘修复提示导致无法进入单用户模式，即不能重置密码，也不能修复磁盘。

第二个想到的是Linux救援模式，通过引导光盘进入救援模式环境，选择不自动挂载扫描到的文件系统，救援模式下能够找到本地磁盘的分区，可尝试了好多种路径都无法进行修复。重启进入救援模式，选择自动挂载本地文件系统，居然成功挂载，并且chroot /mnt/sysimages也能进入文件系统目录，然而执行修复操作，依然无法成功。

转念一想，既然能够chroot进入到损坏的文件系统，是否能够修改密码呢？立即尝试很快有了答案——可以重置root密码。重启系统，待提示输入根用户密码进入修复操作界面，终于不再报密码错误了，从而顺利完成了磁盘修复。

故障分析

从修复文件系统操作忽然变成了特定情况下的重置密码，密码的错误本身就是蹊跷的，因为在出现问题前同事都成功登录过，怀疑是因为文件系统损坏而导致无法验证密码，错误的密码又影响文件系统的修复操作，相互的制约使虚机承载的业务迟迟得不到恢复。救援模式从独立的内存环境中挂载文件系统，遗憾未能找到恰当的修复文件系统的办法，但密码的重置也使问题的破解有了可操作性。

回顾整个问题，重置密码和修复文件系统都还是问题的表象，存储系统的重要性不言而喻，每个虚机根据业务属性的不同，合理选择writethrough和write-back两种Cache写机制，以期尽可能避免问题复杂度的提升。