我正在尝试在e2fsck启动持久实时 lubuntu 时运行该程序来修复可写系统分区（ext4）的“损坏的文件系统”错误，我想以某种方式自动执行此操作（因此理想情况下我不想启动到另一个实时 usb 来执行此操作）
我想实现自动化，因为这些错误往往会随着系统重启/关闭而累积（我确实按照说明操作，移除系统所在的 USB 记忆棒，然后在关机/重启时按 Enter）。经过几个月的使用（可能关机 100 次），错误确实累积了很多，以至于系统无法启动。
我确实通过启动另一个实时系统然后运行来修复了错误：
umount -l /dev/sdc5
e2fsck -y /dev/sdc5
/dev/sdc5 是安装在 /media/lubuntu/writable 上的系统的可写分区
为了使将来实现自动化，我尝试通过以下方式修复同一存储介质中的错误：
- 启动到恢复模式，但
e2fsck返回“目标正忙”，因此延迟卸载不成功。 - 点击
eGRUB 菜单并编辑fsck.mode=none然后fsck.mode=force启动（Ctrl+x/f10）但它并没有修复错误。 fsck通过更改最大安装数量来强制启动，sudo tune2fs -c -1 /dev/sdb5但它并没有修复错误
我不确定在最后两种情况下 fsck 是否运行过，而且我不知道如何找出答案，我尝试读取 /var/log 中几个日志的内容，但没有找到关于它的提及
我的实时系统是使用 mkusb 和 lubuntu 22.04.3 iso 制作的，欢迎任何帮助
答案1
@sudodus 在评论中回答了这个问题。我将在这里总结一下：
- 运行没有挂载可写日志分区的实时 lubuntu：
在 mkusb 制作的 GRUB 菜单中，突出显示
live选项，按，用e替换内联文本，然后使用或启动。quiet splashnopersistent toramf10Ctrl+X - 启动时，卸载
writable分区（例如通过 KDE 分区管理器 GUI），然后在终端运行sudo e2fsck -f /dev/sdXN（sdXN 是可写分区，例如 sdc5）
另一个可能的解决方案：为系统使用更高质量的存储介质，以防止错误随着时间的推移而累积（未经测试）