发表于:

接到求助，某CentOS节点失联，BMC控制台无响应，进入救援模式，检查分区，发现/dev/sda（系统盘所在设备块）下无任何分区。由于服务器系统盘全部是做了RAID1的，因此排除了硬件损坏的可能，和服务器owner确认可能是有同学误操作删除分区表后，着手准备恢复。由于时间紧急没有截屏记录，以下为文字回忆，主要是记录解决思路和踩坑过程。

  1. 挂载Live盘，进入救援模式，恢复网络连接，用于安装testdisk（testdisk类似于windows中的diskgenius，用来恢复linux分区数据屡试不爽）

    nmcli connection modify eth0 ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns 8.8.8.8

  2. 计划使用yum安装，无奈缺少yummain依赖，此路不通，改为下载离线二进制包

    wget https://www.cgsecurity.org/testdisk-7.1.linux26-x86_64.tar.bz2

  3. 解压后执行testdisk /dev/sda，开始恢复分区表

    # 光标选中sda磁盘，选择Proceed回车
# 接下来选择分区类型，Intel表示MBR分区，EFI GPT表示GPT分区，根据实际情况选择
# 这里我踩了坑，testdisk默认选择了GPT分区，后来发现实际这块系统盘是MBR分区，只能用testdisk重新恢复一遍MBR分区
# 选择Analyse，选择Quick Search
# 等待分区表搜索结束后，绿色部分就是被删除的分区表，可以简单核对下是否准确，回车进入分区
# 如果分区数量依然不对，这里可以选择Deeper Search深度扫描
# 如果分区确定没问题，选择Write，回车将分区表重新写入磁盘
# 退出testdisk

  4. lsblk查看，我们熟悉的系统分区又回来了，通过挂载检查各个分区文件都在，但是重启后，未显示内核引导，光标直接卡在1234F:，由于内核引导都未能加载，判断是grub引导出现问题。

  5. 再次返回救援模式，挂载sda1引导分区，果然发现grub和grub2目录一堆问号，且访问和删除都提示structure needs cleaning

  6. 使用xfs_repair修复文件系统无果，准备重新格式化boot分区，将原boot分区中除grub和grub2目录以外的文件全部备份，mkfs.xfs /dev/sda格式化boot分区，恢复备份文件，然后开始修复引导

    # 在chroot前bind mount，解决grub-probe: error: cannot find a device for / 报错
mount -o bind /dev /mnt/sysimage/dev
mount -o bind /proc /mnt/sysimage/proc
mount -o bind /run /mnt/sysimage/run
mount -o bind /sys /mnt/sysimage/sys
​
chroot /mnt/sysimage
grub2-install /dev/sda
grub2-mkconfig -o /boot/grub2/grub.cfg

  7. 恢复引导后重启，熟悉的内核引导界面回来了，还没来得及喜悦，新的坑出现了：加载内核时报错invalid magic number you need to load the kernel first

  8. 内核加载失败，判断是备份出来的boot分区内的内核文件也受到波及损坏了，痛定思痛，下定决心：直接删除重建boot分区+重装内核+重建引导

    # fdisk删除原boot分区，n新建第一块分区表
# fdisk a，给新建的分区表打上BOOT标记
# 保存分区表，mkfs.xfs给boot重新格式化
# 挂载到/mnt/sysimage/boot下，准备重装内核
​
# 通过chroot，uname -a确定恢复的内核版本
# 重装内核
rpm -ivh /run/install/repo/Packages/kernel-3.10.0-1160.el7.x86_64.rpm --root=/mnt/sysimage/ --force
​
# 内核安装完成后，重复第6步的命令进行引导修复

  9. 重启服务器，OS引导正常，内核启动顺畅，熟悉的登录页面又回来了，成就感+1