RK3588 文件系统只读问题排查与修复

一、问题现象

1.1 初始表现

在 Orange Pi 5 Plus（RK3588）上执行文件操作时，出现以下错误：

# scp 传输文件失败scp-rE:\k73588\qt\QTrackerSerialTest202512-6 orangepi@192.168.1.238:/home/orangepi/# 错误：stat remote: No such file or directory# mv 移动文件失败mv/tmp/QTrackerSerialTest202512-6 ~/# 错误：inter-device move failed; unable to remove target: Read-only file system# cp 复制文件失败cp-r/tmp/QTrackerSerialTest202512-6 ~/# 错误：cannot create directory: Read-only file system# remount 重挂载失败sudomount-oremount,rw /# 错误：cannot remount /dev/mmcblk1p2 read-write, is write-protected

1.2 核心症状

二、问题诊断

2.1 检查磁盘空间

df-h/

输出：

Filesystem Size Used Avail Use% Mounted on /dev/mmcblk1p2 28G 27G 883M 97% /

结论：磁盘使用率 97%，空间严重不足。

2.2 检查文件系统挂载状态

mount|grep" / "

输出：

/dev/mmcblk1p2 on / type ext4 (ro,relatime,...)

结论：根目录被挂载为ro（只读模式）。

2.3 检查系统日志（关键步骤）

sudodmesg|grep-i"mmcblk\|write-protect\|readonly\|I/O error"

关键日志输出：

[ 6.893558] EXT4-fs (mmcblk1p2): re-mounted. Opts: commit=600,errors=remount-ro [ 130.648174] EXT4-fs error (device mmcblk1p2): ext4_mb_generate_buddy:802: group 159, block bitmap and bg descriptor inconsistent: 378 vs 377 free clusters [ 130.654856] Aborting journal on device mmcblk1p2-8. [ 130.660925] EXT4-fs (mmcblk1p2): Remounting filesystem read-only [ 130.664934] EXT4-fs (mmcblk1p2): failed to convert unwritten extents to written extents -- potential data loss! (inode 787013, error -30)

2.4 诊断结论

根本原因：

ext4 文件系统的块位图（block bitmap）与块组描述符（bg descriptor）数据不一致，触发文件系统自我保护机制，自动转为只读模式。

挂载参数errors=remount-ro配置了：当检测到错误时，自动将文件系统重挂载为只读，防止数据进一步损坏。

三、问题修复

方案1：重启并自动修复（最简单）

# 方法1：创建强制检查标志（可能因只读失败）sudotouch/forcefsck# 方法2：强制重启sudoreboot-f

重启后系统可能自动执行 fsck 修复。

方案2：单用户模式修复（推荐）

步骤1：重启进入单用户模式

在 U-Boot 启动阶段，编辑启动参数，添加：

init=/bin/sh

步骤2：修复文件系统

# 以只读方式重挂载根目录mount-oremount,ro /# 执行文件系统检查与修复fsck.ext4-f-y/dev/mmcblk1p2# 修复完成后重启reboot-f

方案3：从 TF 卡启动修复（最可靠）

步骤1：制作启动 TF 卡

1. 在 Windows 上烧录一个 Ubuntu/Debian 系统到 TF 卡
2. 将 TF 卡插入板子
3. 从 TF 卡启动

步骤2：修复 eMMC 文件系统

# 查看 eMMC 设备lsblk# 确认 eMMC 设备名，如 /dev/mmcblk1# 卸载 eMMC（如果被自动挂载）sudoumount/dev/mmcblk1p2# 执行文件系统修复sudofsck.ext4-f-y/dev/mmcblk1p2# 修复完成后重启sudoreboot# 拔掉 TF 卡，从 eMMC 启动

方案4：使用 rkdeveloptool 修复（终极方案）

如果以上方法都无法修复，使用 Rockchip 工具重新烧录：

# 进入 MaskROM 模式（短接 eMMC 引脚）# 使用 rkdeveloptool 烧写完整镜像rkdeveloptool db MiniLoaderAll.bin rkdeveloptool wl 0x0 update.img rkdeveloptool rd

四、修复后验证

4.1 验证文件系统状态

# 检查挂载模式（应该是 rw）mount|grep" / "# 期望输出：/dev/mmcblk1p2 on / type ext4 (rw,...)# 测试写入touch~/test.txt&&echo"写入成功"&&rm~/test.txt

4.2 检查系统日志

# 确认无新错误sudodmesg|grep-i"ext4\|error"|tail-20

4.3 清理磁盘空间（重要！）

