
RK3588 文件系统只读问题排查与修复一、问题现象1.1 初始表现在 Orange Pi 5 PlusRK3588上执行文件操作时出现以下错误# scp 传输文件失败scp-rE:\k73588\qt\QTrackerSerialTest202512-6 orangepi192.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-protected1.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-immcblk\|write-protect\|readonly\|I/O error关键日志输出[ 6.893558] EXT4-fs (mmcblk1p2): re-mounted. Opts: commit600,errorsremount-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 诊断结论检查项结果说明硬件识别✅ 正常eMMC 57.6 GiB 识别正常磁盘空间⚠️ 不足使用率 97%仅剩 883M文件系统❌ 损坏ext4 块位图元数据不一致挂载模式❌ 只读自动转为只读保护数据根本原因ext4 文件系统的块位图block bitmap与块组描述符bg descriptor数据不一致触发文件系统自我保护机制自动转为只读模式。挂载参数errorsremount-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 卡在 Windows 上烧录一个 Ubuntu/Debian 系统到 TF 卡将 TF 卡插入板子从 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 验证文件系统状态# 检查挂载模式应该是 rwmount|grep / # 期望输出/dev/mmcblk1p2 on / type ext4 (rw,...)# 测试写入touch~/test.txtecho写入成功rm~/test.txt4.2 检查系统日志# 确认无新错误sudodmesg|grep-iext4\|error|tail-204.3 清理磁盘空间重要# 清理 apt 缓存sudoaptcleansudoaptautoremove-y# 清理系统日志sudojournalctl --vacuum-time3d# 清理用户缓存rm-rf~/.cache/*# 查看清理后的空间df-h/五、数据备份修复前必须执行文件系统只读时数据仍可读取请先备份重要数据# 在 Windows PowerShell 中执行# 备份整个家目录scp-r orangepi192.168.1.238:/home/orangepi E:\backup\# 备份特定目录scp-r orangepi192.168.1.238:/home/orangepi/项目文件 E:\backup\或打包后传输更高效# 在板子上打包sshorangepi192.168.1.238tarczf /tmp/backup.tar.gz ~/重要目录exit# 在 Windows 上下载scporangepi192.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 磁盘告警 adminexample.com fi |sudotee/usr/local/bin/disk_alert.shsudochmodx /usr/local/bin/disk_alert.sh# 添加到 crontab 定时检查echo0 8 * * * /usr/local/bin/disk_alert.sh|sudotee-a/etc/crontab6.2 正常关机# 避免直接拔电源使用正常关机命令sudoshutdown-hnow# 或sudopoweroff6.3 定期文件系统检查# 每月执行一次文件系统检查sudotouch/forcefscksudoreboot6.4 减少写入操作# 将日志目录挂载为 tmpfs内存文件系统echotmpfs /var/log tmpfs defaults,size100M 0 0|sudotee-a/etc/fstab# 将临时目录挂载为 tmpfsechotmpfs /tmp tmpfs defaults,size500M 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 orangepiIP:/home/orangepi E:\backup\ │ └──────────────────────────┬──────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────┐ │ 步骤4尝试修复 │ │ 方案1sudo 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% 以上空闲空间 │ └─────────────────────────────────────────────────────┘八、常见问题Q1fsck 修复后问题反复出现A可能是 eMMC 存在物理坏块。建议低级格式化 eMMC重新烧录完整镜像如仍无法解决联系售后更换 eMMCQ2如何判断是硬件故障还是软件故障A查看系统日志EXT4-fs error→ 软件故障文件系统损坏I/O error/mmcblk1: recovery?→ 硬件故障eMMC 损坏Q3修复后数据会丢失吗Afsck 修复通常不会丢失数据。但如果文件系统严重损坏可能会将损坏的文件放入lostfound目录删除无法修复的文件因此修复前必须先备份数据。Q4scp 传输到 /home/orangepi/ 失败但传输到 /tmp/ 成功A这是 Windows OpenSSH 客户端的路径解析问题末尾带/的路径可能解析失败建议去掉末尾/或使用~或使用/tmp/中转九、关键命令速查用途命令检查磁盘空间df -h /检查挂载状态mount | grep / 检查系统日志sudo dmesg | grep ext4重挂载为读写sudo mount -o remount,rw /修复文件系统sudo fsck.ext4 -f -y /dev/mmcblk1p2强制重启sudo reboot -f清理磁盘sudo apt clean sudo apt autoremove -y备份数据scp -r orangepiIP:/path E:\backup\