排查由于 fstab 错误而导致的 Linux VM 启动问题

注意

本文中引用的 CentOS 是 Linux 发行版, (EOL) 将达到生命周期结束。 相应地考虑使用和计划。 有关详细信息,请参阅 CentOS 生命周期终止指南

Linux 文件系统表 fstab 是一个配置表,旨在配置在系统启动过程中按顺序检测和装载特定文件系统的规则。 本文讨论错误的 fstab 配置可能导致启动问题的多种情况,并提供故障排除指南。

下面列出了由于 fstab 错误配置而导致虚拟机启动问题的几个常见原因:

  • 使用传统文件系统名称,而不是文件系统的 UUID) (通用唯一标识符。
  • 使用的 UUID 不正确。
  • fstab 配置中没有 nofail 选项的未附加设备存在条目。
  • fstab 配置中的条目不正确。

确定 fstab 问题

在Azure 门户的 “启动诊断] (/azure/virtual-machines/boot-诊断#boot-诊断-view) 边栏选项卡中检查串行日志中 VM 的当前启动状态。 VM 将处于紧急模式。 会看到类似于以下示例导致紧急模式状态的日志条目:

[K[[1;31m TIME [0m] Timed out waiting for device dev-incorrect.device.
[[1;33mDEPEND[0m] Dependency failed for /data.
[[1;33mDEPEND[0m] Dependency failed for Local File Systems.
…
Welcome to emergency mode! After logging in, type "journalctl -xb" to viewsystem logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode.
Give root password for maintenance
(or type Control-D to continue)

注意

“/data”是使用的装入点的示例。 文件系统装入点的依赖项失败因使用的名称而异。

解决方案

有 2 种方法可以解决此问题:

修复 VM 联机

使用串行控制台

  1. 从 Azure 门户 连接到 VM 的串行控制台
  2. 需要手动访问单用户模式才能重新配置 fstab。 这些步骤可能因使用的 Linux OS 类型和对根帐户的访问权限而异。 按照 单用户模式 文档访问每个受支持的 Linux 合作伙伴映像的单用户模式。
Fstab 故障排除步骤
  1. Vm 启动到单用户模式后。 使用喜欢的文本编辑器打开 fstab 文件。

    vi /etc/fstab
    
  2. 查看 中 /etc/fstab列出的文件系统。 fstab 文件中的每一行指示 VM 启动时装载的文件系统。 有关 fstab 文件的语法的详细信息,请 man fstab 运行 命令。 若要排查启动失败问题,请查看无法装载的文件系统的条目。 最好查看每一行,以确保它在结构和内容中都正确。 正确管理 fstab 文件需要考虑的几个要点如下:

    • 每行的字段由制表符或空格分隔。 将忽略空行。 具有数字符号 (#) 作为第一个字符的行是注释。 注释的行可以保留在 fstab 文件中,但不会处理它们。 建议对不确定的 fstab 行进行注释,而不是删除这些行。

    • 使用文件系统分区的 UUID 在 Azure VM 上装载数据磁盘。若要确定文件系统的 UUID,请 blkid 运行 命令。 有关语法的详细信息,请 man blkid 运行 命令。 fstab 文件中的 UUID 条目示例:

      UUID=<UUID number here>  /data      xfs    defaults,nofail 0  0
      
    • nofail使用文件系统条目 (数据磁盘) 中的 选项,即使在相应条目的分区中发生错误后,也能继续启动。 选项 nofail 有助于确保即使文件系统已损坏或启动时不存在,VM 也会启动。

  3. 保存对 fstab 文件的更改。

  4. 在对 fstab 条目进行更改后,使用 mount -a 作为最佳做法。 这将重新运行 fstab 配置,并通知用户任何现有语法或条目错误。

  5. 验证语法和条目后,使用以下命令重新启动 vm。

    reboot -f
    
  6. 如果条目注释或修复成功,系统应在门户中到达 bash 提示符。 检查是否可以连接到 VM。

注意

还可以使用“ctrl+x”命令,该命令也会重新启动 vm。

脱机修复 VM

如果 VM 串行控制台访问权限不可用,另一种解决方法是修复 VM 脱机。 有两种方法可以采用脱机方法:

使用 Azure Linux 自动修复 (ALAR)

Azure Linux 自动修复 (ALAR) 脚本是 使用 Azure 虚拟机修复命令修复 Linux VM 中所述的 VM 修复扩展的一部分。 ALAR 涵盖多个修复方案的自动化,包括 /etc/fstab 问题。

ALAR 脚本使用修复扩展 run 命令及其 --run-id 选项。 自动恢复的脚本 ID 为: linux-alar2。 执行以下步骤,通过脱机 ALAR 方法自动执行 fstab 错误:

az vm repair create --verbose -g centos7 -n cent7 --repair-username rescue --repair-password 'password!234' --copy-disk-name  repairdiskcopy
az vm repair run --verbose -g centos7 -n cent7 --run-id linux-alar2 --parameters fstab --run-on-repair
az vm repair restore --verbose -g centos7 -n cent7

注意

资源组名称“centos7、vm 名称”cent7“和 --copy-disk-name”repairdiskcopy“是示例,值需要相应地更改。

fstab 修复脚本将备份原始文件,并去除 /etc/fstab 文件中启动系统不需要的任何行。 成功启动 OS 后,再次编辑 fstab 并更正之前不允许重新启动系统的任何错误。

或者,创建修复 VM 后,还可以通过手动登录到修复 vm、装载 OS 磁盘的附加副本并对其 fstab 文件进行更改来实现更改。 请按照下列步骤操作:

  • 使用 az vm repair create 命令创建修复 VM。
  • 若要将和 chroot 装载到救援 VM 中附加的 OS 磁盘的文件系统,请按照详细的 chroot 说明进行操作
  • 接下来,按照上述 fstab 故障排除步骤进行操作
  • 应用更改后, az vm repair restore 可以使用 命令与原始 VM 执行自动 OS 磁盘交换。

使用手动方法

如果串行控制台和 ALAR 方法都不可行或失败,则必须手动执行修复。 按照此处的步骤手动将 OS 磁盘附加到恢复 VM,并将 OS 磁盘交换回原始 VM:

将 OS 磁盘成功附加到恢复 VM 后,请按照详细的 chroot 说明 装载和 chroot 到附加的 OS 磁盘的文件系统。 然后,实施 fstab 故障排除步骤 ,对有问题的 OS 磁盘的 fstab 文件进行适当的更改。

联系我们寻求帮助

如果你有任何疑问或需要帮助,请创建支持请求联系 Azure 社区支持。 还可以向 Azure 反馈社区提交产品反馈。