我试图在 Deepin Linux 20 上安装需要更高版本 GLIBC 的软件。我发现关于如何做到这一点的 Stack Overflow 问题并按照一些答案的说明进行操作。现在，每当我尝试启动计算机时，Deepin 徽标都会显示并冻结（它应该是动画的）。计算机不响应任何击键，包括隐藏徽标和显示文本输出的击键。
如果我什至无法启动到终端，如何检查启动日志或撤消此更改？我可以启动到另一个系统，但不确定如何离线修复主系统。
在按照评论中的建议删除启动选项后quiet，splash我现在有了有关该问题的详细信息。
在底部，我有一行：
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007f00 ]---
我还有一行我认为导致内核恐慌的行：
/init: line 83: wait-for-root: not found
另一行详细说明了内核恐慌：
/sbin/init: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
答案1
（我意识到这些说明可能感觉像是突然被扔进游泳池的深处，沉没或游泳。如果这些说明对您来说似乎不够详细，我强烈建议您寻找具有更多 Linux 经验的人在你附近，并尝试与他们一起修复它。）
如果您没有可以恢复的备份，最简单的恢复方法可能是手动提取并放回旧库，一旦系统可运行 chroot，请使用包管理器降级任何更新的库包。
.deb可以使用 手动提取软件包ar x package.deb，这会产生三个文件：control.tar.xz包含安装前/后安装/删除脚本（如果有）和软件包管理器的元数据，并data.tar.xz包含实际文件，使用相对路径打包，如果您提取在data.tar.xz系统根目录中，文件将自动解压到其预期位置。
在这种特定情况下，您将启动到备用系统，挂载损坏的主系统的根文件系统，然后data.tar.xz从主系统根目录的目录中的相应 glibc 包中提取该文件系统。换句话说，如果将主根文件系统挂载到/mnt，您将data.tar.xz使用以下内容提取：
cd /mnt
tar xvf /where/ever/data.tar.xz
您还应该阅读/var/log/dpkg.log主系统的（即，/mnt/var/log/dpkg.log当主操作系统的根文件系统安装到时/mnt）。该文件应该有类似这样的行
<timestamp> upgrade <package name>:<arch> <old version> <new version>
这将告诉您在开始不幸的升级尝试之前到底有哪些软件包版本，以及您的 glibc 升级是否导致其他库软件包也升级：如果确实如此，您可能也必须恢复这些软件包。
一旦恢复了必要库的正确版本，您就可以通过 chroot 来测试主系统。假设主系统的根文件系统安装到/mnt：
mount --rbind /dev /mnt/dev
mount --rbind /sys /mnt/sys
mount -t proc proc /mnt/proc
chroot /mnt
在这些命令之后，您输入 chroot 命令的 shell 会话现在应该能够在主系统的环境中运行，本质上就像主系统以最小方式运行一样（“单用户模式”）。您应该运行ldd /sbin/init并验证它是否报告没有丢失库，并且可能对任何重要的系统二进制文件执行相同的操作。
此时，您还应该能够使用包管理器来小心地恢复失败的升级，因此包管理器对当前安装的文件的想法将再次符合现实（这样您以后就不会出现依赖问题）。如果dpkg.log指示在升级过程中删除了软件包，您可能应该重新安装删除的软件包，以便可以恢复到升级前存在的确切配置。
如果您在升级尝试后执行了手动操作update-initramfs -u，或者主安装initrd.img-<kernel version>中的文件时间戳/boot表明它们在升级尝试期间已更新，则您可能需要update-initramfs -u -k <kernel version>在 chrooted shell 会话中运行以重建主系统的 initramfs 再次带有良好的库。
如果您设法恢复在 glibc 升级尝试中更新的所有库包，您的主系统现在应该回到升级前的状态，并且可以再次启动。
更新 GLIBC 而不同时升级发行版的其余部分通常是一个坏主意：GLIBC 通常是系统上基本上所有可执行二进制文件所依赖的基石，并且许多库文件也将依赖于它。
发行版构建者选择了一组核心系统库版本（包括 GLIBC），并将它们构建和配置为能够很好地协同工作。如果您将这些库中的任何一个替换为用于其他发行版（甚至是该版本的另一个主要版本）的包，相同的分布），这些相互依赖关系将处于危险之中，并且事情可能无法按预期运行，或者根本无法运行（正如您所发现的）。