Ubuntu 20.04.6 LTS系统/lib目录异常引发依赖缺失，求修复方案及原因排查

问题背景 #

我有一台Ubuntu 20.04.6 LTS服务器，突然出现一系列异常：

• SSH连接被拒绝，提示/bin/bash: No such file or directory
• 重启机器触发内核panic，关键报错片段：

  Begin: Running /scripts/init-bottom ... mkdir: can't create directory '/root/lib/modules': Read-only file system

  [...]

  run-init: can't execute '/sbin/init', No such file or directory

  [...]

  run-init, can't execute '/etc/init': Permission denied

  [...]

  Kernel panic not syncing: Attempted to kill Init! exitcode-Ox00000100

已排查与临时修复操作 #

通过Live USB启动并挂载根磁盘后发现：

• /sbin/init存在，但它是软链接，指向的/lib/systemd/systemd缺失
• 正常机器中/lib是指向usr/lib的软链接，但我的机器里/lib是一个目录，仅包含x86_64-linux-gnu文件夹

于是我做了以下操作：

1. 备份原/lib目录
2. 将/lib替换为指向usr/lib的软链接

现在机器可以正常重启并通过SSH登录，但执行sudo apt update和sudo apt upgrade时触发新错误：

/usr/bin/python3: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by /usr/bin/python3)
/usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /usr/bin/python3)
/usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /usr/bin/python3)
/usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /usr/bin/python3)

补充信息（Edit 1） #

原/lib/x86_64-linux-gnu目录下的文件极少：

$ ls [...]/lib/x86_64-linux-gnu/
libexpat.so.1  libexpat.so.1.8.7  libhistory.so.8  libhistory.so.8.1  libreadline.so.8  libreadline.so.8.1

对比备份目录与当前目录的差异：

$ diff [...]/lib/x86_64-linux-gnu /lib/x86_64-linux-gnu | grep -v "Only in /lib/x86_64-linux-gnu"
Binary files [...]/lib/x86_64-linux-gnu/libexpat.so.1 and /lib/x86_64-linux-gnu/libexpat.so.1 differ
Only in [...]/lib/x86_64-linux-gnu: libexpat.so.1.8.7
Binary files [...]/lib/x86_64-linux-gnu/libhistory.so.8 and /lib/x86_64-linux-gnu/libhistory.so.8 differ
Only in [...]/lib/x86_64-linux-gnu: libhistory.so.8.1
Binary files [...]/lib/x86_64-linux-gnu/libreadline.so.8 and /lib/x86_64-linux-gnu/libreadline.so.8 differ
Only in [...]/lib/x86_64-linux-gnu: libreadline.so.8.1

另外，SSH登录时还会弹出以下警告：

/usr/bin/xauth: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /usr/bin/xauth)
/usr/bin/xauth: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /usr/bin/xauth)
/usr/bin/xauth: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /lib/x86_64-linux-gnu/libX11.so.6)
/usr/bin/xauth: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /lib/x86_64-linux-gnu/libX11.so.6)
/usr/bin/xauth: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /lib/x86_64-linux-gnu/libXau.so.6)
/usr/bin/xauth: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /lib/x86_64-linux-gnu/libbsd.so.0)
/usr/bin/xauth: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /lib/x86_64-linux-gnu/libmd.so.0)

求助问题 #

1. 不重装系统的前提下，如何修复当前的依赖问题？
2. 可能是什么原因导致了这次系统异常？

修复方案建议 #

咱们先从核心库文件的问题入手，毕竟现在所有报错都是因为GLIBC这类基础系统库出了问题，得先把它们拉回正常状态。

1. 用Live USB修复库文件

你之前已经用过Live USB了，这次再重复一次操作：

• 启动Live USB，把根分区挂载到/mnt（记得替换成你实际的分区，比如/dev/sda1）
• 先把当前/mnt/lib/x86_64-linux-gnu备份好，避免操作失误无法回滚
• 去Ubuntu官网下载20.04.6的ISO镜像，挂载后提取里面casper/filesystem.squashfs中的完整lib/x86_64-linux-gnu目录，复制覆盖到你挂载的根分区对应位置；或者找一台同版本的正常Ubuntu x86_64机器，把它的/lib/x86_64-linux-gnu完整复制过来

2. 进入Chroot环境强制重装核心包

如果Live挂载后，咱们可以进入chroot环境操作，这样更贴近真实系统的运行环境：

sudo mount /dev/sdXn /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt

进入chroot后，强制重装最核心的系统包，把损坏的库和程序修复：

apt-get install --reinstall libc6 libm-dev python3-minimal python3 systemd
apt-get install --reinstall ubuntu-minimal ubuntu-standard

安装完成后输入exit退出chroot，重启机器试试。

3. 修复APT自身的依赖问题

如果chroot环境里APT还是报错，先清理缓存再修复依赖链：

apt-get clean
apt-get update --fix-missing
dpkg --configure -a
apt-get -f install

这几步能帮你把APT的状态拉回正常，方便后续的包管理操作。

可能的原因分析 #

从你遇到的一系列问题来看，大概率是以下几种情况：

• 磁盘文件系统损坏：最开始重启时出现的“Read-only file system”是关键信号，说明磁盘可能有坏道或者文件系统出错，导致/lib下的核心文件被损坏或丢失。你可以在Live环境下先卸载根分区，再用fsck /dev/sdXn检查修复文件系统。
• 误操作：会不会是之前执行了错误的命令？比如误删了/lib下的文件，或者不小心把/lib的软链接改成了目录？这种情况在服务器日常操作中偶尔会发生。
• 软件包升级异常：之前的APT升级可能中途中断（比如断电、网络故障），导致核心库文件被不完整地替换，直接破坏了系统的依赖结构。
• 恶意攻击：这个概率相对低一些，但也不能排除——如果服务器权限管控不够严格，恶意程序可能篡改系统核心库文件，不过这种情况通常会伴随其他异常痕迹。

备注：内容来源于stack exchange，提问作者LemmeTestThat