3. 启动挂载失败现象分析：系统卡在启动界面、进入紧急模式、只读文件系统挂载

启动挂载失败，说白了就是系统在开机时找不到该找的盘，或者盘找到了但读写权限不对。我这些年排查过不下百例这类问题，现象就那么几种，但背后的原因却五花八门。今天咱们就把这三种典型现象掰开揉碎了讲清楚。

3.1 系统卡在启动界面

这是最让人头疼的一种。屏幕上一个 logo 转圈圈，转啊转，就是进不去系统。你按什么键都没反应，只能硬重启。

为什么会这样？

我个人的经验是，这种情况多半出在 根文件系统（/） 的挂载上。系统在 initramfs 阶段尝试挂载根分区，如果挂不上，它就会一直重试，直到超时。超时之后呢？不同发行版表现不一样：

• CentOS 7 / RHEL 7： 默认会等待 90 秒，然后进入紧急模式
• Ubuntu 18.04+： 会显示一个「A start job is running for ...」的提示，倒计时 90 秒
• Debian： 可能直接卡住，连倒计时都不给你看

我记得有一次帮客户排查，一台 CentOS 7 的服务器每次重启都卡在启动界面。我远程连上 IPMI 一看，屏幕就一个 logo 在转。等了 90 秒，果然跳到了紧急模式。进去一看 /etc/fstab，里面挂了一个 NFS 共享，但网络还没起来——典型的顺序依赖问题。

3.2 进入紧急模式（Emergency Mode）

紧急模式，是系统给你的「最后一道防线」。它给你一个 root shell，但只挂载了最基本的文件系统——通常是只读的根文件系统，外加 /proc、/sys、/dev 这些虚拟文件系统。

进入紧急模式的原因，我总结下来主要有三类：

原因类别	典型场景	排查方向
fstab 配置错误	UUID 写错、设备路径不对、挂载选项语法错误	检查 /etc/fstab，用 blkid 核对 UUID
磁盘/设备不可用	硬盘故障、USB 盘被拔掉、iSCSI 目标离线	看 dmesg 日志，检查设备是否存在
文件系统损坏	意外断电导致超级块损坏、日志回放失败	用 fsck 修复，必要时用备用超级块

进入紧急模式后，你第一件事该做什么？我建议按这个顺序来：

1. 先看 /etc/fstab —— 用 cat /etc/fstab 检查每一行。注意看有没有 nofail 选项。如果某个分区挂了 nofail，挂载失败不会导致紧急模式，系统会跳过它。
2. 检查 dmesg 日志 —— 用 dmesg | grep -i error 或者 dmesg | grep -i mount。错误信息通常会直接告诉你哪个设备出了问题。
3. 手动挂载试试 —— 比如 mount /dev/sdb1 /mnt，看报什么错。这一步能帮你快速区分是设备问题还是配置问题。

3.3 只读文件系统挂载

这种最隐蔽。系统能正常启动，你能登录进去，看起来一切正常。但你想写个文件，或者 touch 一下，系统告诉你：Read-only file system。

为什么会以只读方式挂载？

说白了，这是系统的一种自我保护机制。当内核检测到文件系统有严重错误时，它会自动以只读方式重新挂载，防止进一步损坏数据。我遇到过几种常见情况：

• 文件系统日志损坏： 意外断电后，日志里记录了未完成的事务，但回放时发现不一致
• 磁盘硬件错误： 硬盘出现了坏道，写操作失败，内核把文件系统标记为只读
• 挂载选项指定了 ro： 有人在 /etc/fstab 里写错了，把 rw 写成了 ro

我曾经处理过一个案例：一台数据库服务器，运行了两年多一直正常。突然有一天，DBA 说写不了数据了。我上去一看，/data 分区是只读的。查 dmesg 发现大量 I/O error，再用 smartctl 一查，硬盘的 Reallocated_Sector_Ct 已经爆表了。赶紧让客户换盘——数据虽然没丢，但再拖下去就不好说了。

3.4 三种现象的关联与排查路径

这三种现象其实是一条线上的三个节点。我画了一张图，帮你理清它们之间的关系：

从图上你能看出来，这三种现象不是孤立的。同一个根因，在不同阶段会表现出不同的症状。比如一个错误的 fstab 条目：如果它影响的是根分区，系统可能直接卡在启动界面；如果影响的是非关键分区，系统会进入紧急模式；如果文件系统只是轻微损坏，系统可能以只读方式挂载它，让你「能用但写不了」。

我个人习惯是，遇到启动问题先看现象属于哪一类，然后按图索骥。卡界面就先等 90 秒看它跳不跳紧急模式；进了紧急模式就先看 fstab 和 dmesg；只读挂载就先查硬件健康状态。这套流程走下来，90% 的问题都能定位到根因。