☰

当我删除 /lib64 时没有命令执行

tag-icon • tag-icon command-line permissions directory
当我删除 /lib64 时没有命令执行

rm -rf *当我位于lib64其中的目录中时，我执行了命令。

（通过评论/答案的问题是，我删除了ld-linux-x86-64.so.2并且里面没有临时的/var/lib64）

（我有 busybox）

然后我无法执行大多数 bash 命令，例如ls，bash。当我尝试执行它们时，我看到：

bash: /usr/bin/bash: No such file or directory

或者

bash: /usr/bin/ls: No such file or directory

但许多命令都能正常工作echo，例如cd

许多命令可以运行但不能正常工作，例如which显示以下错误：

bash: /usr/bin/which: /bin/sh: bad interpreter: No such file or directory

当我/usr/bin执行cd命令时，cd $file它会引发错误。例如，当我执行cd /usr/bin/ls它时向我显示：

bash: cd: /usr/bin/ls: Not a directory

或者

bash: cd: /usr/bin/bash: Not a directory

当我执行'cd /usr/bin/bash'时

当我打开终端时，显示以下消息：

There was an error creating the child process for this terminal
Failed to execute child process “/bin/bash” (No such file or directory)

（有两个选项：首选项、重新启动）

我$PATH可以/home/$me/.sdkman/candidates/springboot/current/bin:/home/$me/.cargo/bin:/home/$me/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/opt/grade/gradle-7.0.2/bin:/opt/apache-maven-3.8.1/bin:/home/$me/v8/depot_tools:/home/$me/.config/composer/vendor/bin 使用浏览器或/和之前启动的程序。但我无法再次启动它们。

我打开了一个终端选项卡，其中有前面提到的一些命令、浏览器和文档阅读器。它们可以工作，但无法再次启动。

无法理解的是以下错误：

bash: /usr/bin/which: /bin/sh: bad interpreter: No such file or directory

答案1

/usr/bin/which是一个 shellscript：

~$ cat /usr/bin/which
#! /bin/sh
set -ef

if test -n "$KSH_VERSION"; then
        puts() {
                print -r -- "$*"
        }
else
        puts() {
                printf '%s\n' "$*"
        }
fi
...
...
...

这只是脚本的前几行，它要长得多。但我们只需要看一下第一行，即

#! /bin/sh

/bin符号链接到/usr/bin，因此/bin/sh指向/usr/bin/sh。

似乎您删除了必要的系统文件，这就是命令对您不起作用的原因。 cd并且echo不是命令而是 shell 内置命令，这就是它们仍然有效的原因。

我们无法告诉您删除了哪些文件，因为我们不知道您在哪个目录中发出了 -command rm -rf *。也许可以从实时会话中复制文件并让系统恢复工作，但您必须自己找出丢失了哪些文件。否则请重新安装。

提示：在我的系统中只有一个文件/lib64：

~$ ~$ ~$ ls -la /lib64/
total 8
drwxr-xr-x  2 root root 4096 Oct 13 03:37 .
drwxr-xr-x 14 root root 4096 Oct 13 03:37 ..
lrwxrwxrwx  1 root root   42 Sep 28 08:38 ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

这是一个符号链接，只需重新创建符号链接就足够了，但由于命令不再起作用，您必须从实时会话中执行此操作。

答案2

在我的 ubuntu 20.04 系统上，/lib64/ 目录仅包含一个符号链接：

ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so

如果您不小心删除了它，几乎所有命令都会失败并出现以下错误：

# ls -al
-bash: /bin/ls: No such file or directory

您可以使用以下命令恢复符号链接：

cd /lib64/
LD_LIBRARY_PATH=ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/ld-2.31.so /bin/ln -s /lib/x86_64-linux-gnu/ld-2.31.so ld-linux-x86-64.so.2

答案3

/lib64 目录包含几乎所有可执行文件都需要的共享库以及 ld-linux 解释器。它们在共享库中共享通用代码，而不是将其复制到每个可执行文件中。shell 脚本之类的东西可能也无法工作，因为它们运行的​​命令可能存在问题，并且需要的解释器（如 bash）也可能存在问题。

可用的命令要么内置于您的 shell 中（例如cd和echo），要么是静态链接的。busybox 命令设计为静态链接，并且内置了许多命令的缩写版本。

损坏 /lib64 等系统目录对 unix 系统来说几乎是致命的。要恢复功能，您需要恢复丢失的文件。执行此操作的选项包括：

  • 从备份恢复
  • 重新安装它们来自的 deb 文件
  • 从另一个具有相同操作系统版本的相同系统复制文件
  • 从实时安装磁盘启动并使用实时磁盘上的工具替换丢失的文件
  • 完全重新安装操作系统（先备份数据）

也许可以进行部分恢复，然后使用类似的东西dpkg -V来获取库存文件中不同或缺失的内容列表，并使用重新安装一些损坏的软件包apt install --reinstall。不幸的是，dpkg 及其使用的工具都依赖于共享库，因此至少在关键库出现之前，这些库必须存在才能有所帮助。

遗憾的是，在这种情况下，重新安装往往比修复损坏更快、更容易。

相关内容