记一次错误卸载软件包导致Linux系统崩溃的修复解决过程

首先问题产生的缘由很简单,是我一同事在安装oracle一套软件时,按照要求需要binutils软件包的32位版本,然而在Oracle Linux已经装有64位,按理说是可以安装i686的,我猜应该是32位的版本低于这个已有的64位所以导致冲突而安装失败,因此同事就用yum remove binutils,这个命令也奇葩,由于是root权限导致依赖于它的200多个软件包也被卸载,最终导致网络断开,系统崩溃,在vSphere虚拟机上重新启动发现再也起不来。下面看问题:

1. Kernel panic - not syncing: Attempted to kill init!


这个错误时在重新启动Oracle Linux一开始就出现,查阅的相关资料得知Kernel panic问题一般是由驱动模块终端处理终端问题导致的(不懂。。。),一开始我以为是驱动程序依赖于binutils导致被卸载,因此第一反应是想办法把缺失的软件装回去。实际上,是由于安全访问控制模块selinux的问题,参考类似问题。于是检查vi /etc/selinux/config时发现SELINUX=disables,拼写错误,应为disabled
当再次启动没再出现该错误时,我高兴的认为原来这么简单就帮同事解决了,事实这根本还没到200多个软件包缺失而导致系统崩溃那一步。

2. 系统启动加载条完成后,一直hang住不动

这无疑要使用LiveCD修复系统了,参考Ultimate method to install package from linux rescue modeUsing Rescue Mode to Fix..Problems。因为知道出问题前做过什么操作,下面直接上解决问题的过程。

2.1 将系统DVD安装镜像加载到光驱

再次重启就自动进入安装界面,我们当然选择rescue mode

一路按照提示确定(可以不配置network,这里就不贴图了,很简单),最终会提供给用户一个shell终端,对应的是从DVD光驱加载进来的系统,执行chroot /mnt/sysimage才会进入到原损坏的Linux系统,还好yumrpm命令还可以使用,悲剧的是我并不知道yum remove命令卸载了哪些软件包。

2.2 安装缺失的软件包

这里得谢天谢地yum命令的安装卸载日志/var/log/yum.log,这个日志里清楚的记录了installederased的所有软件包,用rpm是不可能了,因为270多个包的依赖关系难以解决,只能通过yum方式,而由于rescue模式没有配置网络,因此只能使用本地镜像源。

在rescue系统下挂载光驱到待修复系统中的/media目录
bash-4.1# mount /dev/cdrom /mnt/sysimage/media

chroot进入待修复系统
bash-4.1# chroot /mnt/sysimage

手动编辑一个仓库源(真实待修复的系统)
sh-4.1# cd /etc/yum.repos.d/ && vi Oracle-Media.repo
[DVD-media]
name=oracle-$releasever - Media
baseurl=file:///media
gpgcheck=0
enabled=1

建议只留Oracle-Media.repo文件,其他的.repo文件都mv成.bak,以防连接不了这些源而报错,虽然报错关系不大。
获取被依赖erased掉的软件列表

你可以将yum.log中多余的部分去掉,筛选出应该重新安装的packages:
sh-4.1# cp /var/log/yum.log{,.bak}
sh-4.1# less /var/log/yum.log.bak
Oct 29 20:17:34 Erased: gcc-c++
Oct 29 20:18:44 Erased: gcc
Oct 29 20:22:59 Erased: xorg-x11-drivers
...
Oct 29 20:24:46 Erased: iputils
Oct 29 20:24:46 Erased: udev
Oct 29 20:24:46 Erased: initscripts
Oct 29 20:24:46 Erased: hwdata
Oct 29 20:24:46 Erased: module-init-tools
Oct 29 20:24:48 Erased: binutils

下面一条命令应该要彻底解决问题了
sh-4.1# awk '{print "yum install -y ",$5}' /var/log/yum.log.bak |sh > /root/yum_install.log

保险起见,可以查看一下产生的日志文件。此时重启(记得拿出光盘)应该是修复问题了。但我遇见的问题还没完。

3. An error occurred during the file system check


