文件系统损坏导致虚拟机无法正常启动的问题及解决方法

Posted 2023-04-25

参考技术A 简介

计算机的文件系统是一种存储和组织计算机数据的方法，它使得对其访问和查找变得容易，文件系统使用文件和树形目录的抽象逻辑概念代替了硬盘和光盘等物理设备使用数据块的概念，用户使用文件系统来保存数据不必关心数据实际保存在硬盘（或者光盘）的地址为多少的数据块上，只需要记住这个文件的所属目录和文件名。

在使用中, 会遇到文件系统损坏的故障, 直接导致 Azure 平台的虚拟机无法正常启动和访问, 以下是关于此类问题的描述及解决方法.

关于文件系统,详情参见如下:

文件系统

注意:本文档讨论的文件系统以 CentOS 作为范例, 其他版本的 Linux 略有不同, 请注意差别.

文件系统损坏常见问题

范例1:

复制

Checking all file systems.

[/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/sda1

/dev/sda1  contains a file system with errors, check forced .

/dev/sda1: Inodes that were part of a corrupted orphan linked list found.

/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

范例2:

复制

EXT4-fs (sda1): INFO: recovery required on readonly filesystem

EXT4-fs (sda1): write access will be enabled during recovery

EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure

EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Making fs in need of filesystem check .

解决方案之 root 文件系统损坏

A = 文件系统故障所在的虚拟机

B = 临时虚拟机

在 Azure 经典管理门户上停止运行虚拟机 A.

在同一个 cloud service 里创建一台临时 Linux 虚拟机 B.

删除虚拟机 A, 但是选择保留磁盘.

在 Azure 经典管理门户上,选择虚拟机 B -> 附加磁盘 -> 选择虚拟机 A 的系统磁盘.

以管理员身份登陆虚拟机 B.

执行:# fdisk -l

确认虚拟机 A 的系统磁盘作为新的磁盘设备附加在虚拟机 B 上.假定虚拟机A的系统磁盘为 /dev/sdc, root 文件系统为 /dev/sdc1

执行以下步骤, 进行备份文件系统信息:

复制

# fdisk -l /dev/sdc > /var/tmp/fdisk_before.log

# dumpe2fs /dev/sdc1 > /var/tmp/dumpe2fs_before.log

# tune2fs -l /dev/sdc1 > /var/tmp/tune2fs_before.log

# e2fsck -n /dev/sdc1 > /var/tmp/e2fsck._beforelog

执行以下命令, 进行文件系统修复:

复制

# fsck -yM /dev/sdc1

解决方案之常规文件系统损坏

A = 文件系统故障所在的虚拟机

B = 临时虚拟机

在 Azure 经典管理门户上停止运行虚拟机 A.

在同一个 cloud service 里创建一台临时 Linux 虚拟机 B.

删除虚拟机 A, 但是选择保留磁盘.

在 Azure 经典管理门户上,选择虚拟机 B -> 附加磁盘 -> 选择虚拟机 A 的系统磁盘.

以管理员身份登陆虚拟机 B.

执行:# fdisk -l

确认虚拟机 A 的系统磁盘作为新的磁盘设备附加在虚拟机 B 上.假定虚拟机 A 的系统磁盘为 /dev/sdc, root 文件系统为 /dev/sdc1

执行如下命令,将虚拟机A的系统磁盘挂载到临时虚拟机上:

复制

# mkdir /mnt/temp_fs

# mount /dev/sdc1 /mnt/temp_fs

# cp /mnt/temp_fs/etc/fstab /mnt/temp_fs/etc/fstab.org

# vi /mnt/temp_fs/etc/fstab

将文件系统损坏的条目注释掉,保存修改, 退出 vi.

# umount /dev/sdc1

在 Azure 经典管理门户上分离虚拟机 A 的系统磁盘.

在 Azure 经典管理门户上基于虚拟机 A 的系统磁盘, 重建虚拟机 A.

以管理员身份登录虚拟机 A.

执行以下命令, 进行文件系统修复:

复制

# fsck -yM ;

文件系统修复完毕以后, 恢复 /etc/fstab 被注释的对应条目, 重启虚拟机.

立即访问http://market.azure.cn

Linux文件系统损坏导致无法正常启动与fsck修复工具

问题：
今天在打开自己的虚拟机学习的时候，发现在文件系统检查过程中出现以下的报错:
/dev/mapper/VolGroup-lv_root:UNEXPECTED INCONSISTENCY;RUN fsck MANUALLY. [FAILED]
这提示意味着，Linux文件系统损坏了，导致文件系统损坏的原因可能是异常的关机，比如：突然断电。
这里的提示已经很明确的说明了，“UNEXPECTED INCONSISTENCY;RUN fsck MANUALLY.”：意外的不一致性导致文件系统损坏，需要手动fsck修复。
按照系统的提示，输入密码进到系统里面

然后输入命令：fsck (然后根据提示输入yes)

再输入命令：fsck –y /dev/sda1

最后reboot重启系统即可

/etc/fstab配置文件
首先这里来说一下为什么开机会出现文件系统检查这一步。
想要使文件系统开机挂载并检查，可以通过/etc/fstab开机自动挂载文件系统的配置文件进行设置。

配置文件中每列的含义：
第一列：被挂载的文件系统
第二列：挂载点
第三列：文件系统类型
第四列：挂载选项（一般都是使用默认defaults）
第五列：是否备份
第六列：是否开机做磁盘检查
很明显，想要开机磁盘检查，就把第六列设置为“1”，建议普通磁盘都设置0不备份也不检查，否则磁盘有问题，可能会导致系统起不来；系统盘则可设置为1或2。
fsck修复工具
使用man fsck中找到这段解释：check and repair a Linux file system。
从这里可以知道，fsck工具不仅可以做文件系统的检查（扫描），还能修复文件系统，当然fsck所能修复的问题也是有限的，但又不失为一个便捷的自带修复工具。fsck的使用权限必须是root权限。
语法：fsck [-sACVRP] [-t fstype] [--] [fsck-options] filesys [...]
参数：
-t : 给定档案系统的型式，若在 /etc/fstab 中已有定义或 kernel 本身已支援的则不需加上此参数
-s : 依序一个一个地执行 fsck 的指令来检查
-A : 对/etc/fstab 中所有列出来的 partition 做检查
-C : 显示完整的检查进度
-d : 列印 e2fsck 的 debug 结果
-p : 同时有 -A 条件时，同时有多个 fsck 的检查一起执行
-R : 同时有 -A 条件时，省略 / 不检查（忽略根文件系统）
-V : 详细显示模式
-a : 如果检查有错则自动修复
-r : 如果检查有错则由使用者回答是否修复
-n：对所有文件进行检测，对所有提问都用no回答（交互式统一为no，不需手动输入）；只检测文件系统，不进行修复，只报告。
-y：与-n相对，对所有文件进行检测，对所有提问都用yes回答，无须人工干预，自动修复文件系统。
-D：通知fsck额外检查系统的一致性。
-f 强制进行检查