Windows11 ディスク換装でINACCESSIBLE BOOT DEVICE

Windows 11 ProとUbuntu 20.04 desktopが入ったSATA SSD。
購入当時、Windowsの起動が革命的に早くなって感動したやつで、電源オン2500回程の現在も元気に動いていて、快適な環境を提供し続けてくれている。

このSATA SSDを、容量の大きなM.2 SSDに換装する。

原因が分かれば大した話ではないのだが、解決までに15時間も掛かってしまった。

発生したこと

問題に関係する環境の情報。

項目	値
搭載OS	Windows 11 ProとUbuntu 20.04 desktopのデュアルブート
SATAデバイス	SSD(GPT), DVD-Drive
M.2デバイス	なし(今まで一度も付けたことがない)

この環境で、SATA SSD(1TB)の中身を、そっくりそのままM.2 SSD(2TB)に入れて使おうとした。
USBフラッシュメモリーからUbuntuを起動し、ddコマンドでベターッとコピーすれば動くはず･･･と。

コピー完了後、Ubuntu 20.04 desktopは起動するが、Windows 11 Proは起動しなかった。
BSoDが発生し、エラーメッセージはINACCESSIBLE BOOT DEVICEであった。
(このメッセージは一瞬表示され、すぐに再起動してしまうので、画面をビデオに撮影して確認した)

対策

その1

この問題が発生する理由は、BIOS(UEFI含む)で正しく起動デバイスが設定できていない、装置が故障している、ケーブルが正しくつながっていない、ドライバが古い、マザーボードのBIOSが古い、etc. 色々あるようだ。

この環境では

M.2 SSDデバイスを空っぽにして接続。
SATA SSDのWindows 11 Proを起動し、ドライブをクイックフォーマットしてアクセス。
その後で、SATA SSDの内容をM.2 SSDにコピーする。

が対策であった。

今まで一度もNVMeデバイスを取り付けたことがなかったので、標準 NVM Express コントローラー(2006年製)は読み込まれることがなかった。
NMVeデバイスを一度接続してWindows 11に認識させることで、それが読み込まれるようにした、という話。

標準 NVM Express コントローラーが読み込まれないと･･･

PCを起動。
BIOSはM.2にあるUEFIを示す。
ブートマネージャーが起動。
ブートローダーが起動。
Windowsローダーを呼び出すところ、もしくは、Windowsローダーがその先を読み込もうとするときにM.2にアクセスできない。

となって、「アクセスできない起動デバイス」というエラーが表示されることになる。

最終的には、Windows 11 Proを空き領域にインストールしてみて、それが起動できることを確認したところで、もしかしてドライバ？と気が付いた。
古いんじゃなく、読み込んでいないかもと。

その2 2023/06/25追記

本日、マザーズPCでINACCESSIBLE BOOT DEVICEが発生。
ディスクドライバは読み込まれていたはずだけれど…もう一度！古いSATA SSDで起動、空っぽにしたM.2 SSDにアクセスした後に、改めてSATA SSDの内容をM.2 SSDにコピーして起動、INACCESSIBLE BOOT DEVICE発生。

この問題に遭遇することは二度とないだろうと思っていたが、比較的あっさりと二度目がやってきた。

bcdedit /enum all で確認してみたところ、ブートローダーがramdiskとか書かれていて、ちょっと変だった。

出先だし、あまり時間がなかったこともあったので、過去に復旧させたコマンドを順番に入力してみた。

DISKPARTでEFIパーティションにドライブ名をセット。
ちょっとどんな容量だったかは覚えていないけれど、EFIパーティションはVolume 1だった。

X:\Sources>diskpart

DISKPART> list volume

 Volume ###  Ltr Label        Fs    Type        Size     Status     Info
 ----------  --- -----------  ----  ----------  -------  ---------  --------
 Volume 0     C   OS           NTFS   Partition    100 GB  正常
 Volume 1                      FAT32  Partition    300 MB  正常         非表示

 ...

DISKPART> select volume 1

ボリューム 2 が選択されました。

DISKPART> assign letter=z

DiskPart はドライブ文字またはマウント ポイント を正常に割り当てました。

DISKPART> exit

DiskPart を終了しています...

後は順番にコマンドを実行。

X:\Sources>bcdboot C:\windows /s Z: /f UEFI /l ja-jp
ブート ファイルは正常に作成されました。

X:\Sources>bootrec /scanos
Windows インストールを、すべてのディスクをスキャンして検出しています。

これには、しばらく時間が掛かります。お待ちください...

Windows のインストールのスキャンは成功しました。
Windows のインストールとして認識された合計数: 0 ← 意味がなかった感じもする。

