服务器磁盘损坏丢失CentOS 7.9操作系统起不来？？！！

两台部署EBS的服务器安装了CentOS7.9的操作系统，进行应用运行环境配置后重启，重启失败，操作系统起不来，提示找不到启动设备。

诊断过程

1、操作系统层问题

服务器原厂硬件工程师诊断了操作系统的启动情况，对主机进行尝试启动操作系统后，确认不是硬件层面的问题，为操作系统层问题，引导失败，建议修复引导，如修复无果，建议重装操作系统。

2、更换启动模式方法

联系另外第三方操作系统工程师提供远程诊断支持，对主机尝试BIOS和UEFI两种模式启动操作系统，都启动失败。找了同批购买的第三台服务器重启，配置相同，一样问题，重启不起来。操作系统工程师通过对第三台主机进行启动尝试，因识别不到磁盘，判断无操作系统存在，已丢失。三台服务器为通型号，操作配置都一样，唯一的区别就是，第三台的启动分区放在第二块设备sdb上。

什么？？！！好好的服务器，才购买回来不久欸，硬件这么不抗打嘛！？

3、重装操作系统修改参数并重启主机

通过重装第三台主机的操作系统，并进行IP配置，重启后操作系统可成功启动。再进行关闭selinux和透明大页两项需要重启操作系统生效的内核参数，并重启主机

vi /etc/selinux/config

SELINUX=disabled

vi /etc/default/grub

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet transparent_hugepage=never "

修改以上两项参数后重启，第三台主机重装后的系统可以正常重启。

4、引导配置问题

通过以上，对比第三台服务器重装操作系统后修改配置，并重启成功，vi /etc/default/grub与grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg均涉及到了引导配置的修改，能重启成功，可以推断前面两台应用服务器的引导配置很可能发生了异常修改。经对比发现：

使用操作系统的iso镜像文件通过救援模式，进入操作系统查看，两台应用服务器的启动引导分区下的/boot/efi/EFI路径下多出了redhat目录，并且/boot/efi/EFI/centos目录下丢失了类似BOOT.CSV、BOOTX64.CSV、shim.efi和shimx64.efi等文件。

##CentOS 7.9不正常的引导配置/boot/efi/EFI/centos的文件内容

##CentOS 7.9引导配置被篡改后的路径/boot/efi/EFI/redhat

确定启动引导丢失的情况下，通过救援模式进入系统，一直尝试修复CentOS 7.9操作系统的引导配置，却经多种方法多次尝试生成新的引导配置并重启，均无效，修改方法如下：

5、系统启动引导顺序问题

通过efibootmgr工具，可以查看到，首先是使用0003，即CentOS标签引导系统操作系统。

两台应用服务器的主机引导顺序

（当前使用救援模式，使用的是DVD文件启动）

# efibootmgr

BootCurrent: 0005

BootOrder: 0003,0000,0004,0005

Boot0000* Embedded NIC 1 Port 1 Partition 1

Boot0001* Hard drive C:

Boot0002* BRCM MBA Slot 0400 v21.6.3

Boot0003* CentOS

Boot0004* Virtual Floppy

Boot0005* Virtual CD/DVD

MirrorStatus: Platform does not support address range mirror

DesiredMirroredPercentageAbove4G: 0.00

DesiredMirrorMemoryBelow4GB: false

重装系统后的第三台服务器的引导顺序

# efibootmgr

BootCurrent: 0003

BootOrder: 0003,0000,0004,0005

Boot0000* Embedded NIC 1 Port 1 Partition 1

Boot0001* Hard drive C:

Boot0002* BRCM MBA Slot 0400 v21.6.3

Boot0003* CentOS

Boot0004* Virtual Floppy

Boot0005* Virtual CD/DVD

MirrorStatus: Platform does not support address range mirror

DesiredMirroredPercentageAbove4G: 0.00

DesiredMirrorMemoryBelow4GB: false

想采取以下方法，生成Oracle Linux的引导标签，但未使用该方法去修复引导问题并启动操作系统。因为服务器本身安装的是CentOS7.9的操作系统，如果生成Oracle Linux引导标签，则会以Oracle Linux形式启动操作系统，就乱了。

efibootmgr --create --disk /dev/sda --part 1 --label "RedHat" --loader /boot/efi/EFI/redhat/shimx64.efi

6、操作系统的内核问题

在操作以上尝试方案的时候，同时发现，在/boot目录下，发现有两个内核的vmlinuz文件，如下：

bash-4.2# grubby --info=ALL

在执行grub2-mkconfig -o /boot/efi/EFI/centos/grub .cfg的时候，还报出 cat : /etc/oracle-release : No Such file or directory的提示。

在正常的CentOS系统中执行这个命令，应该是读取/etc/centos-release或者/etc/redhat-release文件，而不会去读取/etc/oracle-release文件的，本身也不存在该文件，因此，就怀疑目前的CentOS 7.9操作系统已经被污染，或者进行过内核调整（升级）。

