用另一个更新的libc.so.6替换符号链接libc.so.6后如何恢复？

Question

如何在用另一个更新的libc.so.6替换符号链接libc.so.6后恢复？

我查看了以下链接 How to recover after deleting the symbolic link libc.so.6?

问题是我用另一个libc.so.6

更新了文件

有没有其他方法可以在没有knoppix的情况下出行？我不能做rm，cat，mv ..等只有ldconfig但我甚至无法替换文件因为链接在那里。我怎样才能删除这个文件？

Answer 1

如果你已经没有任何准备就陷入了这样的问题，那么，如果没有外部救援启动，你已经很有可能无法恢复。对于将来的实验，您可以使用以下准备之一：

• 在一个单独的终端中启动mc（Midnight Commander）或其他具有嵌入式文件系统操作实现的复杂shell工具。
• 创建“救援”工具集（如/ rescue下的FreeBSD中的一个）。
• 启动任何脚本语言的REPL工具（Python，Ruby等）;也许某些导入（如Python中的sys，os，os.path）应在危险步骤之前调用。

（对于所有此类操作，在实验之前，关键系统路径的备份副本是一种很好的方式。）

但是一些小的动作可以在没有工作libc的裸shell中完成。在大多数交互式shell中，如bash，都有一些有用的内置函数，因此您可以：

• echo *，echo /lib/*代替ls
• echo -n >$file让它变空;对于ldconfig，这有效地将其从库中删除，因为ldconfig仅在其缓存中列出正确识别的库;
• 如果printf是shell内置的（就像现代bash），您可以使用它和shell重定向创建任何二进制文件;这是非常缓慢和错字，但仍然是一个机会。

接下来，在每次外部命令调用之前，为正确的libc版本设置LD_PRELOAD允许用另一个库替换任何库;例如LD_PRELOAD=/lib/libc-2.11.3.so ls将使用/lib/libc-2.11.3.so中找到的所有外部符号运行ls，并从已安装的名称中覆盖其名称。 （在导出规范之前不要尝试使用env！它会因破坏的libc而失败，并且对于像bash这样的任何B组shell都不需要。）使用/ lib的备份副本导出LD_LIBRARY_PATH， / usr / lib允许从主要库目录损坏的大多数问题中解脱出来。 （注意，这个方法在您链接的问题中有描述。您真的尝试过吗？）

我希望可以在此列表中添加其他黑客方法。

P.S。这个问题不应该转移到ServerFault吗？