「クローニングで発生した問題あれこれ」のその5です。これまで検証した結果から、クローニングでのみ問題が起こることは分かりました。ただ、その問題はパーティション構成とは直接の問題はないこともわかりました。
そこで、改めて色々な情報をWebから集めた結果、この問題のカギを握るのは「ディスク署名の重複」によるものと結論付けるに至っています。
ただし、一部推測でこうなるだろう、というのが混ざっていますし、記憶が多少あいまいな点もありますので、間違っていたら皆さん自身での検証結果の方を優先してください。コメントでご指摘などいただければ、可能な限り対応します。
なお、以下の記述は、私の検証した結果を踏まえたものなので、HDDがSATA#0、SSDがSATA#2のチャンネルにそれぞれ接続されている前提です。また、HDDはMBRディスクであるケースのみを取り扱ってます。さらに、クローン元がHDD、クローン先がSSDという状況です。
ディスク署名の確認
Windowsが起動している状況なら、コマンドプロンプトを管理者として実行して、"diskpart"コマンドを使ってディスク署名を確認できます。また、Windowsの回復ドライブで起動した場合でも、いったんコマンドプロンプトに下りれば同じく"diskpart"コマンドが使えます。
通常、つまりクローンをしていない場合、ディスク0（HDD）とディスク1（SSD）のディスク署名（ID）は別の値になっています。これが、クローンしたHDDとSSDの場合は同じ値になるということですね。
クローン環境の模擬：ディスク署名だけを重複させる
ディスク署名を重複させるためだけにクローンを作ると、時間が何時間もかかって不便なのですが、実際にはdiskpartコマンドを使って、下の画面のようにディスク0の署名をディスク1のものと同じ値に設定できます。
それで、この状態でWindowsを再起動すると、その2，3で述べた問題が再現します。つまり、HDD内にWindowsパーティションがあれば、そのWindowsが起動するし、無ければ”inaccessible boot device”というメッセージを出してWindows起動不可となります。
では、この前後でどういう変化が起こって起動できなくなるのか、と言う事を窺い知れるのが、Windowsのブートマネージャが参照するBCDと呼ばれるデータを制御する"bcdedit"というコマンドの出力です。このコマンドもdiskpartと同じ局面で使えるコマンドです。何もオプションをつけずに実行すると、現在のブートにかかわる情報を表示してくれます。
起動環境の確認：bcdeditコマンドの出力
まず、正常な状態、つまりディスク署名が重なっていない場合の出力は以下の通りです。
ここで注目すべきは、Windowsブートマネージャーの中の"device"項目です。ここで”partition=\Device\HarddiskVolume2”と書かれていますが、これはディスク0（HDD）にパーティションが一つだけがあり、これがVolume0、ディスク1（SSD）にあるブートパーティションがVolume1、WindowsのシステムパーティションがVolume2という風に割り振られてます。
ちなみに、このVolume*の数字部分は固定で書かれているわけではなく、接続状況によって動的に変化します。例えば、HDDを外してSSD単独で起動した場合、自動的？に"Volume1"に変わります。
では、diskpartコメントでHDDの署名をSSDと重複させた場合に、bcdeditの出力がどう変化するかを示したのが下の画面です。
見てわかるとおり、ブートマネージャーの"device"項目などが"unknown"となり、起動に使うパーティションをどこに見に行ったらいいかわからない状態になっています。
このように、ディスク署名が重複すると、起動するパーティションが行方不明になることが、「クローン同時接続問題」の本質だと言う事が強く示唆されます。そして、ブートデバイス・ボリュームを決定するためのキーとして、ディスク署名が使われていると言う事が予測されます。
かなり長くなりましたので、一旦"unknown"になった後、そんな中でどんな風に起動が進行していくかの推測は、その6で書きたいと思います。