显然,文件系统损坏。根据提示输入root密码后可以进入到shell中,网上有办法说执行fsck命令来修复分区,又说且不能是mounted状态,但无论我怎么去fsck.ext4 /dev/mapper/vg_fusion_lv_u1,提示

WARNING!!!  The filesystem is mounted.   if you continue you ***WILL*** 
cause ***SEVERE*** filesystem damage`

Do you really want to continue (y/n)? yes

fsck.ext4: No such file or directory while trying to open /dev/mapper/vg_fusion_lv_u1

The superblock could not be read or does not describe a correct ext2 
filesystem.  If the device is valid and it really contains an ext2 
filesystem (and not swap or ufs or something else), then the superblock 
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

听起来好像还挺严重的,我之前猜想的是不是反复的开关电源来重启导致lvm文件系统corrupt,但事实我发现/dev/mapper/vg_fusion_lv_u1不存在,但lv_fusion_lv_root却完好,执行lvdisplay发现这个命令根本不存在,这才发现原来lvm2软件没有安装(难道是第2部分安装少许出错?)。
这下容易多了,反正现在系统不借助rescue mode就可以起来,重新安装软件包,但是此时的整个文件系统是read only,有两个办法可以解决:

  1. mount -o remount,rw /
    重新挂载根分区为读写,vi /etc/fstab注释掉挂载/u1的那条记录,此时会正常启动,只是有一个文件系统没有挂载,但可以正常安装缺失的lvm2软件,不妨多执行几遍2.2的安装命令。然后手动挂载mount /dev/mapper/vg_fusion_lv_u1 /u1应该就没问题了。记得改回/etc/fstab。
  2. 2.2步骤类似,进入rescue modechroot,重新执行awk '{print "yum install -y ",$5}' /var/log/yum.log.bak |sh > /root/yum_install.log,确保没有报错且已安装lvm。

这下问题总是解决了,避免了删除系统的灾难(测试环境)。

4. 总结

回头去看这三个问题,其他它们是各自独立的

  • 第1个问题,是由于设置selinux有人拼写错误,哪怕没做后续的任何操作,重启系统就会启动不了,是早已存在到目前才发现。也有人说遇见过同样的Kernel panic错误但尝试各种办法都难以解决的,这就看具体问题具体分析了。
  • 第2个问题,是真真切切错误卸载重要软件包,导致系统崩溃,修复系统的方法自然也就是利用原镜像在rescue mode下把该装的都装回去,前提是yum.log日志存在,万幸没有执行过yum clean all
  • 第3个问,题实际文件系统并没有损坏,还是lvm2缺失,但是此处必须小心,免得SEVERE filesystem damage,那么修复过程就没意义了。

以后处理其他系统故障时也可使用类似的方法修复,Redhat、CentOS、OracleLinux、Ubuntu等都适用。


原文链接地址:http://seanlook.com/2014/11/03/one-troubleshooting-for-centos-corrupt/


<think>好的,用户问的是怎么查看Linux系统错误修复它们。首先,我需要整理一下思路,确保涵盖主要的排查和修复方法。用户可能是系统管理员或者有一定Linux使用经验的人,遇到系统问题需要解决。他们可能对日志位置、工具使用不太熟悉,需要一步步指导。 首先,系统日志是查找错误的重要来源。常见的日志文件如/var/log/syslog、/var/log/messages,还有各个服务的日志,比如/var/log/nginx/error.log。需要告诉用户这些路径,以及如何用tail、grep等命令查看。此外,journalctl命令对于systemd系统来说很关键,特别是实时监控日志的功能。 接下来,系统工具方面,dmesg可以查看内核相关的错误,硬件问题或者驱动问题可能会在这里显示。top/htop用来监控资源使用情况,可能用户遇到的性能问题可以通过这些工具发现。还有磁盘检查工具,比如df和smartctl,磁盘空间不足或者硬盘故障是常见的问题源。 常见的错误类型需要列举,比如磁盘空间不足、权限问题、服务崩溃、网络问题等。针对每种情况给出解决办法,比如删除文件、chmod/chown调整权限,或者用systemctl重启服务。 自动修复工具如fsck和日志轮询工具logrotate也应该提到,但要注意提醒用户谨慎使用,特别是fsck可能需要卸载文件系统,可能需要启动到恢复模式。 最后,维护建议部分,定期更新系统、备份数据、监控工具的使用,这些能帮助预防问题。用户可能还需要知道如何设置自动化监控,比如cron任务或者使用Prometheus等工具。 需要确保回答结构清晰,分步骤说明,每个部分有具体的命令示例,让用户能跟着操作。同时要注意使用正确的LaTeX格式,虽然这个问题里可能数学公式不多,但如果有变量或代码,需要用行内格式。比如命令中的变量如$FILE可能需要用$包围。 可能用户深层需求是希望系统稳定,快速解决问题,所以不仅要告诉方法,还要给出维护建议,防患于未然。需要检查是否有遗漏的部分,比如是否提到SELinux/AppArmor的问题,或者包管理器相关的故障处理,但可能过于深入,保持基础到中级的内容比较合适。</think>### 一、查看系统错误的核心方法 (步骤分阶说明,按优先级排序) 1. **检查系统日志** 📍核心路径: ```bash /var/log/syslog # 通用系统日志 /var/log/messages # 传统系统消息 /var/log/kern.log # 内核相关错误 /var/log/boot.log # 启动过程错误 ``` 🔧操作命令: ```bash tail -n 100 /var/log/syslog | grep -i "error" # 查看最新100条含error的日志 journalctl -p 3 -xb # 查看systemd系统的严重错误(优先级3及以上) ``` 2. **内核级错误检测** ```bash dmesg -T | grep -E "error|fail|warning" # 带人类可读时间戳 ``` ✅典型错误- `I/O error`(磁盘故障) - `segfault`(内存越界) 3. **服务状态排查** ```bash systemctl --failed # 列出失败的服务单元 systemctl status <service_name>.service # 查看具体服务详情 ``` --- ### 二、高频错误场景与修复方案 #### 场景1:磁盘空间耗尽 🔍检测命令: ```bash df -h | awk '$5 > 90% {print}' # 显示使用率>90%的分区 ``` 🛠️修复步骤: 1. 清理大文件: ```bash ncdu / # 交互式磁盘分析工具 ``` 2. 删除过时日志: ```bash journalctl --vacuum-size=200M # 限制日志占用200MB ``` #### 场景2:文件系统错误 🔍检测命令: ```bash fsck -n /dev/sda1 # 检查不修复 ``` 🛠️修复流程: 1. 卸载分区:`umount /dev/sda1` 2. 强制修复:`fsck -y /dev/sda1` #### 场景3:软件包依赖损坏 🔍检测命令: ```bash apt-get check # Debian/Ubuntu验证包完整性 ``` 🛠️修复命令: ```bash apt --fix-broken install # 自动修复依赖 dpkg --configure -a # 强制完成中断的配置 ``` --- ### 三、高级诊断工具 | 工具名称 | 用途 | 示例命令 | |----------------|-----------------------------------|-----------------------------------| | `strace` | 跟踪进程系统调用 | `strace -p <PID>` | | `lsof` | 查看被占用的文件/端口 | `lsof /var/log/syslog` | | `netstat` | 网络连接诊断 | `netstat -tulnp | grep TIME_WAIT` | | `smartctl` | 硬盘健康检测 | `smartctl -a /dev/sda` | --- ### 四、自动化监控建议 1. **配置日志告警** ```bash # 在/etc/logwatch/conf/logwatch.conf中添加: MailTo = admin@example.com MailFrom = logwatch@$(hostname) ``` 2. **启用系统审计** ```bash auditctl -w /etc/passwd -p wa -k passwd_change # 监控密码文件修改 ``` 3. **部署监控系统** - Prometheus + Grafana(资源监控) - Zabbix(综合告警) --- ### 五、关键修复原则 1. **变更前备份** ```bash cp /etc/fstab /etc/fstab.bak # 修改关键配置前必须备份 ``` 2. **最小化修改** - 优先通过`apt-get revert`或`snap revert`回滚操作 3. **验证修复效果** ```bash reboot # 关键修复后必须重启验证 journalctl -b # 查看本次启动日志 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值