首先问题产生的缘由很简单，是我一同事在安装oracle一套软件时，按照要求需要binutils软件包的32位版本，然而在oracle linux已经装有64位，按理说是可以安装i686的，我猜应该是32位的版本低于这个已有的64位所以导致冲突而安装失败，因此同事就用<code>yum remove binutils</code>，这个命令也奇葩，由于是root权限导致依赖于它的200多个软件包也被卸载，最终导致网络断开，系统崩溃，在vsphere虚拟机上重新启动发现再也起不来。下面看问题：
当再次启动没再出现该错误时，我高兴的认为原来这么简单就帮同事解决了，事实这根本还没到200多个软件包缺失而导致系统崩溃那一步。
再次重启就自动进入安装界面，我们当然选择<code>rescue mode</code>：
一路按照提示确定（可以不配置network，这里就不贴图了，很简单），最终会提供给用户一个shell终端，对应的是从dvd光驱加载进来的系统，执行<code>chroot /mnt/sysimage</code>才会进入到原损坏的linux系统，还好<code>yum</code>和<code>rpm</code>命令还可以使用，悲剧的是我并不知道<code>yum remove</code>命令卸载了哪些软件包。
这里得谢天谢地<code>yum</code>命令的安装卸载日志<code>/var/log/yum.log</code>，这个日志里清楚的记录了<code>installed</code>和<code>erased</code>的所有软件包，用rpm是不可能了，因为270多个包的依赖关系难以解决，只能通过yum方式，而由于rescue模式没有配置网络，因此只能使用本地镜像源。
建议只留oracle-media.repo文件，其他的.repo文件都<code>mv</code>成.bak，以防连接不了这些源而报错，虽然报错关系不大。
获取被依赖erased掉的软件列表
保险起见，可以查看一下产生的日志文件。此时重启（记得拿出光盘）应该是修复问题了。但我遇见的问题还没完。
显然，文件系统损坏。根据提示输入root密码后可以进入到shell中，网上有办法说执行<code>fsck</code>命令来修复分区，又说且不能是mounted状态，但无论我怎么去<code>fsck.ext4 /dev/mapper/vg_fusion_lv_u1</code>，提示
听起来好像还挺严重的，我之前猜想的是不是反复的开关电源来重启导致lvm文件系统corrupt，但事实我发现<code>/dev/mapper/vg_fusion_lv_u1</code>不存在，但<code>lv_fusion_lv_root</code>却完好，执行<code>lvdisplay</code>发现这个命令根本不存在，这才发现原来lvm2软件没有安装（难道是第2部分安装少许出错？）。
这下容易多了，反正现在系统不借助<code>rescue mode</code>就可以起来，重新安装软件包，但是此时的整个文件系统是<code>read only</code>，有两个办法可以解决：
<code>mount -o remount,rw /</code>
重新挂载根分区为读写，<code>vi /etc/fstab</code>注释掉挂载<code>/u1</code>的那条记录，此时会正常启动，只是有一个文件系统没有挂载，但可以正常安装缺失的lvm2软件，不妨多执行几遍2.2的安装命令。然后手动挂载<code>mount /dev/mapper/vg_fusion_lv_u1 /u1</code>应该就没问题了。记得改回/etc/fstab。
与<code>2.2</code>步骤类似，进入<code>rescue mode</code>→<code>chroot</code>，重新执行<code>awk '{print "yum install -y ",$5}' /var/log/yum.log.bak |sh > /root/yum_install.log</code>，确保没有报错且已安装lvm。
这下问题总是解决了，避免了删除系统的灾难（测试环境）。
回头去看这三个问题，其他它们是各自独立的
第1个问题，是由于设置selinux有人拼写错误，哪怕没做后续的任何操作，重启系统就会启动不了，是早已存在到目前才发现。也有人说遇见过同样的<code>kernel panic</code>错误但尝试各种办法都难以解决的，这就看具体问题具体分析了。
第2个问题，是真真切切错误卸载重要软件包，导致系统崩溃，修复系统的方法自然也就是利用原镜像在<code>rescue mode</code>下把该装的都装回去，前提是yum.log日志存在，万幸没有执行过<code>yum clean all</code>。
第3个问，题实际文件系统并没有损坏，还是lvm2缺失，但是此处必须小心，免得<code>severe filesystem damage</code>，那么修复过程就没意义了。
以后处理其他系统故障时也可使用类似的方法修复，redhat、centos、oraclelinux、ubuntu等都适用。