エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
fsck_ffs -b: 代替スーパーブロック: uyota 匠の一手
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
fsck_ffs -b: 代替スーパーブロック: uyota 匠の一手
日常的なハードディスクの障害の中で生活をしていると、必然的に fsck の回数が増える。 FreeBSD には、... 日常的なハードディスクの障害の中で生活をしていると、必然的に fsck の回数が増える。 FreeBSD には、比較的に早い時期から background fsck が開発されたので、起動時の fsck には正しく umount 去れていなかった時も、ルートパーティションを除き、簡単な点検だけで終らせて、システムを開始しする。 background fsck に移行できない場合は、シングルユーザモードに移動し、手動で fsck を起動すれば、ほとんどの場合は問題ない。ルートパーティション以外だったら、少なくても /sbin などのものが使えたり、/usr も問題が無ければ、他のパーティションの復活も他愛も無いことだ。 しかし、今回だけは、そうは問屋が卸さない。 ルートパーティションのスーパーブロックが壊れてしまい、第二ローダが起動すらしない。 FreeBSD/i386 boot Defau