尝试history查看历史执行命令，是否有内核变更的操作，发现有修改介质相应文件的内容，如：rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle和yum install oracle-ebs-server-R12-preinstall操作命令，看到这是配置EBS程序运行环境的操作内容。

使用rpm查看内核，发现CentOS 7.9的操作系统里确实存在两个版本的内核

bash-4.2# rpm -qalgrep kernel

尝试删除Oracle Linux 7.6的内核，发现该内核被oracle-ebs-server-R12-preinstall需要，因此证实，系统确实发生过内核变更。

也尝试删除grub2-efi相关工具，重新安装grub2-efi，重新生成CentOS 7.9的引导配置，无法安装grub2-efi和shim，报shim冲突，操作系统依然重启失败。

yum reinstall grub2-efi shim

grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

到了这里，就决定删除Oracle Linux 7.6的内核以及相关工具包。

操作系统启动解决方法

计划将内核kernel-uek-4.14.35-2847.536.5.e17uek.x86_64.然后重装内核kernel-3.18.8-1168.71.1.e17.x86_64，重新生成centos 7.9的引导配置。

1、删除oracle-ebs-server-R12-preinstall包

rpm -e oracle-ebs-server-R12-preinstall

2、删除kernel-uek-4.14.35-2847.536.5.e17uek.x86_64

rpm -e kernel-uek-4.14.35-2847.536.5.e17uek.x86_64

3、删除与安装grub2-efi和shim发生冲突的工具包

4、删除CentOS 7.9对应内核相关的vmlinuz-3.18.0-1168.el7.x86 64文件

通过清理/boot目录下的所有内容方式，清理CentOS 7.9内核相关文件

cd /boot; mv * /root/bootbackup

5、使用ISO文件以救援模式登陆操作系统并挂载镜像

cat >/etc/yum.repos.d/CentOS-Media.repo
[c7-media]
name=CentOS-$releasever - Media
baseurl=file:///mnt/
gpgcheck=1
enabled=1
gpgkey=file:///mnt/RPM-GPG-KEY-CentOS-7

6、重装内核kernel-3.18.8-1168.e17.x86_64修复/boot启动分区

7、修复/boot/efi 分区，恢复 GRUB2引导配置

yum install grub2-efi shim

grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

到了这里，CentOS 7.9的内核已经重装完毕，对应的引导配置也修复完成。

8、提出系统到救援模式并重启系统

到此，CentOS 7.9的操作系统已重启成功。

从上面的操作可以看到，重新修复CentOS 7.9操作系统的引导配置，非常曲折。在Oracle Linux内核的存在下，就无法直接修复，需要先删除与Oracle Linux内核相关的工具包，再重新安装CentOS 7.9系统的的内核。

总结

本次两台应用服务器操作系统重启失败，是因为操作系统启动引导配置被篡改，导致系统在正常启动过程，无法读取启动引导文件。引导配置被篡改的原因，则是因配置EBS运行环境，需要安装oracle-ebs-server-R12-preinstall这个预安装包，安装该包有依赖kernel-uek-4.14.35-2847.536.5.e17uek.x86_64、fwupdate和shim等相关配置，安装了该Oracle Linux 7.6系统对应的内核后，系统在UEFI模式下，以最新安装的内核重新生成一份引导配置文件，存放在/boot/efi/EFI/redhat目录下，与原来安装好CentOS 7.9操作系统默认的路径/boot/efi/EFI/centos发生了变化，也导致了后者路径下的BOOT.CSV、BOOTX64.CSV、shim.efi和shimx64.efi等文件被清理，取而代之地生成fwup*开头的文件。

另外一个原因，则是在引导配置内容发生了路径改变之后，引导挂载点为/boot/efi/EFI/redhat情况下，没有对应类似”Oracle Linux”的引导标签，默认还是先找”CentOS”这个引导标签，从而启动的时候，无法引导到/boot/efi/EFI/redhat读取最新的引导配置内容。

因为服务器的CentOS 7.9操作系统里有两个内核，一个是centos的内核，另一个则是Oracle Linux的内核。其实如果单纯为了能够把操作系统启动起来，根据efibootmgr的指示，一个方法是可以通过创建Oracle Linux引导标签，使用OracleLinux的内核来启动操作系统，完全是可以了。

意向不到，安装EBS预安装包过程，由于依赖关系，会自动把Oracle Linux的内核安装上去，在UEFI模式下，还以最新的内核生成了相应的引导配置。

思考

留给大家一个思考问题，就是为什么操作系统工程师诊断说第三台服务器的操作系统丢失了，救援模式也识别不到磁盘，与另外两台应用服务器的情况不一样。（提示一个：第三台服务器的启动引导分区在第二块磁盘上/dev/sdb）

答案：（在底下）

（可能是因为引导分区放在第二块盘/dev/sdb，而使用ISO镜像进入救援模式默认找引导分区到第一块盘/dev/sda上找，找不到就认为没有磁盘信息。救援模式下可通过mount /dev/sdX /mnt/sysimage方式手动挂载，让其识别启动引导分区和/根分区，进而登陆系统）