fsckはfsckを実行しません（スーパーブロックフラグを設定できません）

SDカードベースのデバイスでのクリーンでないシャットダウンに続いて、SDカードをfsckルートファイルシステムに取り出しました。これにより、以下のバリエーションが生まれました。

e2fsck 1.43.1 (08-Jun-2016)
/dev/sdc2: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? no
Clear journal<y>? no
e2fsck: unable to set superblock flags on /dev/sdc2

ここでは両方とも「いいえ」と答えましたが、すぐに同じ結果につながらないはい/いいえのシーケンスはありません。

ファイルシステムはマウントすることができ、何気ない検査で大丈夫に見えます。これはデバイスでも正常に動作し、それがルートファイルシステムです（実際には、それほどうまくいかないことが判明しました。コメントを参照してください。回復不能な破損ディレクトリがいくつかあります）。

私はdd「ファイルへのパーティション（8ギガバイト）をD、およびその上でfsckを試してみました。興味深いことに：

e2fsck 1.43.1 (08-Jun-2016)
plush.rootfs: recovering journal
Clearing orphaned inode 18290 (uid=0, gid=0, mode=0100644, size=34096)
Clearing orphaned inode 18270 (uid=0, gid=0, mode=0100644, size=38916)
Clearing orphaned inode 18250 (uid=0, gid=0, mode=0100644, size=1128076)
Clearing orphaned inode 11411 (uid=0, gid=0, mode=0100644, size=293108)
Setting free inodes count to 406127 (was 408580)
Setting free blocks count to 1305622 (was 1347486)
plush.rootfs: clean, 60209/466336 files, 604906/1910528 blocks (check after next mount)

その後のfsckパスはクリーンで、イメージをマウントでき、fsck -fその後もパスします。

ただし、生のブロックコピーイメージが作成されたカード上のファイルシステムには、同じ問題がsystemd-fsckあります。ただし、起動時に発生する問題は、ファイルシステムを「クリーン」として記録します。ただし、その後、適切にシャットダウンしてカードを取り出し、fsck別のボックスから再試行すると、同じエラーが表示されます。

オリジナルが別のマシンにマウントされると、syslogは次のように記録します。

kernel: EXT4-fs (sdc2): 4 orphan inodes deleted
kernel: EXT4-fs (sdc2): recovery complete

私はそれをすべてバックアップしているので、私はここで何でも試すことにオープンです。私はこれを忘れて、明らかに修正されたイメージからパーティションを再書き込みすることもできますが、それはfsckが軽微な問題の解決に不可解に失敗したと仮定することを意味するため、非常に満足のいく解決策ではないようです。

これは、recovery_flagの必要性などの「公式ドキュメントのリクエスト」の質問（または単に「これはどういう意味ですか？」の質問）に変わるのではないかと思います。

私はこれと同じ問題に遭遇しました。e2fsckメンテナで問題をデバッグした後、SDカードが壊れていることに気付きました。エラーなしで書き込みを受け入れていましたが、実際にはカードにデータを書き込んでいませんでした。SDカードは事実上読み取り専用でした。

カードが何らかのフェイルセーフモードに入ったようです。このモードでは、データを読み取ることはできますが、何も書き込まれません。

このe2fsckメッセージunable to set superblock flagsは、エラーなしで発生した、ジャーナルを処理済みとしてマークするためにスーパーブロックに書き込もうとしたが、スーパーブロックを再度読み込もうとしたときに、ジャーナルを再生する必要があることを示していました。つまり、スーパーブロックに書き込まれた変更はストレージメディアに保存されませんでした。

私が使用しているこの問題のあるカードは、Samsung Evo 16GB microSDです。これは、これらのカードの一般的な問題である場合に備えて言及します。

これを使用ddして/dev/zero、ブロック0でカードに4096バイトを書き込むことでこれをテストすることができました。その後、カードから読み戻し、必要なすべてのゼロを取得する代わりに、元の変更されていないext4スーパーブロックを取得しました。

現在、データを新しいカードに移動し、SDカードに10年間の保証を提供していると思われるSamsungから交換品を入手できるかどうかを確認しています。

更新：サムスンは16GBカードを同じEvoシリーズの32GBカードに置き換えたので、あまり文句を言うことはできません！

私はこれが古いスレッドであることを知っていますが、私はいくつかの洞察を提供すると思いました。

これは、SDカードが自然死する方法のようです。sdカードが耐えることができる読み取り/書き込みサイクルの数は、「読み取り/書き込み」と見なされる他のほとんどの媒体よりも大幅に少ないです。これが終了すると、カードは読み取り専用モードになりますが、そのことは通知されません。OSのキャッシュなどのおかげで、カードに書き込んでいると多くのことは思われますが、何も付着しません。

sdカードを強制終了する優れた方法は、それをスワップパーティションとしてマウントするか、読み取り/書き込みが非常に集中するものとしてマウントすることです。あなたはその方法でカードをどれだけ早く殺すことができるか驚かれることでしょう。SDカードまたはUSBサムドライブからknoppixを実行すると、カードの品質とknoppixの使用状況に応じて、1〜2か月しか持続しないことがわかりました。（私はそれ以来、数年続いたUSB SSDドライブからknoppixを実行するように切り替えました）。