grubでbootできなくなった2048 sector以内のディスク障害

1.概要

去年のことですが、500GBのディスクがクラッシュのメッセージを出力して、grubによるブートができなくなりました。しかし、不思議なことにfsckを実行するとエラーなし、各パーティション内のファイルも参照できます。パーティションテーブルを再構築して、再度試しても状況は同じになります。

ディスクのクラッシュは何度も経験し、PCから取り外してUSB接続で確認する機器を利用して検査をしています。クラッシュした場合は異音がするのですぐにわかります。異音がない場合でもディスクを認識できなくなり、異常なことに気が付きます。

今回のケースは異音もなく、ディスクも正常に認識され、fsckの実行やgpartedによる初期化も問題ないのですが、OSを再導入してGrubブートを実行するとエラーになり止まってしまいます。

この問題に関して、私は以下のように認識をしました。

(1) ディスクの先頭1MB（0〜2047セクター）の物理エラーを検出・修復できない

(2) 上記領域にはMBR以外にbootに必要なモジュールが保管されている

(3) ddコマンドを利用すると内容の確認は可能である

2.詳細

障害を解析した訳ではないので、詳細に関しては不明瞭な点が多数あります。grubを利用したbootだけがだめになってしまたディスクのようです。別の代替ディスクに交換して、環境を再構築すると問題はなくなりました。つまり、ディスクはクラッシュしていたと言うことですが、gparted, fsck, fdisk, mkfsでエラーにならない故障でした。

fdiskでディスクを調べていて、2048セクター以前の領域はユーザ側で利用できないことに気が付きました。0〜2047セクターなので、2048 * 512 = 1MBの領域です。ここには、パーティションテーブル以外にもbootに必要な情報が保管されていると認識しています。

Grubの詳細な仕様はわかっていませんが、2048セクター以前の領域を利用すると理解していました。Grubでエラーが発生して、2048セクター以降では何も問題が発生しない。更に、Gpartedでパーティションテーブルを再構築をしても、状況が変わらない。

私の環境はmsdosパーティションテーブルを利用しているので、MBRが存在します。今回の故障はMBRは無事ですが、2047セクター内のmsdosパーティションテーブル以降の場所でクラッシュが起きたようです。ユーザーが普通利用する領域は無事なので、fsckではディスクに問題はなく、データディスクとしては使えるようです。

2048以前のセクター内容を確認する手段がないことに気が付きました。gparted, fsck, fdisk, mkfsで処理できない場所がディスク上に存在します。この領域を操作する最後の手段はddがあるとGeminiから教わりました。

既に、このディスクは分解して廃棄したのでddによる検証はできなかったのですが、こんな故障の仕方もあるんだと思ったので、ブログの記事にしました。今回記事を見直して、備忘録として残すことにしました。

3.所見

ディスクでエラーが発生した場合、代替シリンダを利用してエラーが発生した領域を正常な領域と入替えて利用する仕組みがありました。代替シリンダを利用する方法は物理的な初期化が必要と聞いたことがありますが、具体的な方法は良くわかっていません。

ディスクが容量が少ない上、高価なときには、クラッシュが発生している領域を利用しないパーティションをダミーで作成して、利用することもありました。今では、やらない手段となっています。

最近はSSDに変わっていますが、私の経験ではSSDで１箇所でも物理的な問題が発生すると問題領域を利用不可にする仕組みは使えません。ディスクとSSDではストレージ領域の使われ方が大きく異なっているようです。

更新日

2026-08-01

参考

[本ブログ内参照]
・hdparmコマンドでHDD/SSDの速度測定！Ubuntu/LinuxMintで簡単にできるベンチマーク手順
・LinuxMintでStorageデバイスの内容を完全消去する方法
・ディスクの状態を確認するためにsmartctlを利用しました
[外部サイト参照]
・Why does the partition start on sector 2048 instead of 63?