X:\Sources>bootrec /rebuildbcd
Windows インストールを、すべてのディスクをスキャンして検出しています。

これには、しばらく時間が掛かります。お待ちください...

Windows のインストールのスキャンは成功しました。
Windows のインストールとして認識された合計数: 0 ← これも意味がなかったかも。
操作は正常に終了しました。

これで起動するようになった。

やったこと

このブログは自分メモ。
将来何かに使うかもしれないので、悪戦苦闘ぶりを記す。

現在のSSDの確認

今のディスクに全く不満はないわけだけれども、ちょっと調べてみたら2TBのM.2 SSDの価格が大幅に下落していた。
価格が下がっている理由を考えると微妙なところではあるけれども、ついついポチってしまった。

今のSSDはまだまだ元気に動いているし、十分な容量があるから、今までHDDで動作させていたPCに取り付けて頑張ってもらうつもり。

さて…
SSDの状態をメモしておく。後々、何かトラブルがあった時に使うかもしれないから。

$ sudo fdisk -l /dev/sda
ディスク /dev/sda: 953.89 GiB, 1024209543168 バイト, 2000409264 セクタ
Disk model: SPCC Solid State
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: ADXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX920C

デバイス     開始位置   最後から     セクタ サイズ タイプ
/dev/sda1        2048     206847     204800   100M EFI システム
/dev/sda2      206848     239615      32768    16M Microsoft 予約領域
/dev/sda3    29566976 1792004095 1762437120 840.4G Microsoft 基本データ
/dev/sda4  1792004096 1793406975    1402880   685M Windows リカバリ環境
/dev/sda5  1793413120 1961346713  167933594  80.1G Linux ファイルシステム
/dev/sda6  1961347072 1978124287   16777216     8G Linux スワップ

