这是一次惨痛的教训。前两天刚在网上看了人们因为一个空格引发的血案（哈哈，没介个夸张了），说的是一个开源程序的安装脚本里面因为多了一个空格导致程序误删除了系统usr目录。呼呼，介个，太有杀伤力了。可是介个今天尽然发生在了我自己身上。BS一下。

 

问题起因：

       昨天写了个程序发布脚本，因为多了一个空格，从而导致把系统lib目录删除了。直接导致系统无法正常启动。

 

 

解决方式：

       通过相同版本的系统盘引导，进入救援模式（linux rescue）。选择好语言，配置网络特别重要，因为呆会要通过scp命令从另外一个机器上拷贝一个lib目录过来。（注，如果机器无法恢复，可以通过这种方式把文件从机器里面恢复备份出来）。

 

操作：

1、在光驱插入系统盘，从光驱启动。

2、在boot命令行输入: linux rescue

3、根据提示选择语言，配置网络，选择操作权限，如果要修复一定要选择可写。

4、这样程序会把之前安装的系统镜像到/mnt/sysimage 目录底下。

5、这个时候通过shell命令可以操作和查看这个目录下的文件。(chroot /mnt/sysimage)

6、这个时候通过scp命令从另外一个相同系统版本的机器上把lib目录拷贝过来。再重新启动系统。

7、注，这里面没有ll命令，只能用ls。这前不知道用了ll还以为有问题。

 

这样，第一阶段算告一个段落了。呼呼，出来呼吸一下新鲜空气，机房空气真差，而且好吵。有木有，相信各位同胞们都有体会。

 

机器是起来了，可是新的问题又来了。什么情况

 

在系统开机的时候直接提示：

libc.so.6 共享库打开失败，原因无权访问（Permission denied）

libm.so.6等一系列在lib目录下存在链接的库都找不到了（No such file or directory），纠结了，为什么捏？

 

通过各种渠道，问部门linux高手，在网上找资料，可是结果只有一个没办法。高手都建议我重装了。

可是我就不相信这个问题解决不了，于是我去找了一些用户相关及linux权限控制的资料。终于让我看到了希望

selinux高安全性内核。如果通过这个guest用户登录系统即使是否777权限的文件也不能正常访问，好了，希望来了。

于是在网上找了一下关闭这个用户组的方式，方式如下：

 

vim /etc/sysconfig/selinux 把selinux设置为disable。

然后开机启动，哈哈，一切搞定，OK