centos故障修复

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

操作系统启动失败如下图报错:

wKiom1RKZXqgHGs6AANK_kNlQys060.jpg

故障现象:

从图中可以看到,操作系统启动的过程中,fsck在执行文件系统检测时出现了错误,并且是在检查/dev/mapper/VolGroup-lv_home时出错,提示此文件不存在;

故障分析:

这是一个什么界面,为何会出现这个界面?

CentOS6.4的操作系统启动的的大致过程为:加载BootLoader-à加载kernel-àinit执行系统初始化-à用户登录;而在init执行系统初始化的过程中,会执行系统初始化脚本/etc/rc.d/rc.sysinit,在此脚本中即会执fsck -A进行文件系统检测;

fsck -A会执行什么操作呢?

fsck -A会遍历文件/etc/fstab,检查其中定义的所有的文件系统。fsck在做文件系统检查前通常不会去检查设备是否真实存在,所以如果某设备不存在,而又去做了fsck,fsck即会报错,继而导致启动操作系统时会进入文件系统修复模式(file system repair mode),而中断正常的操作系统启动;

所以,这就是为何会出现此界面的原因了。

解决方法

既然是fsck执行失败,导致操作系统无法继续启动,所以可以在操作系统启动时,让fsck跳过检查这个有问题的/dev/mapper/VolGrouplv_home即可正常启动操作系统;(在/etc/fstab中设置此项的第6个字段fs_passno的值设为0,即意为fsck不检查此行)

但是此时文件系统修复模式下所有文件都是只读的,无法编辑/etc/fstab;所以此时可以选择从系统光盘启动,选择进入紧急救援模式下去修改文件(因为紧急修复模式不会执行/etc/rc.d/rc.sysinit,所以不会出现此报错);下面3行是在紧急救援模式下的操作:

1
2
3
bash-4.1# chroot /mnt/sysimage
sh-4.1# vim /etc/fstab             ##将/dev/mapper/VolGrouplv_home这一行的第6个字段设为0
sh-4.1# reboot -r

此时即可正常启动系统,不过中途会看到如下界面:

wKiom1RKZ8LzU4kiAAHPtG_x4m8874.jpg

此时已没有fsck的报错,但是mount挂载文件系统时有一个failed的信息,这是因为在系统初始化脚本/etc/rc.d/rc.sysinit中,文件系统检测完成后的下一步即是根据/etc/fstab文件中的定义去挂载文件系统;此时即提醒找不到/dev/mapper/VolGroup-lv_home,所以会出现上图红圈内的报错;

并且从此界面可以明确的看到问题的所在了,/dev/mapper/VolGroup-lv_home不存在;虽然有此failed信息,但不影响系统可以继续启动;

上图绿色圈中的是需等待SELinux自动完成重新打标,若不想等待,可以在系统启动时禁入编辑模式,禁用SELinux的启动即可,如下图:

wKiom1RKaESSAihxAADwKCnHGFA003.jpg

--------------------------------------------------------------------

至此操作系统已经可以启动起来,此处需介绍下背景了,此系统安装时是按照系统默认的分区布局(partitioning layout),如下图:

wKiom1RKaMvzQle7AAGPBvjJ-gE539.jpg

一块硬盘sda,分成了sda1sda2两个分区,sda2做成物理卷,基于此物理卷创建的卷组名称为VolGroup,在此卷组上创建了3个逻辑卷,名称分别为lv_rootlv_homelv_swap,并且此逻辑卷lv_rootlv_home分别挂载到了文件系统中的/目录和/home目录;

所以前文中/dev/mapper/VolGroup-lv_home即是此系统自动创建的挂载在/home的逻辑卷;比如由于误操作(umount、lvremove,或是系统断电等其他意外情况也可能会导致类似问题),删除了此逻辑卷,然后在重启电脑时,即会出现开篇处的报错了。

--------------------------------------------------------------------------------------------------------------------------------------

现在操作系统已经启动登录,也知道问题所在了,那么接下来如何恢复此逻辑卷呢?

此时,系统中查看此逻辑卷的确是已被删除;

1
2
3
4
5
6
7
[root@mysqlhost1 ~]# lvs
  LV      VG      Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lv_root VolGroup -wi-ao--- 50.00g                                             
  lv_swap VolGroup -wi-ao--- 992.00m                                             
[root@mysqlhost1 ~]# ll /dev/VolGroup/
lrwxrwxrwx 1 root root 7 10月 22 20:27lv_root -> ../dm-0
lrwxrwxrwx 1 root root 7 10月 22 20:27lv_swap -> ../dm-1

并且由于此逻辑卷是挂载在/home目录下,此逻辑卷丢失,那么/home目录下的数据,是否也是一同丢失了呢?如何恢复/home目录下原有的数据?

