我遇到这个问题已经很长时间了，并尝试了不同的解决方案来解决这个问题，但无法找到文件系统损坏的根本原因。
我在 Advantech IoT 网关中安装了 Ubuntu OS 22.04，它目前位于距我 300 英里的站点（远程）。无法手动执行 sudo fsck /dev/mmcblk0p2。因此，我查看了几篇帖子，发现其中一篇指出，每次设备重新启动时都可以自动执行此文件检查，但重新启动时它不应该转到 initramfs 页面，因此我可能需要去现场进行手动 fsck。
简而言之，我遵循了以下步骤，以便每次断电/重启时都会进行文件检查并自动执行 fsck：使固定（我无法复制该问题来交叉检查它是否有效）：在 /etc/default/grub 中 GRUB_CMDLINE_LINUX_DEFAULT="quiet fsck.mode=force fsck.repair=yes" sudo update-grub sudo tune2fs -l /dev/mmcblk0p2 | grep 'Maximum mount' sudo tune2fs -c 1 /dev/mmcblk0p2
但现在我遇到一种情况，设备通常处于在线状态，我可以在 teamviewer 中看到，但我无法控制设备中的任何内容，因为有些文件已损坏。我们只是使用该设备收集 IoT 数据，并将数据发送到 thingsboard 云。所以一切正常，但我们遇到的情况是，我们需要控制电池或任何设备，然后，我们需要通过 teamviewer 或 remotessh 进入设备，然后执行一些 python 脚本。此时我们看到系统已进入只读模式，我们无法更新任何内容。
现在这又回到了场景 1，我需要手动执行 fsck 或重新启动，如果我重新启动并且修复到位，我不确定它是否会通过 initramfs 屏幕。如果它再次进入此屏幕，那将是一个问题。
所以这次我执行了 sudo fsck /dev/mmcblk0p2 并手动修复了所有节点。但它要求再次重新启动设备。我们怎么确定它不会进入 initramfs 页面。
以及如何找出导致磁盘损坏的根本原因？是否有解决方案可以在设备损坏后立即找出原因，如果我重新启动系统，修复是否有效，这是正确的修复方法吗？
我已经收集了系统和 dmesg 日志以备不时之需。