起動時にファイルシステムを確認しようとしましたが、エラーが発生して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? (クイックGoogle検索では、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のマイクロSDを見つけて、ASUSが提供するDebian 10をフラッシュしました。いくつかのデフォルト設定が完了したら、以前のルートでパーティションをアンマウントして実行できました。fsck

関連情報