你能帮我解决这个问题吗？
我“意外地” rpm -e glibc.x86_64 库并导致我的 VPS 无法使用，因为所有命令都会引发以下错误之一：
[root@panel lib64]# yum
bash: /usr/bin/yum: /usr/bin/python: bad interpreter: No such file or directory
[root@panel lib64]# ls
bash: /bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
如果以下任何一项可以有所帮助：
1）我仍然与 shell 保持连接
2）我无法启动恢复，因为它是一个远程 VPS
3）仍安装有 i686 glibc
4)我的主目录中有 x86_64 版本的 .rpm 文件。
5)有/lib/ld-linux.so.2，我可以以某种方式让系统使用那个吗？
6) 我有一个 /opt/glibc-2.14/lib/ld-linux-x86-64.so.2，我可以执行带有前缀的命令，但关键的命令，如 rpm2cpio 或 wget 会引发共享对象错误。
我可以使用静态命令或在路径中放置其他库或任何其他方式来解决这个问题吗？
谢谢大家。
答案1
由于您删除了链接器，因此无法执行任何其他程序。您真正拥有的只是正在运行的 bash shell。没有 wget，没有 cp。
这可以有两种方式。常规备份恢复和重建此实例所做的操作，现在启动此过程。或者非常有创意地从中提取数据并重新启用 glibc。
需要复制至少与 EL6 的 glibc 版本 2.12 一样新的二进制文件。仅使用 bash。理论上，仅使用内置程序即可。在其他主机上，使用 rpm2cpio 提取，使用 /dev/tcp/ 将它们下载到损坏的主机。实际上，这很丑陋，而且很难实现功能。需要使用未加密的协议，并手动输入请求。
相反，将虚拟机磁盘映像（快照）附加到其他正常运行的 EL6 虚拟机，并在那里对其进行操作。将其挂载到某个地方，比如 /mnt。使用 yum 恢复 glibc，但将其安装在损坏的根目录中：
yum --installroot=/mnt install glibc
安装后备份所有重要数据。将其再次移至损坏的实例并启动。
现在进行事后分析。
修复损坏的实例对于恢复数据很有用，但可能行不通。备份仍然是必须始终有效的恢复方法。确保重建和恢复是可能的。
您必须使用它rpm -e --nodeps才能进入这种情况。绝不这样做。依赖关系的存在是因为软件包彼此需要。glibc 的 rpm 软件包描述 ( rpm -qi glibc) 提到了它的重要性，尽管公平地说，在很多文字之后：
这个特定的软件包包含最重要的一组共享库：标准 C 库和标准数学库。如果没有这两个库，Linux 系统将无法运行。
如果您无法使用 yum 解决 rpm 事务，请停止。质疑软件包数据库的完整性。质疑 yum 存储库的合理性，它曾让某些人认为--nodeps这是一个好主意。
答案2
我认为您可以使用现有的 i686（32 位）工具链构建 glibc.x86_64 的源代码。下载源代码并解压，然后按照 INSTALL 说明进行操作。当您运行 configure 时，它将仅检测 32 位，并且应该从那里恢复。
我还发现在 centOS 上你可以执行
yum update kernel
# reboot
yum update
（从https://geeksterminal.com/how-to-install-glib-glibc/1392/）
小型自卫队
答案3
我建议下载glibc x86_64.rpm通过 wget 打包，然后使用转速命令。