☰

我尝试在启动时检查文件系统，但遇到错误，导致 fsck 无法完成

tag-icon • tag-icon debian fsck
我尝试在启动时检查文件系统，但遇到错误，导致 fsck 无法完成

在尝试解决与看似已满的磁盘相关的问题时，我尝试检查 ASUS Tinkerboard 2S (Debian 10) 根目录上的文件系统。

我在日志中遇到以下错误：

systemd-sysctl[195]: Couldn't write 'force' to 'fsck/mode', ignoring: No such file or directory
systemd-sysctl[195]: Couldn't write 'yes' to 'fsck/repair', ignoring: No such file or directory

通过检查上次检查的日期以及tune2fs -l /dev/mmcblk2p9 | grep 'checked\|Maximum\|Mount'显示去年日期的情况可以进一步确认这一点：

Mount count:              172
Maximum mount count:      1
Last checked:             Tue May  3 13:10:09 2022

我该如何纠正这个问题？

答案1

systemd-sysctl的工作是在引导过程的早期运行，读取配置文件并将/etc/sysctl.d其中找到的任何设置写入位于/proc/sys.

但看起来 .中的某些文件中有类似fsck.mode=force和 的设置。这些将分别映射到虚拟文件和......除了文件系统检查工具通常不会有内核组件（并且绝对不会有文件系统！），因此这些设置似乎位于错误的位置。目前我还不能确定这是由于操作员错误还是文件系统损坏造成的。fsck.repair=yes/etc/sysctl.d//proc/sys/fsck/mode/proc/sys/fsck/repairext4

相反，这些设置是有意义的内核启动参数。在 x86 系统上，这些参数可以添加到 的GRUB_CMDLINE_LINUX_DEFAULT=或GRUB_CMDLINE_LINUX=变量中/etc/default/grub。但由于 Tinkerboard 2S 是 ARM 设备，因此它不使用 GRUB，而是使用其他一些引导加载程序......也许u-boot？ （我无法通过快速谷歌搜索找到 Tinkerboard 2S 启动过程的清晰示例。）

如果引导加载程序是u-boot，那么此文档可能或多或少与您在引导过程开始时看到的内容相符：

https://wiki.debian.org/U-boot/#U-boot_prompt.2C_custom_kernel_arguments

简而言之：当您看到Hit any key to stop autoboot:带有 3 秒倒计时的提示时，您应该连接串行控制台并按其上的任意键来访问 u-boot 提示符：=>。

要触发一次性文件系统检查，您需要输入以下命令：

setenv bootargs ${bootargs} fsck.mode=force fsck.repair=yes
boot

重要的是不要直接代替现有的bootargs价值，但添加到它。

saveenv在命令行后使用该命令setenv将使选项持久化（而不是仅一次引导），但您应该首先尝试不使用saveenv，以防文件系统检查出现进一步问题。

答案2

谢谢@telcoM

最后我找到了一种替代方法，它只适用于 Tinkerboard 2S，因为除了 eMMC 存储（我的根所在）之外，该设备还有一个 Micro SD 插槽。使用 Micro SD 插槽时，启动时优先选择此插槽而不是 eMMC

于是我在家里找了一块128GB的Micro SD，刷入了华硕提供的Debian 10。经过一些基本设置后，我能够卸载旧根上的分区并运行fsck

相关内容