记一次断电引起的CentOS引导失败

    公司大楼举行消防演习，期间会拉闸断电，所以将长期运行的服务器都做了关机。可能是没有确认完全关机，一台服务器在重新上电之后，停留在了grub界面，引导阶段过不去了。

    起初以为只是grub引导的问题，借鉴文章：如何解决CentOS开机直接进入grub命令界面 - 走看看，尝试恢复grub配置，无果，如下图：

    没能找到0x83类型的Boot分区，心里就咯噔了，怕是分区坏掉了吧，问题不在重建grub配置上。

    赶紧找系统盘来救援吧，这里碰到了一个坑，恢复模式总进入dracut环境，其实很久没有用到救援了，起初也没觉得是坑，总算看到命令行了嘛，一通操作，也没解决任何问题（此时处于各种确认和抓瞎状态：什么/etc/fstab，mount，lsblk，df -Th等），基本确认数据盘，数据文件都ok，就是系统盘boot区不见了。在蒋老师的提议下，外挂一块硬盘上去，重新装个系统试试，这时居然无法进入安装界面，才知道之前都是因为没法载入安装介质，所以进入了dracut环境，当然对于我们碰到的问题，可能dracut环境也能搞定，只是后来就不在这个环境下修复了。

    先来看看这个坑吧，看图：

    启动安装和修复的时候，启动命令里都带有安装介质的完整盘符，但是我们烧制的安装U盘，在Windows中盘符是“CentOS 7 x8”，已经达到最大长度限制了，网上说改盘符但没有成功，于是在启动选项上按tab键，修改LABEL为“CentOS\x207\x20x8”，其中的\x20就是空格的转义符不用改，这样就能正常进入到sh-4.2#，这里其实我们一开始都不太记得原系统是CentOS的哪个版本了，用了6.5和7系列的镜像来尝试。

    到此安装个新系统是没有问题的，我们的阵列卡目前来可以先稳住不动了，但新装的系统还要配置一系列服务，特别是git之类，也有不少麻烦，想看看还有没有机会把旧系统修复。

    其实，之前启动修复进入dracut环境的时候，已经注意到提示了，只是一开始没往那个方向去尝试，具体错误如下图：

    就是sda设备上有I/O错误嘛，于是关键词搜索一番，参考文章：磁盘blk_update_request: I/O error-阿里云开发者社区，因为我们没有floppy，所以直接尝试2；

    先通过badblocks检查硬盘坏道，这里需要几个小时（耐心等待结束）：

    查出4个坏块：

    看到这四个坏块，我也没想着先去做坏道修复，因为看了这里的地址和之前fdisk查到的boot区地址匹配不上

    Boot区地址要从409600000开始呢，所以又尝试了xfs_repair方法来修复sda3，但没有成功，通过blkid查找挂载设备，sda3就是不出现在列表中。

    那么就试试把坏块修复掉吧：

    ①badblocks -s -w /dev/sda 204800003 204800000 (参数里END在前，START在后，END代表需要修复的扇区末端，START代表需要修复的扇区起始端)

    这一步完成后再用badblocks -s -v -o /root/bb.log /dev/sda检测看是否还有坏道存在，（又是数小时等待之后）已经是0/0/0了，于是执行下一步：

    ②fsck -a /dev/sda3得到：

    之后再mount sda3

    mount成功了，不报magic number，super block问题了，进入目录ls一下，文件都在，看来成功了。

    reboot，看到了图形界面：

    OG复出了！

    前后断断续续，居然折腾了快1周，记录一下。