更新中にシステムを強制終了したときにこの問題が発生しました。その後、grubの起動パラメータを「ro」から「rw」に変更しなければ起動できませんでした。その後、起動するたびにfsckを実行すると、次の出力が表示されます。
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
ファイルシステムを回復するにはどうすればよいですか？
答え1
UEFIを持つシステムがある可能性があり、エラーメッセージはESP（EFIシステムパーティション）のFAT32ファイルシステムの「ダーティビット」に関連しています。通常、このパーティションはマウントされますが、一部のディストリビューションでは、カーネルおよび/またはブートローダが実際に更新されない限り、他の場所/boot/efi（おそらく）にマウントまたは完全にアンマウントします。/boot
ダーティビットfsck.vfat（FAT32ファイルシステムでも使用）をリセットすると確かに効果があります。ただし、一部のバージョンでは、変更をファイルシステムに実際に記録するオプションが必要です。fsck.vfat特定のバージョンに適用される詳細については、マニュアルページを参照してください。
簡単にESPファイルシステムをアンマウントして確認できます。インストール中にFAT32ファイルシステムを確認しないでください。そうしないと、ファイルシステムにアクセスすると、カーネルのファイルシステムドライバが「ダーティビット」を上書きします。
起動パラメータをからに変更すると、roシステムrwの別の問題が隠れることがあります。確認する他のファイルシステムがある可能性があります。たぶんルートファイルシステムですか？
起動プロセスが中断され、テキストモードのコマンドプロンプトが表示された場合正確に汎用ユーティリティがまだ書き込みを許可していないルートパーティションでファイルシステムチェックを実行できます。これは、他のメディアからシステムを最初に起動せずにルートパーティションでファイルシステムチェックを実行する唯一の方法です。
ルートファイルシステムでスキャンを実行してファイルシステムを変更した場合は、スキャンが完了するとすぐに再起動する必要があります。カーネルは、変更前に読み取られた一部のブロックがまだメモリにキャッシュされている可能性があり、ルートファイルシステムが再起動なしで書き込み可能として再マウントされると、そのブロック（およびその中のエラー）がすぐに削除される可能性があります。ディスクに書き換えることができます。
答え2
RHEL 7の場合、以下を行いました。
ディスクを一覧表示します。
df -h
または
lsblk
回復するディスクをアンマウントするには（以下の例では/ dev / sda1）：
umount /dev/sda1
ダーティビットをクリアしてディスクを回復するには：
fsck /dev/sda1 -a -w
注：上記のコマンドはfsck.vfatであり、fatに適しています。ファイルシステムによっては、異なるバージョンのfsckが実行され、異なるパラメータが必要になる可能性があります。 fsck.vfatでは、-aは自動回復のためのものであり、-wは変更を即座に書き込むことです。
ディスクを再マウントします。
mount /dev/sda1
システムを再起動します。
systemctl reboot
そうでなければ
reboot