来源与分类
问题元数据
- 问题编号：TIC-6250、ZSV-12865
- 组件/产品：ZVF ZSphere
- 状态：写入端已有修复代码；当前证据不足以将 5.0.2/OEM 标记为已修复，存量清理另行跟踪
- 报告/受影响版本：5.0.2、5.1.0
- 最后更新时间：2026-09-02
问题描述
通过图形化添加存储并选择“空闲盘”时，后端会格式化并挂载块设备，同时写入 /etc/fstab。旧实现对普通设备写入 defaults，对多路径设备写入 defaults,_netdev,x-systemd.device-timeout=10，均缺少 nofail；当设备缺失或未及时就绪时，systemd 会等待必要挂载并阻塞 local-fs.target。此外，删除数据存储未必同步卸载并清理原条目，残留 UUID 在后续拔盘、换盘或重新格式化后也会触发同一故障。
这里有三个需要分开的分支：旧构建可能直接写 /dev/sdX 或 /dev/vdX；UUID 在 blkid 中不存在表示残留/设备已变；UUID 存在且挂载点正确但仍阻塞，才符合缺少 nofail 的容错问题。不能只看到 Emergency Mode 就统一修改挂载参数。
现象
- 添加存储并选择“空闲盘”后，主机
/etc/fstab新增一行；若只填写已有挂载路径、不选择空闲盘，则该流程不写入 fstab。 - 设备被拔出、替换、未及时发现或数据存储删除后，主机重启无法正常进入系统。
- Emergency shell 或启动日志显示
local-fs.target、挂载超时或设备不存在。
影响
主机无法完成启动，其上的虚拟机和存储访问随之受影响。直接删除 fstab 行可能使仍在使用的本地盘或数据存储在下次启动时不再挂载；只给新条目增加 nofail 也不会自动清理历史残留条目。
规避方案
- 在故障主机的控制台或恢复环境执行以下只读采集，并保存完整输出；不要先删除 fstab 条目：
cat /etc/fstab
blkid
lsblk -f
findmnt --verify --verbose
journalctl -xb -1 -p err --no-pager | tail -80- 判读时逐条记录 fstab 的设备标识、挂载点和选项：设备名条目要核对当前设备枚举；
UUID=条目要在blkid中找到同一 UUID；UUID 存在时还要核对文件系统、挂载点和数据存储归属。预期findmnt --verify --verbose不报告设备缺失或语法错误；若它指向目标 ZStack 条目，才进入修复。 - 支持协助方案：由 ZStack 技术支持与存储管理员先生成
/etc/fstab的可恢复备份，再只处理已经确认的目标条目。仍有效但需要启动容错的条目补充nofail；设备已永久移除且平台资源也已删除的残留条目才移除。不得改动系统根分区、/boot或归属不明的挂载项。 - 修改后再次运行
findmnt --verify --verbose，确认目标 UUID、挂载点和选项正确，再在维护窗口重启。预期主机越过local-fs.target并正常连接 ZSphere；若校验仍报错、目标盘未挂载或文件系统异常，立即恢复备份并停止重启尝试。 - 新建存储时的临时自助规避是“不选择空闲盘，只使用已经由管理员正确挂载的路径”；代价是不能由该流程直接使用整块裸盘。该方式不修复历史 fstab 条目。
- 验证标准：
findmnt --verify --verbose无目标条目错误，维护窗口重启后主机正常进入系统并连接 ZSphere，所有应保留的文件系统仍挂载到原路径；任一项不满足即恢复 fstab 备份并停止。
受影响产品
- ZVF ZSphere：5.0.2、5.1.0
- 部署形态和依赖组件：使用主机本地块设备或多路径块设备并由 ZSphere 写入
/etc/fstab的主机；未使用该挂载机制时不适用。
修复状态
- 当前状态：ZSV-12865 已有写入端修复代码；当前证据未证明该修复已进入客户 5.0.2 或 Nexa虚拟机 OEM 交付，因此这些构建不能标记为已修复。存量条目清理由 ZSV-9315 单独跟踪。
- 修复版本：Jira 记录的目标版本为 5.2.0；本地仓库可见修复曾合入
zsv_5.1.1代码线，但这不能证明任意 5.1.1/5.0.2 交付包都已包含。应按客户完整版本串和包提交确认。 - 关联缺陷/修复记录：ZSV-12865 增加
nofail与 device timeout；ZSV-9315 跟踪卸载/删除时清理 fstab。