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
ここでは両方とも「いいえ」と答えましたが、すぐに同じ結果につながらないはい/いいえのシーケンスはありません。
ファイルシステムはマウントでき、何気ない検査で大丈夫に見えます。これはデバイスでも正常に動作し、それがルートファイルシステムです（実際には、それほどうまくいかないことが判明しました。コメントを参照してください。回復できないほど壊れたディレクトリがいくつかあります）。
私はファイルにパーティション（8 GB）をdd 'し、それに対して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が軽微な問題の解決に不可解に失敗したと仮定することを意味するため、非常に満足できる解決策のようには見えません。
これはneeds recovery_flag（または単なる「これはどういう意味ですか？」という質問）のようなものに関する「公式ドキュメントの要求」の質問に変わるので、これらの行に沿った提案は高く評価されます。
私はこの同じ問題に遭遇しました。 e2fsckメンテナで問題をデバッグした後、SDカードが壊れていることに気付きました。エラーなしで書き込みを受け入れていましたが、実際にはカードにデータを書き込んでいませんでした。 SDカードは事実上読み取り専用でした。
カードが何らかのフェイルセーフモードに入ったようです。このモードでは、データを読み取ることはできますが、何も書き込まれません。
e2fsckメッセージunable to set superblock flagsは、エラーなしで発生した、スーパーブロックへの書き込みを試みてジャーナルに処理済みのマークを付けようとしたが、再度スーパーブロックを読み取ろうとしたときに、ジャーナルが再生されます。つまり、スーパーブロックに書き込まれた変更はストレージメディアに保存されませんでした。
私が使用しているカードでこの問題が発生しているのは、Samsung Evo 16GB microSDです。これは、これらのカードでよくある問題であるためです。
ddを使用して、ブロック0で/dev/zeroから4096バイトをカードに書き込むことにより、これをテストすることができました。その後、カードから読み戻し、必要なすべてのゼロを取得する代わりに、元の変更されていないext4スーパーブロックを取得しました。
現在、データを新しいカードに移動し、SDカードに10年間の保証を提供していると思われるSamsungから交換品を入手できるかどうかを確認しています。
更新：サムスンは16GBカードを同じEvoシリーズの32GBカードに置き換えたので、あまり文句を言うことはできないと思います！
これが古いスレッドであることは知っていますが、少し洞察を提供したいと思いました。
これは、SDカードが自然死する方法のようです。 sdカードが耐えることができる読み取り/書き込みサイクルの数は、「読み取り/書き込み」と見なされる他のほとんどの媒体よりも大幅に少ないです。これが終了すると、カードは読み取り専用モードになりますが、そのことは通知されません。 OSキャッシングなどのおかげで、カードに書き込んでいると多くのことは思われますが、何も付着しません。
Sdカードを強制終了する優れた方法は、それをスワップパーティションとしてマウントするか、読み取り/書き込みが非常に集中するものとしてマウントすることです。あなたはその方法でカードをどれだけ早く殺すことができるか驚かれることでしょう。カードの品質とknoppixの使用状況に応じて、SDカードまたはUSBサムドライブからknoppixを実行すると、1〜2か月しか持続しないことがわかりました。 （私はそれ以来、数年続いたUSB SSDドライブからknoppixを実行するように切り替えました）。