本文涉及的 hostname 和 uuid 进行了脱敏替换
有一台云服务器因欠费停机，在续费手动重启后，未能正常进入操作系统，陷入了 emergency mode。
通过 journalctl -xb 检索 fail 关键字，发现启动序列发生了连锁崩塌。所有的错误都指向同一个源头：系统无法将 UUID=9e73c882-***-8280ed0187d7 的磁盘分区（/dev/vdb1）挂载到 /opt 目录，连带 local-fs.target 等 target 启动失败，导致 Systemd 判定环境未就绪，强制中断引导。
执行 lsblk -f，磁盘 /dev/vdb 及其分区 /dev/vdb1 依然存在。
查看云监控，数据盘甚至还有读写操作。
检查 mount unit 状态，查看依赖关系，没有发现可疑的地方。
systemctl status opt.mount
systemctl list-dependencies --reverse opt.mount
先排除这个分区，看看系统有没有其他问题，修改 /etc/fstab：
# UUID=9e73c882-***-8280ed0187d7 /opt ext4 defaults 0 2
UUID=9e73c882-***-8280ed0187d7 /opt ext4 defaults,nofail,x-systemd.automount 0 2
nofail即便挂载失败也允许系统继续引导x-systemd.automount将实际挂载推迟到首次访问/opt时
现在系统可以正常启动了，但是任何试图访问 /opt 或其父目录的尝试都将卡住进程直到访问超时。
尝试手动挂载， mount /dev/vdb1 /opt，成功。
接下来解决为什么自动挂载失败，Gemini 说：
注意到你刚才贴出的 lsblk 输出： 9e73c882-a1fd-4f9d-a634-8280ed0187d7 而你最开始 fstab 里写的（或我回复里引用的）是： 9e73c882-a1fd-4f9f-a634-8280ed0187d7
所以 Systemd 一直在等待那个“永远不会出现”的设备，排除人工复制错误，那只能怪宇宙射线或者 Cloud-init 了。