![意外删除了我的 /bin 文件夹?](https://linux22.com/image/1381612/%E6%84%8F%E5%A4%96%E5%88%A0%E9%99%A4%E4%BA%86%E6%88%91%E7%9A%84%20%2Fbin%20%E6%96%87%E4%BB%B6%E5%A4%B9%EF%BC%9F.png)
我在 root 终端上乱搞,不小心删除了整个/bin
文件夹。这危险吗?我该怎么做才能解决这个问题?
root@laptop:/# ls -l /
total 80
drwxr-xr-x 3 root root 4096 Oct 11 19:10 boot
drwxr-xr-x 16 root root 3360 Oct 11 20:21 dev
drwxr-xr-x 123 root root 4096 Oct 12 10:08 etc
drwxr-xr-x 3 root root 4096 Dec 14 2012 home
lrwxrwxrwx 1 root root 29 Oct 11 19:10 initrd.img -> boot/initrd.img-3.2.0-4-amd64
lrwxrwxrwx 1 root root 30 Oct 11 18:48 initrd.img.old -> /boot/initrd.img-3.2.0-4-amd64
drwxr-xr-x 15 root root 4096 Oct 11 18:54 lib
drwxr-xr-x 2 root root 4096 Oct 11 18:48 lib64
drwx------ 2 root root 16384 Oct 11 18:47 lost+found
drwxr-xr-x 3 root root 4096 Oct 11 20:21 media
drwxr-xr-x 2 root root 4096 Dec 14 2012 mnt
drwxr-xr-x 2 root root 4096 May 6 05:27 opt
dr-xr-xr-x 150 root root 0 Oct 11 18:54 proc
drwx------ 4 root root 4096 Oct 11 20:40 root
drwxr-xr-x 17 root root 680 Oct 12 10:06 run
drwxr-xr-x 2 root root 4096 Oct 11 19:09 sbin
drwxr-xr-x 2 root root 4096 Jun 10 2012 selinux
drwxr-xr-x 2 root root 4096 May 6 05:27 srv
drwxr-xr-x 13 root root 0 Oct 11 18:54 sys
drwxrwxrwt 11 root root 4096 Oct 12 11:31 tmp
drwxr-xr-x 10 root root 4096 Oct 11 18:51 usr
drwxr-xr-x 11 root root 4096 Oct 11 18:55 var
lrwxrwxrwx 1 root root 26 Oct 11 19:10 vmlinuz -> boot/vmlinuz-3.2.0-4-amd64
lrwxrwxrwx 1 root root 26 Oct 11 18:51 vmlinuz.old -> boot/vmlinuz-3.2.0-4-amd64
答案1
危险吗?现在不危险了——你已经做了危险的事。
你刚刚删除了系统中基本的属于每个系统的东西都需要。根据维基百科关于 FHS 的文章/bin 包含“在单用户模式下需要可用的基本命令二进制文件;适用于所有用户,例如 cat、ls、cp。”这些在某些情况下非常重要。
假设你想解决这个问题,你可能能够从正在运行的系统复制 /bin - 可能是从与你的发行版相同版本的 livecd 复制。我不能完全当然可以。
尽管如此,在尝试此操作时,请备份所有必要文件,以防万一出现问题。/etc/ /home 和 /var 可能是个好主意,在使用它的发行版中 /srv 也是个好主意。
答案2
是的,您刚才犯的一个相当严重的错误,可能与删除 Windows 上的 Program Files 相当(如果可能的话)。
如果您有另一台(虚拟)机器,您可以尝试这个相当不错且快速的解决方案来解决这个常见问题:
我们需要什么?
- ssh、rsync、sudo 应该仍然可用
- 你应该有一个类似的系统可以通过你的网络访问(使用 coreutils)
过程:
- 复制 bin 目录:
'#' 符号表示您应该是 root 用户。在大多数系统上,用“sudo”替换 '#' 即可。在其他系统上,请使用“su”。
# rsync -rv <remote-login>@<remote-server>:/bin /
或者
# scp -rv <remote-login>@<remote-server>:/bin /
- 然后“cd”到 /bin 目录(现在应该可以再次工作了)
# ln -s bash sh
这很重要,因为大多数程序实际上都链接到 /bin/sh,而且许多脚本都在 shebang (#!) 行中链接到它。您应该链接到 bash(对于大多数人来说),或者您使用的 shell(对于那些可能不会删除 /bin 目录的人来说)。
- 从你的存储库更新和升级(在 Ubuntu 和 Debian 上)
# aptitude update && sudo aptitude upgrade
或者
# apt-get update && sudo apt-get upgrade
这至少应该能让你拥有一个可以正常工作的系统。你也许应该重新安装 coreutils,并且通常情况下,要小心谨慎。你应该备份你的数据,并小心谨慎。
答案3
在某些发行版(例如 Debian)的最新版本中,目录中的文件/
被合并到 /usr 中的各自对应文件中,因此/bin
其他文件是简单的符号链接:
/bin → /usr/bin
/sbin → /usr/sbin
/lib → /usr/lib
/lib64 → /usr/lib64
如果是这种情况,您可以使用发行版的救援或实时模式简单地重新创建这些符号链接。
答案4
我已完成下列操作并能够在 5 分钟内恢复我的完整功能的 Ubuntu。
将 Ubuntu 的副本(已崩溃的相同版本)安装到 U 盘中。
在有问题的机器上使用 U 盘运行 Ubuntu Live 模式
找到您崩溃的驱动器并从机器左上角的“位置”选项卡中安装它。
Ctrl使用+ Alt+ "打开终端T,并使用 在已安装的驱动器中创建一个 bin 文件夹
sudo
,即sudo mkdir /media/bin
使用 将所有 bin 文件从实时会话复制到受害设备,
sudo
即sudo cp /bin/* /media/bin
重新启动,它可能会显示一些消息来更新您的固件(或其他消息),只需忽略一段时间并登录。