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

项目
07/30/2024

适用于：✔️ Linux VM

注意

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

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

下面列出了导致虚拟机启动问题的常见原因：fstab 配置错误导致虚拟机启动问题：

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

确定 fstab 问题

在Azure 门户的 [启动诊断] （/azure/virtual-machines/boot-diagnostics#boot-diagnostics-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
- 使用串行控制台
脱机修复 VM
- 使用 Azure Linux 自动修复（ALAR）
- 使用 Manual 方法

联机修复 VM

使用串行控制台

从 Azure 门户连接到 VM 的串行控制台。
需要手动访问单个用户模式才能重新配置 fstab。这些步骤可能因所用 Linux OS 的类型和对根帐户的访问权限而异。按照单用户模式文档访问每个受支持的 Linux 合作伙伴映像的单用户模式。

Fstab 故障排除步骤

VM 启动到单个用户模式后。使用你喜欢的文本编辑器打开 fstab 文件。
```
vi /etc/fstab
```
在 . 中 /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 也会启动。
保存对 fstab 文件的更改。
在对 fstab 条目进行更改后，请 mount -a 将其用作最佳做法。这将重新运行 fstab 配置，并通知用户任何现有的语法或条目错误。
验证语法和条目后，使用以下命令重新启动 VM。
```
reboot -f
```
如果条目注释或修复成功，系统会在门户中出现 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。
若要将附加 OS 磁盘的文件系统装载和 chroot 装载到救援 VM 中的文件系统，请按照详细的 chroot 说明进行操作。
接下来，按照与上述相同的 fstab 故障排除步骤操作。
应用更改后， az vm repair restore 可以使用命令与原始 VM 执行自动 OS 磁盘交换。

使用 Manual 方法

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

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

联系我们寻求帮助

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

通过