# 清理 apt 缓存sudoaptcleansudoaptautoremove-y# 清理系统日志sudojournalctl --vacuum-time=3d# 清理用户缓存rm-rf~/.cache/*# 查看清理后的空间df-h/

五、数据备份（修复前必须执行）

文件系统只读时，数据仍可读取，请先备份重要数据：

# 在 Windows PowerShell 中执行# 备份整个家目录scp-r orangepi@192.168.1.238:/home/orangepi E:\backup\# 备份特定目录scp-r orangepi@192.168.1.238:/home/orangepi/项目文件 E:\backup\

或打包后传输（更高效）：

# 在板子上打包sshorangepi@192.168.1.238tarczf /tmp/backup.tar.gz ~/重要目录exit# 在 Windows 上下载scporangepi@192.168.1.238:/tmp/backup.tar.gz E:\backup\

六、预防措施

6.1 磁盘空间管理

# 定期检查磁盘空间df-h# 保持 20% 以上空闲空间# 设置监控告警（可选）echo' #!/bin/bash USAGE=$(df / | tail -1 | awk "{print \$5}" | tr -d "%") if [ $USAGE -gt 80 ]; then echo "磁盘使用率过高: ${USAGE}%" | mail -s "磁盘告警" admin@example.com fi '|sudotee/usr/local/bin/disk_alert.shsudochmod+x /usr/local/bin/disk_alert.sh# 添加到 crontab 定时检查echo"0 8 * * * /usr/local/bin/disk_alert.sh"|sudotee-a/etc/crontab

6.2 正常关机

# 避免直接拔电源，使用正常关机命令sudoshutdown-hnow# 或sudopoweroff

6.3 定期文件系统检查

# 每月执行一次文件系统检查sudotouch/forcefscksudoreboot

6.4 减少写入操作

# 将日志目录挂载为 tmpfs（内存文件系统）echo"tmpfs /var/log tmpfs defaults,size=100M 0 0"|sudotee-a/etc/fstab# 将临时目录挂载为 tmpfsecho"tmpfs /tmp tmpfs defaults,size=500M 0 0"|sudotee-a/etc/fstab

七、问题排查流程图

┌─────────────────────────────────────────────────────┐ │ 文件操作失败（Read-only file system） │ └──────────────────────────┬──────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────┐ │ 步骤1：检查磁盘空间 │ │ df -h / │ │ → 使用率是否 > 90%？ │ └──────────────────────────┬──────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────┐ │ 步骤2：检查系统日志 │ │ sudo dmesg | grep ext4 │ │ → 是否有 EXT4-fs error？ │ └──────────────────────────┬──────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────┐ │ 步骤3：备份重要数据（只读模式下仍可读取） │ │ scp -r orangepi@IP:/home/orangepi E:\backup\ │ └──────────────────────────┬──────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────┐ │ 步骤4：尝试修复 │ │ 方案1：sudo reboot -f（重启自动修复） │ │ 方案2：单用户模式 fsck.ext4 -f -y /dev/mmcblk1p2 │ │ 方案3：从 TF 卡启动修复 │ │ 方案4：重新烧录镜像 │ └──────────────────────────┬──────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────┐ │ 步骤5：验证修复结果 │ │ mount | grep " / " → 确认是 rw │ │ touch ~/test.txt → 确认可写入 │ └──────────────────────────┬──────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────┐ │ 步骤6：清理磁盘空间并设置预防措施 │ │ sudo apt clean && sudo apt autoremove -y │ │ 保持 20% 以上空闲空间 │ └─────────────────────────────────────────────────────┘

八、常见问题

Q1：fsck 修复后问题反复出现？

A：可能是 eMMC 存在物理坏块。建议：

1. 低级格式化 eMMC
2. 重新烧录完整镜像
3. 如仍无法解决，联系售后更换 eMMC

Q2：如何判断是硬件故障还是软件故障？

A：查看系统日志：

• EXT4-fs error→ 软件故障（文件系统损坏）
• I/O error/mmcblk1: recovery?→ 硬件故障（eMMC 损坏）

Q3：修复后数据会丢失吗？

A：fsck 修复通常不会丢失数据。但如果文件系统严重损坏，可能会：

• 将损坏的文件放入lost+found目录
• 删除无法修复的文件

因此修复前必须先备份数据。

Q4：scp 传输到 /home/orangepi/ 失败，但传输到 /tmp/ 成功？

A：这是 Windows OpenSSH 客户端的路径解析问题：

• 末尾带/的路径可能解析失败
• 建议去掉末尾/，或使用~，或使用/tmp/中转

九、关键命令速查