lvremove删除逻辑卷,其只是会清除LVM的部分元数据信息(metadata),真正的数据仍会被完整的保留即虽然逻辑卷lv_home被删除了,但是原/home下的数据仍然存在,只是现在暂且看不到;

并且默人的配置是,LVM的物理卷、卷组或是逻辑卷发生任何改动之前,LVM的元数据信息都会自动保存至/etc/lvm/archive目录下;

所以我们只需恢复逻辑卷lv_home被删除前的自动备份的LVM元数据信息,逻辑卷lv_home即可自动恢复,然后后重新挂载,即可查看到/home目录下原有的数据了;如下操作步骤:

1
2
3
4
5
6
##查看和卷组VolGroup相关的元数据备份信息
[root@mysqlhost1 ~]# vgcfgrestore --list VolGroup  
   File:          /etc/lvm/archive/VolGroup_00001-560861966.vg
   VG name:            VolGroup
   Description:    Created *before* executing 'lvremove /dev/VolGroup/lv_home'
   Backup Time:  Wed Oct 22 17:33:17 2014

此处的结果中可以看到在执行'lvremove /dev/VolGroup/lv_home'之前,卷组的元数据自动被备份到了文件/etc/lvm/archive/VolGroup_00001-560861966.vg

1
2
3
4
5
6
7
8
9
10
11
12
13
14
##从对应文件中恢复卷组VolGroup的那一刻的元数据信息 
[root@mysqlhost1 ~]# vgcfgrestore -f/etc/lvm/archive/VolGroup_00001-560861966.vg VolGroup
   Restored volume group VolGroup
##此时即可看到此逻辑卷lv_home了
[root@mysqlhost1 ~]# lvscan                                 
  ACTIVE           '/dev/VolGroup/lv_root' [50.00 GiB] inherit
  inactive         '/dev/VolGroup/lv_home' [108.54 GiB] inherit
  ACTIVE           '/dev/VolGroup/lv_swap' [992.00 MiB] inherit
##激活此逻辑卷
[root@mysqlhost1~]# lvchange -ay /dev/VolGroup/lv_home              
[root@mysqlhost1 ~]# lvscan
  ACTIVE           '/dev/VolGroup/lv_root' [50.00 GiB] inherit
  ACTIVE           '/dev/VolGroup/lv_home' [108.54 GiB] inherit
  ACTIVE            '/dev/VolGroup/lv_swap' [992.00 MiB] inherit
1
2
3
4
5
6
##恢复/etc/fstab中刚才做的改动
[root@mysqlhost1 ~]# vi /etc/fstab  
##重新挂载         
[root@mysqlhost1 ~]# mount -a    
##/home目录下原有的数据也都可以查看到了                       
[root@mysqlhost1 ~]# ls /home



















本文转自东方之子736651CTO博客,原文链接:http://blog.51cto.com/ecloud/1568708  ,如需转载请自行联系原作者
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
安全 Unix Linux
CentOS7 Sudo本地提权漏洞修复实践
CentOS7 Sudo本地提权漏洞修复实践
1005 0
CentOS7 Sudo本地提权漏洞修复实践
|
3月前
|
运维 Linux
CentOS操作系统常见的故障处理
本文分享了CentOS操作系统网卡启动失败的故障处理方法,包括使用命令查看日志和禁用NetworkManager服务。
249 4
CentOS操作系统常见的故障处理
|
Linux Shell
Centos显示-bash-4.1$问题的修复及原因探究
Centos显示-bash-4.1$问题的修复及原因探究
170 0
|
Linux Shell
CentOS7下重建grub并恢复系统的故障案例
CentOS7下重建grub并恢复系统的故障案例
745 0
CentOS7下重建grub并恢复系统的故障案例
|
Linux Perl
修复 Longhorn 卷挂载失败(”CentOS 7.6-'fsck' found errors on device“)
修复 Longhorn 卷挂载失败(”CentOS 7.6-'fsck' found errors on device“)
296 0
|
运维 安全 NoSQL
centos 网站漏洞修复之vim文本编辑BUG分析与修复方案
linux系统一直以来都是比较安全的,不管是系统内核还是一些第三方软件都没有太大的漏洞,包括前几年爆出的redis漏洞,没有太多漏洞,然后最近linux频频爆出高危的漏洞,使用vim文本编辑器很多年了,得知被爆出远程代码执行漏洞,有点不可思议,全国大多数的linux服务器都使用的是vim,包括centos系统,redhat,关于该漏洞的详情以及修复方案,我们SINE安全来详细的跟大家介绍一下:
195 0
centos 网站漏洞修复之vim文本编辑BUG分析与修复方案