先检查mount输出中是否存在ro标志，如/dev/sda1 on /home type ext4 (ro,relatime)，再结合dmesg日志定位真实原因（如ext4-fs error或i/o error），并用smartctl验证磁盘健康状态，最后核对fstab配置是否误设ro或errors=remount-ro。
先看 mount 输出里有没有 ro 标志
运行 mount | grep "ro,"，一眼就能发现哪些挂载点被标为只读。比如输出中出现 /dev/sda1 on /home type ext4 (ro,relatime)，说明 /home 分区当前是只读挂载。注意区分：是整个根分区（findmnt /）只读，还是某个子目录（如 /var/log）只读——这直接影响后续排查范围。
如果只是某一分区显示 ro，但 /etc/fstab 里对应行写的是 defaults 或明确写了 rw，那基本可以排除配置错误，转向内核日志找真实原因。
常见误判点：
- 误以为
cat /proc/cmdline | grep ro有输出就一定是启动参数问题——其实很多发行版默认带ro，靠 initramfs 后续 remount rw，所以单看这一项不能下结论 - 看到
errors=remount-ro出现在mount输出里，说明文件系统此前已出错并被内核强制降级，不是当前挂载时写的参数
dmesg 是唯一可信的“事故报告”
dmesg -T | tail -50 必须第一时间执行。90% 的只读不是配置写错，而是内核在报错后主动 remount ro。关键线索就藏在这里：
- 看到
EXT4-fs error、journal has been aborted、superblock invalid→ 文件系统元数据损坏 - 看到
I/O error、end_request: I/O error、ata1.00: failed command、NVMe timeout→ 硬件或链路问题 - 看到
Remounting filesystem read-only这句话本身，就是内核已触发保护机制的铁证
别等 journalctl ——如果没启用持久日志（/var/log/journal 为空），dmesg 就是唯一能回溯的现场记录。缓存容易刷掉，故障刚发生时就得抓。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
smartctl 能快速分清“该修 fs 还是该换盘”
运行 smartctl -a /dev/sdX（把 sdX 换成实际设备，如 sda），重点盯三列：
-
Reallocated_Sector_Ct：非零且持续上涨 → 物理坏道已激活 -
Current_Pending_Sector：大于 0 → 有扇区读不出，正等着重映射，非常危险 -
UDMA_CRC_Error_Count（SATA）或Media_Wearout_Indicator（SSD）异常 → 数据线松动或 SSD 寿命见底
只要其中任意一项亮红灯，就别碰 fsck，立刻停写、备份、换盘。强行修复可能让 pending sector 变成 reallocated，进一步丢失数据。
fstab 和 errors=remount-ro 配置要人工核对
运行 grep -v "^#" /etc/fstab | grep -E "(ro|errors=)"，检查有没有人为误配：
- 第四列写死
ro：直接改rw，然后mount -o remount,rw /mount/point - 写了
errors=remount-ro但没配data=ordered或其他 journal 相关选项：ext4 在 journal 异常时会立即触发只读，这种配置在老旧系统上很常见 - UUID 或设备名写错，导致挂载时 fallback 到只读行为（部分 initramfs 实现）
改完 /etc/fstab 后别忘了 mount -a 测试语法，否则下次重启可能卡住。
真正棘手的情况，往往不是 ro 出现在 fstab 里，而是 dmesg 里反复出现 I/O error，但 smartctl 又看不出明显异常——这时候得怀疑背板、RAID卡、NVMe 驱动或虚拟化存储后端抖动，不是单靠 Linux 命令能定位的。
