当您的Linux实例/etc/fstab文件中未正确配置要自动挂载的文件系统信息或者存在已不可用的文件系统信息，重启系统后可能导致ECS实例的操作系统无法正常启动。您可以通过实例健康诊断工具进行问题修复。
前提条件
Linux实例已通过实例健康诊断工具进行诊断，诊断结果中以下检查项未通过：
- fstab文件中的设备检查
- fstab文件中的设备挂载状态检查
背景信息
问题描述：Linux实例的/etc/fstab文件中，如果未正确配置要自动挂载的文件系统信息，或者存在多余的文件系统配置信息，但其所在的块设备已经不存在或者已从实例上卸载，则重启系统后可能导致系统无法正常启动。
可能原因：
- 云盘已经挂载到实例上，但/etc/fstab文件中配置了错误的文件系统信息，或者云盘上并未包含的文件系统。
- 云盘尚未挂载到实例上，但/etc/fstab文件中却配置了相应的文件系统信息。
解决方案
- 远程连接问题实例。当ECS实例处于正在挂载修复盘的模式下时，只能通过VNC远程连接。具体操作，请参见通过密码认证登录Linux实例。
- 查看问题实例原有系统盘的挂载信息。在临时挂载的修复盘中，问题实例原有系统盘的文件系统会被挂载到某一临时目录下。您可以通过以下任一方式查看所在的临时目录信息：
- 通过ECS控制台的实例健康诊断结果获取，对应的信息格式示例如下所示：
/tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****。 - 在临时挂载的修复盘中，运行mount命令查看。例如，问题实例原有系统盘的设备路径为/dev/vda，命令示例如下所示：
mount | grep /dev/vda
返回结果如下所示：/dev/vda1 on /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse**** type ext4 (rw,relatime)
- 运行以下命令，将修复盘内的虚拟文件系统/dev、/proc和/sys挂载到chroot环境中的根目录。挂载虚拟文件系统的作用为确保后续操作中blkid命令能够正常读取文件系统信息。
mount --bind /dev /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****/dev mount --bind /proc /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****/proc mount --bind /sys /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****/sys
- 运行chroot命令，将根目录切换为问题实例原有系统盘所在的临时路径，并进入chroot环境。您需要在问题实例原有系统盘所在的临时路径中进行文件修复。例如，临时路径为/tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****，命令如下所示：
chroot /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****
- 在chroot环境的根目录，确认虚拟文件/dev、/proc和/sys的目录中已包含正常实例的数据。如果虚拟文件目录下内容为空，将导致部分必须的系统信息无法读取。因此需要运行exit命令，退出chroot环境，重新执行步骤3和4。
- 运行以下命令，查看Linux实例中存在的块设备信息。
blkid
返回结果示例如下所示：/dev/sr0: UUID="2021-01-28-17-41-**-**" LABEL="ecsgo_rescue_linux" TYPE="iso9660" PTTYPE="dos" /dev/vda1: UUID="edf839fd-8e1a-4373-946a-12345678****" TYPE="ext4"/dev/vdb1: UUID="baed21c8-dbca-43f9-b4f0-60f6b2db****" TYPE="ext4"/dev/loop0: TYPE="squashfs" /dev/loop1: TYPE="DM_snapshot_cow" /dev/loop2: TYPE="squashfs" /dev/loop3: LABEL="_ecsgo_rescue_li" UUID="d3dc381f-d365-4f3f-9b6e-c8108642****" TYPE="ext4" /dev/loop4: TYPE="DM_snapshot_cow" /dev/mapper/live-rw: LABEL="_ecsgo_rescue_li" UUID="d3dc381f-d365-4f3f-9b6e-c8108642****" TYPE="ext4" /dev/mapper/live-base: LABEL="_ecsgo_rescue_li" UUID="d3dc381f-d365-4f3f-9b6e-c8108642****" TYPE="ext4" /dev/mapper/live-osimg-min: LABEL="_ecsgo_rescue_li" UUID="d3dc381f-d365-4f3f-9b6e-c8108642****" TYPE="ext4"
请注意： - /dev/sr0、/dev/loop0至/dev/loop4、/dev/mapper/live-rw、/dev/mapper/live-base、/dev/mapper/live-osimg-min属于修复系统的块设备信息，请忽略。
- 您只需要关注Linux实例存在的块设备信息，例如/dev/vda1以及
/dev/vdb1。 - 运行以下命令，查看/etc/fstab文件中已配置的块设备信息。
cat /etc/fstab
返回结果示例如下所示：
- 检查blkid命令结果与/etc/fstab文件中的内容是否匹配，然后在/etc/fstab文件中修复不匹配的配置项。
- 将
UUID=edf839fd-8e1a-4373-946a-c32c9b45****替换为blkid命令结果中的UUID=edf839fd-8e1a-4373-946a-12345678****。 - 新增一行配置项，写入
/dev/vdb1文件系统信息。UUID=baed21c8-dbca-43f9-b4f0-60f6b2db**** /mnt ext4 defaults 0 0
- 需要自动挂载的文件系统都已配置正确，并且配置的文件系统在实例上确实存在。
如果配置的文件系统在实例上不存在，并且未在/etc/fstab文件对应行设置
nofail参数，将导致系统启动时因找不到所需要挂载的文件系统而失败。 - 如果使用UUID指定挂载的文件系统，确保UUID信息完全一致。
- 确保配置的挂载点均已创建完成并且不存在冲突。
- 确保/etc/fstab文件中每一行配置项的参数都符合文件系统的格式要求。
/dev/vda1的UUID不匹配。/dev/vdb1挂载到实例后，在/etc/fstab文件中未配置对应的文件系统信息。- 运行以下命令进入编辑模式。
vi /etc/fstab
- 将不匹配的示例值替换为正确值。本文示例中，进行如下修改：
- 按Esc键，输入
:wq并回车，保存退出文件。 - 确认不匹配的内容。包含但不限于以下需要确认的内容：如本文提供的blkid命令结果与/etc/fstab文件的示例值对比所示，不匹配的情况如下：
- 运行以下命令，备份/etc/fstab文件。
cp /etc/fstab /etc/fstab.bak
- 修复不匹配的配置项。修复完成后，/etc/fstab文件内容如下所示，与blkid命令结果保持一致。
- 修复完成后，退出修复环境，然后检查问题实例的当前状态。
- 运行exit命令，退出chroot环境。
- 运行以下命令，解除虚拟文件系统的挂载。
umount /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****/dev umount /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****/proc umount /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****/sys
- 在ECS控制台的实例健康诊断页面，卸载修复盘并恢复问题实例至正常模式。
- 远程连接已修复的ECS实例，确认成功登录。
来源：阿里云
