记一次glibc导致的系统崩溃

最新推荐文章于 2025-02-21 09:38:26 发布

原创最新推荐文章于 2025-02-21 09:38:26 发布 · 3.4k 阅读

5 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#linux #运维 #服务器 #glibc

本文记录了一次由于错误安装软件导致glibc关键库文件被覆盖，进而引发系统崩溃的问题。修复过程中涉及到了使用live boot系统安装盘挂载硬盘、恢复链接文件、重新安装头文件等步骤。提醒读者在安装系统软件时务必谨慎，避免破坏系统文件。

记一次glibc导致的系统崩溃

安装了某个软件，提示缺少glibc2.29，于是下载源码编译安装，根据网上非权威不可靠博文，使用--xxx=/usr选项导致系统的关键库文件链接被覆盖，所有依赖glibc的命令均无法使用。

ldd `which cat`
	linux-vdso.so.1 (0x00007ffec49a0000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3e56e67000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3e57461000)

可以看到很多基本命令（除了shell内置命令外）都是依赖libc.so.6这个文件的

大多数程序都是动态链接的。当操作系统加载一个动态链接的应用程序时，它必须找到并加载它执行该应用程序所依赖的动态库。在linux系统上，这份工作由ld-linux.so.2处理。即需要用到动态库的命令都需要/lib64/ld-linux-x86-64.so.2。

解决方案

准备一个live boot系统安装盘，进入try ubuntu without install

挂载本地要修复的系统所在硬盘，进入并修改链接文件

（友情提醒，如果能正常挂载，此时对于关键业务要先备份文件）

ln -sf /lib/x86_64-linux-gnu/ld-2.27.so /lib64/ld-linux-x86-64.so.2
ln -sf /lib/x86_64-linux-gnu/libBrokenLocale-2.27.so /lib/x86_64-linux-gnu/libBrokenLocale.so.1
ln -sf /lib/x86_64-linux-gnu/libc-2.27.so /lib/x86_64-linux-gnu/libc.so.6

ln增加-f选项表示强制覆盖之前的链接文件

修复系统关键库的软连接后终于可以正常开机、使用命令了，但是如果进行哪怕最简单的helloWord编译，都会出现报错

/usr/include/stdint.h:44:9: error: ‘__int_least16_t’ does not name a type; did you mean ‘__int16_t’?
 typedef __int_least16_t int_least16_t;
         ^~~~~~~~~~~~~~~
         __int16_t
/usr/include/stdint.h:45:9: error: ‘__int_least32_t’ does not name a type; did you mean ‘__int32_t’?
 typedef __int_least32_t int_least32_t;
         ^~~~~~~~~~~~~~~
         __int32_t
/usr/include/stdint.h:46:9: error: ‘__int_least64_t’ does not name a type; did you mean ‘__int64_t’?
 typedef __int_least64_t int_least64_t;
         ^~~~~~~~~~~~~~~
         __int64_t
/usr/include/stdint.h:49:9: error: ‘__uint_least8_t’ does not name a type; did you mean ‘__uintmax_t’?
 typedef __uint_least8_t uint_least8_t;
         ^~~~~~~~~~~~~~~
         __uintmax_t
/usr/include/stdint.h:50:9: error: ‘__uint_least16_t’ does not name a type; did you mean ‘__uint16_t’?
 typedef __uint_least16_t uint_least16_t;
         ^~~~~~~~~~~~~~~~
         __uint16_t
/usr/include/stdint.h:51:9: error: ‘__uint_least32_t’ does not name a type; did you mean ‘__uint32_t’?
 typedef __uint_least32_t uint_least32_t;
         ^~~~~~~~~~~~~~~~
         __uint32_t
/usr/include/stdint.h:52:9: error: ‘__uint_least64_t’ does not name a type; did you mean ‘__uint64_t’?
 typedef __uint_least64_t uint_least64_t;
         ^~~~~~~~~~~~~~~~
         __uint64_t

显然这是库文件报错，应该是之前安装glibc时覆盖了原来的头文件

比如报错的头文件之一是/usr/include/x86_64-linux-gnu/bits/stdio.h

使用dpkg搜索含有该文件的软件包

dpkg --search  /usr/include/x86_64-linux-gnu/bits/stdio.h

libc6-dev:amd64: /usr/include/x86_64-linux-gnu/bits/stdio.h

于是重新安装头文件

sudo apt install --reinstall libc6-dev -y

问题解决！

总结，安装系统软件时一定要非常小心，因为很容易把系统弄坏，尽量从官方来源conda、pip、apt、snap、rpm安装软件，并尽可能使用最低安装权限，以防止破坏系统文件。