【系统救援】CentOS7启动失败:报I/O error metadata corruption detected错误

目录

 

问题

解决

扩展

问题

CentOS7系统重启后进入“救援模式”,提示:I/O error metadata corruption错误,截图如下:可见是/dev/sda4分区出现了问题。GRUB正常启动各种服务启动均失败。

解决

1、挂载系统安装光盘,进入救援模式,执行xfs_repair -L /dev/sda4进行修复:

 注意在下面操作界面一定要选择“3”,不然还是xfs_repair不了。

1) Continue :救援模式程序会自动查找系统中已有的文件系统,并可读写挂载到/mnt/sysimage目录下,挂载权限为读写。
2) Read-only mount:挂载权限为只读。
3) Skip to shell :跳过挂载(可手动挂载)直接进入shell。
4) Quit(Reboot):退出重启系统。

直接执行xfs_repair /dev/sda4失败:

根据提示执行:xfs_repair -L /dev/sda4。执行过程未见报错,然后执行reboot重启系统,系统成功加载启动。至此修复完成。

扩展

xfs_repair - repair an XFS filesystem

xfs_repair命令用于修复损坏的(corrupt or damaged )XFS文件系统。通过指定device作为参数,该device是包含文件系统的磁盘分区或者卷的名字。
The filesystem is specified  using  the  device  argument which  should  be  the  device  name  of  the disk partition or volume containing the filesystem. If given the name of a block device, xfs_repair will attempt to find the raw device associated with the specified block device and will use the raw  device  instead.
注意:使用xfs_repair命令修复文件系统,必须卸载掉文件系统,否则会导致文件系统损坏。
Regardless,  the  filesystem to be repaired must be unmounted, otherwise, the resulting filesystem may be inconsistent or corrupt.

需要修复的场景 
1.主机侧发现存在文件系统不可读写的情况,可以通过查看主机端日志来确认是否有文件系统异常发生;
2.出现异常停电,供电恢复正常,主机和阵列系统重起之后;
3.存储介质故障:出现LUN失效、RAID失效、以及IO超时或者出现慢盘,对慢盘进行更换,系统恢复正常之后;
4.传输介质故障:如光纤、网线等损坏等,数据传输链路断开后又恢复正常之后;

检查文件系统 
注:检查文件系统必须保证将文件系统umount成功。 
在根目录下输入“xfs_check /dev/sdd(盘符);echo $?”(注意:在执行 此命令之前,必须将文件系统umount,否则会出现警告信 “xfs_check: /dev/sdd contains a mounted and writable filesystem ”)敲回车键,查看命令执行返回值:0表示正常,其他为不正常,说明文件系统 损坏,需要修复。

修复过程
注:修复时需要暂停主机侧的业务,umount 和 mount 无法修复文件系统 。 
1) 先umount要修复的文件系统的分区 
3) 然后输入 “xfs_repair /dev/sdd(盘符)”执行修复命令。 
xfs_check /dev/sdd; echo $? 
  A)如果为0===》成功修复。 
  B) 如果不为0===》没有成功:请执行xfs_repair –L /dev/sdd命令

参考链接:fsck和xfs_repair - 乐观者 - 博客园

  • 1
    点赞
  • 16
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
在启动 Minikube 时遇到 "Error: initializing source docker://gcr.io/k8s-minikube/kicbase:v0.0.39: pinging container registry gcr.io: Get "https://gcr.io/v2/": dial tcp 74.125.23.82:443: i/o timeout" 错误通常是由于网络连接问题导致的。以下是一些可能的解决方法: 1. 检查网络连接: 确保你的网络连接正常,并且可以访问互联网。尝试使用浏览器或其他网络工具访问 `https://gcr.io/v2/`,看看是否可以成功连接。 2. 检查防火墙设置: 检查你的系统防火墙或网络防火墙设置,确保允许与 `gcr.io` 的通信。如果有防火墙规则限制对特定 IP 或端口的访问,你可能需要相应地进行配置。 3. 使用代理: 如果你的网络使用代理,请确保 Minikube 可以通过代理连接到 `gcr.io`。你可以设置相应的代理环境变量,以便 Minikube 使用正确的代理配置。 ``` export HTTP_PROXY=http://proxy.example.com:port export HTTPS_PROXY=http://proxy.example.com:port ``` 将 `proxy.example.com` 和 `port` 替换为你的代理服务器和端口。 4. 清理并重新启动 Minikube: 如果上述步骤都没有解决问题,可以尝试清理并重新启动 Minikube。运行以下命令: ``` minikube delete minikube start ``` 这将删除现有的 Minikube 集群并重新启动一个新的集群。 如果问题仍然存在,请确保你的系统满足 Minikube 的最低要求,并参考 Minikube 的官方文档或社区支持寻求进一步的帮助。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值