$ sudo smartctl -a /dev/sda
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.15.0-73-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     SPCC Solid State Disk
Serial Number:    AA000000000000000025
Firmware Version: R0522A0
User Capacity:    1,024,209,543,168 bytes [1.02 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-2 T13/2015-D revision 3
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat Jun 10 08:52:24 2023 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		(  120) seconds.
Offline data collection
capabilities: 			 (0x11) SMART execute Offline immediate.
					No Auto Offline data collection support.
					Suspend Offline collection upon new
					command.
					No Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					No Selective Self-test supported.
SMART capabilities:            (0x0002)	Does not save SMART data before
					entering power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 (  10) minutes.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0032   100   100   050    Old_age   Always       -       0
  5 Reallocated_Sector_Ct   0x0032   100   100   050    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   050    Old_age   Always       -       12068
 12 Power_Cycle_Count       0x0032   100   100   050    Old_age   Always       -       2487
160 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       0
161 Unknown_Attribute       0x0033   100   100   050    Pre-fail  Always       -       100
163 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       10
164 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       39125
165 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       168
166 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       2
167 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       79
168 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       7000
169 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       99
175 Program_Fail_Count_Chip 0x0032   100   100   050    Old_age   Always       -       0
176 Erase_Fail_Count_Chip   0x0032   100   100   050    Old_age   Always       -       0
177 Wear_Leveling_Count     0x0032   100   100   050    Old_age   Always       -       0
178 Used_Rsvd_Blk_Cnt_Chip  0x0032   100   100   050    Old_age   Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   050    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   050    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   050    Old_age   Always       -       102
194 Temperature_Celsius     0x0022   100   100   050    Old_age   Always       -       40
195 Hardware_ECC_Recovered  0x0032   100   100   050    Old_age   Always       -       8381418
196 Reallocated_Event_Count 0x0032   100   100   050    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   050    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0032   100   100   050    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x0032   100   100   050    Old_age   Always       -       2
232 Available_Reservd_Space 0x0032   100   100   050    Old_age   Always       -       100
241 Total_LBAs_Written      0x0030   100   100   050    Old_age   Offline      -       494942
242 Total_LBAs_Read         0x0030   100   100   050    Old_age   Offline      -       674667
245 Unknown_Attribute       0x0032   100   100   050    Old_age   Always       -       550384

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

Selective Self-tests/Logging not supported

作業用のUSBフラッシュメモリー

この際だから、USBフラッシュメモリーで動作するUbuntuでも作ろうかなと思い立って、やってみた。
だけれども、あまりにも遅くて待ちきれず、途中でプチンと止めたらフラッシュメモリーが壊れてしまった…128GBタイプだったのに、残念。

ということで、過去に作ったマルチブートなUSBフラッシュメモリーを活用。
Ubuntu 20.04は日本語キーボード対応させたカスタムISOが入っているのでそのまま。
Boot-Repairはちょっと古くても問題いのでそのまま。
Windows 10はファイルを削除し、Windows 11のISOをダウンロードしてきて、中身をコピーしておいた(GrubからWindowsのISOは起動できないから)。

M.2 SSDの取り付けとコピー

M.2 SSDを接続し、USBフラッシュメモリーからUbuntu 20.04を起動。

GPartedを起動してみたら、/dev/nvme0n1という名前が付けられていることが分かった。
そして、SATA SSDは／dev/sdaという名前が付けられていたので、以下のコマンドでコピー。

$ sudo dd if=/dev/sda of=/dev/nvme0n1 bs=1M status=progress

ブロックサイズを指定しないと、コピーが遅い。
16Mを指定しても遅かったりしたので、程々のサイズが良い模様。

コピーは30分ほどで終わったけれども、進捗が分からないと嫌なケースもあるだろうから、進捗表示のオプションも付けている。

SATA SSDの取り外しと起動

SATA SSDを取り外し、USBフラッシュメモリーも取り外して、M.2 SSDから起動。
マザーボードは自動的にUEFIを認識して、ちゃんとブートを掛けてくれる。

Ubuntu 20.04 desktopは問題なく起動。

Windows 11 Proは起動しない。

Windowsロゴ＋ホワイトサークルが30秒ほど。BSoDが一瞬表示されて再起動。 x 2回。
回復モードに突入。

となった。

原因が分からないので、動画で撮影したところ「INACCESSIBLE BOOT DEVICE」。
なお、回復モードでコマンドプロンプトを開くと、M.2 SSDに問題なくアクセスできていた。

ブートに関わる箇所の確認

原因がアレなので無駄骨ではあった。
ただ、起動に関わるトラブルは色々なところで発生していて、各所で親切な人が色々と教えてくれていたのでメモしておく。

ディスクイメージのコピーし直し。
- コピーが失敗することもあるか？と思ったが、そんなことはなかった。
- コピーの度に30分掛かるし、その間にできることも限られるので、必要になるまでやらなくていい。
過去の自分記事でブート関連の修正方法を復習。
- bcdedit /enum all は、ブートの流れを読み取るのに最適だった。
- 過去記事では、bcdbootコマンドで言語を指定していなかったので、修正しておいた。
バックアップ(というか原本)があるから、ブートに関わるコマンドを割と気軽に実行していたが、やっていることの意味は知っておいた方が良い。
- ここでBCDシステムストアについて教えてくれている。
  Microsoft / UEFI 用の BCD システムストアの設定
  - BCDはBoot Configuration Dataの略。
  - 回復モードでは、EFIパーティションにドライブレターは割り当てられない。
    通常モードでも同じ。Linuxでは/boot/efiにマウントされるのとは対照的。
  - bcdedit /enumでdeviceやosdeviceにドライブ名が表示されているケースと、\Device\HarddiskVolume1等と表示されているケースがある。
    - これは、ドライブレターが割り当てられているドライブはドライブ名で表示＆操作ができるというだけのこと。
      DISKPARTでドライブレターを割り当てれば表示も変わる。
    - \Device\HarddiskVolume1の数字の部分がボリュームごとに変わるが、DISKPARTで表示されるものとは違う。
      BCDシステムストアに何かを設定したい場合には、ドライブレターを割り当てて、ドライブ名で操作するのが確実。
    - やってみた感じから、BCDシステムストアの中身は\Device\HarddiskVolume1形式で保管されていると想像される。
- ここでBCDBootコマンドについて教えてくれている。
  Microsoft / BCDBoot のコマンドラインオプション
  - このコマンドは、ファームウェアおよびシステムパーティションを設定する、といっているので、EFIパーティションにブートマネージャー、Windows\system32にBCDファイルを作ってくれるものと見られる。
- UEFIの場合、EFIにブートマネージャーがあって、それが起動されるようになっている。
  - ということは、ブートセクターを作るBootsectコマンドは実行しても意味がなさそう。
  - BootrecコマンドはWindows 7の頃のマニュアルしか見つからないが、これもブートセクターに関連するコマンドなので、同様。
SATAはNVMeより常に優先度が高い。
Microsoft Community / How can I change the disk number of NVME SSD (Boot) to DISK-0 in Disk Management in Windows 11?
- うちの環境でDISKPARTで確認してみたら、SATA、NVMe、USBの順。
  SATAのデバイスを後から追加しても、必ずNVMeより早い番号が付けられる。
- 回復モードでは、SATA → NVMe の順でボリュームに番号が割り当てられ、その順にドライブレターが割り当てられる。
- 通常モードでもこの順序でボリュームに番号が割り当てられるが、ドライブレターは手動で変更すると、それが恒久的に使われる。
  BCDシステムストアのことを考えると、ブート時にボリュームは\Device\HarddiskVolume1形式相当の情報で取り扱われ、ドライブレターはボリュームをどんな名前で取り扱うのかを表しているに過ぎないのかなと思う。
  ボリューム番号が何番であろうと、システムの起動にはあまり関係がないということ。
クローンにまつわるブートの問題を探していると、広告の混じった情報がたくさん出てくる。
- とはいえ、一通りの手順が書かれていて、それは検索キーワードにもできるから、深掘りが可能になる。
- こちらの記事には様々な原因とその対処が書かれており(見つけた中では最多)、多くの問題が解決できるのではないだろうか。
  ICTビジネスサポーター / SSD換装でクローンが失敗する原因と解決方法、起動しない場合も解説

Windows 11 Proのインストール

Windows 11は当然NVMeに対応している訳なので、このシステム(例えばBIOSの設定とか)に何かNVMeが使えない原因があるのでは？と考えた。

まず、Windows 11のアップグレードインストールでどうにかならないか、と考えた。
しかし、やってみたら「起動したWindowsで実行されることを想定した機能」だそうで、ISOから起動したのではダメだった。

幸い、1TB → 2TBへの換装なので、M.2 SSDには1TB弱の空き容量があるので、Windows 11のデュアルブート環境を作ることができる。
ということで、開いているところに新しいWindows 11をインストールしてみた。
新しくインストールしたWindows 11 Proは何の問題もなく起動した。

ここまできて、あぁ、そういえば、SATA SSDの環境で一度もM.2 SSDのディスクを認識させたことがなかったな…と気付いた。

そこで、

M.2 SSDのパーティションテーブルをGPTで作り直して、パーティションを空っぽにする。
SATA SSDでWindows 11を起動して、M.2 SSDにボリュームを作り、ドライブレターを割り当てる。
USBフラッシュメモリーでUbuntuを起動し、ddコマンドでSATA SSD→M.2 SSDへのコピー。
SATA SSDを外してPCを起動し、M.2 SSDでWindows 11を起動。

を実行したところ、Windows 11を起動することができた。

長かった…

GPTディスクの調整

USBフラッシュメモリーからUbuntu 20.04を起動して、GPTディスクの最終調整をする。

GPTの場合、パーティションテーブルのバックアップが、ディスクの最後に取られている。
SATA SSD(1TB)→M.2 SSD(2TB)に中身をベターッとコピーしたので、ディスクの最後に正しいパーティションテーブルのバックアップがない状態。
これは、GPartedを起動すれば自動的に検出され、修正するかどうかを聞かれるので、Fixと答えて修正。

続いて、M.2 SSDの後ろ1TB分の容量を有効活用するべく、GPartedでパーティションを移動したり、広げたりした。
パーティションの異動には危険が伴うので、警告表示がされるけれども、バックアップがあるという安心感もあって、気にせずに実施。

結果としては、狙ったとおりのパーティション構成にすることができた。

効果の確認

まず、VMware Workstation Playerの仮想PCで、いくつものDockerコンテナを起動しているものについて、ディスクイメージをHDDからM.2 SSDに移動してみた。
HDDにイメージがあったときには、設定により改善はさせていたものの、ディスク使用100％が45秒程度続いていた。
M.2 SSDにイメージを移動させたら…OS起動時は1～2％、Dockerコンテナが起動している一番アクセスが多いときでも60％程度を超えることがなくなった。

続いて、M.2 SSDの速度を数値で見てみる。

どうやらこの数字、現時点では相当早いみたい。

ということで、体感的にもベンチマーク的にも革命的な改善となった。

さいごに

今回発生した問題は、

リテール版など、パーツを変えても問題にならないライセンスを使用している。
(OEMは何にくっつけて購入したのかによって、それを変えるとライセンスが無効化するという記憶)
そのシステムでは一度もM.2 SSDを使ったことがない。
SATA SSDをM.2 SSDに換装しようとした。
(普通はPCごと買い換えるとか、まっさらからインストールするのだろう)

という条件が揃ったときに発生する、超レアケースな話ではある。

でもなぁ…Ubuntuはあのカーネルのサイズでちゃんと対応してくれているんだよなぁ。
Windows 11はといえば、起動してからじゃないとアップグレードインストールもできないし、NVMeコントローラーの問題は自動修復できないし、BSoDで再起動しない設定にもかかわらず速攻で再起動するからエラーメッセージが見えないし、それでいて回復モードだと普通にM.2 SSDにアクセスができちゃったりするからM.2 SSDは使えるものと勘違いしてしまう…と、どハマり要素しかないのですよ。

超レアケースではあるけれど、基本的なところでもあるので、対応してくれるといいなぁ(もう自分には二度と同じことは起きないだろうけれども)。