centos 7.9 重启失败 显示 i8042: no controller found 问题的解决

某台正在运行CentOS7 .9 的生产服务器突然出现了SSH连接中断的情况，经过重启操作未能解决，反而引发了i8 04 2 :nocontrollerfound的错误，使服务器陷入无法启动的窘境。
面对这一突发状况，我们首先尝试借助Ubuntu启动盘来启动服务器，幸运的是服务器成功启动了，并且检查磁盘空间后发现一切正常，数据丢失的风险得以排除。
随后我们尝试使用CentOS启动盘进行系统修复，但遗憾的是，这一操作并未带来预期的效果。
在尝试使用grub启动系统时，我们发现所有的修复选项都无法进入系统。
在紧急关头，我们决定再次使用Ubuntu启动盘，并挂载系统盘进行数据恢复操作。
不过，在运行了一段时间后，磁盘出现了问题。
所幸的是，我们及时执行了xfs_repair-L命令，并成功地恢复了数据。
第二天，我们再次尝试以单机模式启动服务器。
在执行chroot操作时，我们发现问题的关键在于/lib6 4 目录下的libc.so.6 核心文件版本不匹配。
为了解决这个问题，我们安装了相同版本的CentOS7 .9 ，并利用U盘将所需文件复制到目标服务器，同时备份了原有的/usr/lib6 4 /目录内容，最终chroot操作顺利完成。
至此，我们可以基本确定问题的根源在于操作系统核心库文件的损坏。
由于服务器的RAID1 配置，我们可以在另一台系统上进行同样的操作，以确保服务器的启动成功。
此后，其他应用系统的恢复工作也变得相对简单，主要涉及数据和配置文件的重新加载。

CentOS7.9安装mysql-8.0.36踩坑小记

最近在测试服务器上安装MySQL 8 .0.3 6 版本时，遇到了一些小波折，本以为很简单，结果却花了不少时间解决。
下面记录一下安装过程中踩过的坑。

1 . 排错记录 执行./mysqld --initialize命令初始化MySQL时，提示某些共享库（so文件）版本过低。
检查后发现libstdc++.so.6 库缺少GLIBCXX_3 .4 .2 0等版本，于是从其他服务器上拷贝了6 .0.2 5 版本的libstdc++.so进行替换，初始化成功，但报错并未完全消失。
在尝试替换其他so文件时，发现系统基础命令都无法执行，提示找不到libc.so.6 库文件。
经过排查，发现是glibc库文件损坏了，好在还有SSH连接，经过一番操作终于恢复了正常。
经过反思，意识到问题在于glibc和gcc版本过低。
尝试更新glibc，发现已经是最新版，于是怀疑是yum源太老了。
更换yum源或使用源码编译安装均未解决问题。
回顾安装包，发现下载的是glibc2 .2 8 版本的安装包，而MySQL要求glibc版本在2 .2 8 及以上。
查看MySQL官网后，发现提供了不同glibc版本的安装包，低版本的Linux发行版可以使用低版本的安装包。
查阅资料得知，CentOS7 .9 系统默认的glibc版本是2 .1 7 ，glibc是Linux系统中非常重要的库，几乎所有Linux程序都依赖于它。
因此，在生产服务器上进行升级时应谨慎。
建议在CentOS7 .9 上安装MySQL时，使用glibc版本为2 .1 2 或2 .1 7 的安装包。

2 . 全面认识MySQL安装包 这次排错经历让我对MySQL安装包有了更深入的了解。
以Linux系统MySQL 8 .0.3 6 版本为例，官网提供了三种处理器架构的安装包：x8 6 _3 2 -bit、x8 6 _6 4 -bit和ARM_6 4 -bit。
服务器通常使用x8 6 _6 4 -bit架构，可以通过uname -m或arch命令查看。
根据glibc版本，官方提供了glibc2 .2 8 、glibc2 .1 2 和glibc2 .1 7 三种安装包。
对于特定的glibc版本及处理器架构，MySQL官方提供了三种不同的安装包，包括用于生产环境的MySQL服务器二进制文件、测试套件和集成包。

总结：这次小插曲让我重新认识了MySQL安装包。
从MySQL 8 .0.3 3 版本开始，官方才提供基于glibc2 .2 8 的安装包。
安装MySQL时，应根据操作系统及glibc版本选择匹配的安装包，以避免初始化失败。