通过

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

适用于：✔️ Linux VM

备注

本文中引用的 CentOS 是 Linux 分发版，将达到生命周期结束（EOL）。 请相应地考虑使用和规划。 有关详细信息，请参阅 CentOS 生命周期指南。

总结

Linux 文件系统表 fstab 是一个配置表，旨在配置在系统启动过程中以有序方式检测和装载特定文件系统的规则。

本文讨论多个条件，其中错误 fstab 配置可能导致启动问题并提供故障排除指南。

下面是一些常见原因，可能会导致虚拟机（VM）启动问题，因为 fstab 配置错误：

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

确定 fstab 问题

在 Azure 门户的 Boot diagnostics 页中的串行日志内检查 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 是使用的装入点的示例。 文件系统装载点的依赖失败情况会因所用名称而有所不同。

解决方案

可通过两种方式解决此问题：

联机修复 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。 有两种方法可以采用脱机方法：

使用 Azure Linux 自动修复 （ALAR）

在 Linux 中运行

Azure Linux 自动修复（ALAR）脚本是 使用 Azure Linux 自动修复（ALAR）中介绍的 VM 修复扩展的一部分。 ALAR 涵盖了多个修复方案的自动化，包括 /etc/fstab 问题。

ALAR 脚本使用修复扩展 repair-button 通过指定 --button-command fstab来修复 fstab 问题。 此参数触发自动恢复。 实现以下步骤，通过脱机 ALAR 方法自动处理 fstab 错误：

az extension add -n vm-repair
az extension update -n vm-repair
az vm repair repair-button --button-command 'fstab' --verbose --resource-group $RGNAME --name $VMNAME

备注

相应地替换资源组名称 $RGTEST 和 VM 名称 $VMNAME。

  • 修复 VM 脚本与 ALAR 脚本结合使用，将临时创建资源组、修复 VM 和受影响 VM OS 磁盘的副本。 它备份原始文件 /etc/fstab ，并通过删除或注释掉不需要用于启动系统的数据文件系统条目来修改该文件。
  • 成功启动 OS 后，查看并编辑 /etc/fstab 文件以修复可能阻止正确重新启动的任何错误。
  • 最后，脚本 repair-button 将自动删除包含修复 VM 的资源组。

使用手动方法

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

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

  • Last updated on