Let's noteが壊れてから、復旧するまでの道のり

先週末、会社のLet's noteが急逝！！
症状は、Windowsの起動直後にブルーバックが発生するという、比較的ポピュラーなものだが、このブルーバック、発生原因の特定が、ちとメンドウなのである。


まずは、原因特定のために、ハードウェアテストを慣行。
UbuntuのCD-ROMを使えば、これ一枚でメモリ・HDDのテスト、データレスキューが行えるので、トラブルシューティングのお供として、かなり重宝している。


CD-ROMからUbuntuを起動すると、

  • ディスクの破損チェック
  • メモリテスト

というメニューがあらわれるので、まずは、肩慣らしのメモリテスト。
すると、かつて見たことがないほど大量のエラーが出て、画面が大変な状態に！


メモリがこんな状態だが、一応、HDDの方もチェックしておこうと思ったので、【ディスクの破損チェック】を実行。すると、今度はこんなエラーメッセージが出て、あっけなく終了。



[ 0.166384] ACPI: Aborted because junk in compressed archive
[ 1.215062] Invalid compressed format (err=2)
[ 1.236954] kernal panic- not syncing VFS: unable to mount root fs on unkown block

(0. 0)
もしかして、ディスクも壊れてるの！？


PCがこんなんだから、当然、メモリの故障 => Ubuntuがブートできない => データレスキューもできないという三段論法が成り立つ。


しかし、メモリさえ正常なら、何とかUbuntuを起動できるかもしれない。
かすかな希望を支えに、増設用メモリを外して、再度メモリテストの実行。


すると、、、今度はあっさりテストにパスしてしまった。


もしかして、故障の原因って、さっき外したメモリ？！
これはいけるかも。


よし、お次は【ディスクの破損チェック】だ！
こっちのテストも、なんなくクリア。
もしかして、トラブル解決？


期待に胸を膨らませながら、おそるおそるWindowsを起動してみると、そこには、いつもの見慣れたデスクトップ画面が表示されていた。


Mission Completed！


まとめ
ハードウェアの診断をするときは、

  1. メモリテスト
  2. ディスクの破損チェック

の順に行った方がいいみたい。
なぜなら、メモリが故障しているときは、ディスクの破損チェックは実行できない。
よくよく考えてみれば、当たり前のことなんだけど。。