これは基本的にどう解決するかという質問ではありません (すでに解決されています)。ただ理解を深めたいだけです。
ここですでに良い論理的な答えを見つけました:クローンされたパーティションは正確に同じ位置にはありません
しかし、プロセス全体を理解するのにまだ問題があります。あるいは、私が経験したトラブルを回避する方法を知るのに問題があります。
シナリオは古典的（ではない）です:
SATA HDDをUSB SSDにクローンする（私の場合はAOMEIバックアップ標準）
ラップトップの中に SSD を入れます (はい、最初に HDD を取り外しました ;)
電源オン - 申し訳ありませんが、ボーナスなし - 起動なし - 修復なし (セクターがシフトされているため -> 修復)
そこで、USB 経由で元の HDD を起動するという (素晴らしい?) アイデアを思いつきました。
電源オン - 申し訳ありませんが、ボーナスはありません - 起動しませんが修復します (このセクターは移動されていないため、これが最初の質問です)
修復では、コマンドライン（diskpartなど）に直接アクセスしました
そして私は気づい
bootrec /rebuildbcdた両方Windows システムの修復が提案されました - 問題ありません - しかし、次のエラーが発生します: 「.... 失敗しました... 識別できないシステム」(または類似)
そうですね、それはクローンです... (2 番目の質問: 同じですかdisk signature? そうであれば、どのように変更しますか?)
私はこれを素晴らしいアイデアで解決しました:
bootrec /rebuildbcdもう一度始めましたが後スキャンして前にC: (SSD) 上の Windows を選択し、USB HDD を取り外しました (!) - そして - なんと、正常に完了しました。そして、SSD から起動しました。
質問の要約:
元の HDD が USB から起動しないのはなぜですか (または起動しないのですか)? ディスク ID が同じだからでしょうか? そうであれば、回避する方法はありますか? (Windows アクティベーションの問題に遭遇しますか?)
「区別できないシステムエラー」につながる「もの」とは何か
USB 接続中 (スワップ前) に SSD 上の EFI システムを修復することは可能でしたか?
答え1
質問に対する答えは、コンピュータが最初にどのように起動したかによって 2 通りあります。実際、問題の原因 (パーティションの場所の変更) としてあなたが挙げた説明は、私の知る限り、最初のシナリオにのみ当てはまります (ただし、私は Linux ほど Windows の起動については詳しくないので、Windows EFI モードの起動に関するこの詳細を誤解している可能性があります)。2 つの起動モード (およびシナリオ) は、BIOS モードと EFI モードです。また、共通する要因もいくつかあります。
BIOSモード
2011年後半以前に販売されたほとんどのコンピューターは中古品基本入出力システム (BIOS)ファームウェア。BIOS ベースのコンピューターは、ディスクの最初のセクターであるマスター ブート レコード (MBR) に格納されているブート ローダーを介して起動します。すべての詳細には触れませんが、ほとんどの BIOS モード ブート ローダーは、ディスク上のパーティションの開始セクター番号に大きく依存しています。これは、MBR が小さすぎて完全なブート ローダーを保持できないため、MBR コードはパーティションのパーティション ブート レコード (PBR、パーティションの最初のセクター) からさらにブート コードを読み込み、次に追加のコード (セクター番号で参照されることが多い) を読み込むためです。正確な詳細は OS とブート ローダーによって異なりますが、重要な点は、セクター番号がほとんどの場合に重要であるということです。したがって、ディスクのクローン作成操作でブート パーティションの開始セクターを変更し、それに依存するブート ローダー コードまたは構成を調整しなかった場合、ブート プロセスは失敗します。
ブート可能なパーティション上の「ブート フラグ」(別名「アクティブ フラグ」) の有無など、影響を与える可能性のあるパーティションの詳細が他にもあります。ブート コードは MBR と PBR に存在するため、ディスクのクローン作成操作ではこのブート ローダー コードもコピーする必要があります。ランダムなディスク クローン作成プログラムがこれらのコードをコピーするという保証はありません。(あなたが使用したという AOMEI については具体的にはわかりません。)
ご了承くださいほとんどWindows 7 を搭載して出荷された (ただしすべてではない) コンピューターは、すべての Windows Vista およびそれ以前のコンピューター (Itanium またはその他の特殊な CPU を使用したコンピューターを除く) と同様に BIOS を使用しました。2011 年後半から、製造元は BIOS から新しい EFI/UEFI (次に説明) に急速に移行しましたが、ほとんどの EFI には互換性サポート モジュール (CSM) と呼ばれる機能が含まれており、これによりこれらのコンピューターは BIOS 方式 (別名「レガシー モード」) で起動できます。したがって、新しい EFI ベースのコンピューターに Windows (Windows 8.x および 10 も) を BIOS/CSM/レガシー モードでインストールできます。そのように構成すると、コンピューターは BIOS ベースのコンピューターのように動作します。
EFIモード
の拡張可能なファームウェア インターフェース(EFI) またはその 2.x バリアントである Unified EFI (UEFI) は、2011 年後半から新しいコンピューターの主流ファームウェアとなった BIOS の代替です。しかし、紛らわしいことに、多くのメーカーは EFI を指すのに「BIOS」という用語を使用しています。私の意見では、これは悪い習慣です。なぜなら、EFI は BIOS の単なるマイナー アップデートだと人々に思わせるからです。しかし、実際には、起動方法が根本的に異なります。
EFI ブート方式では、ファイルを使用します。MBR と PBR は特別な役割を担わず、ブート コードを保持しません。コンピュータは、OS インストーラによって NVRAM にその情報が格納されているため、どのブート ローダー ファイルを起動するかを知っています。(特別なフォールバックファイル名、EFI/BOOT/bootx64.efiは、USB フラッシュ ドライブなどの起動可能な外部メディアで使用されます。) EFI は BIOS とは異なりパーティションを認識するため、EFI ブート ローダーは通常、パーティションの開始セクターを参照しません。したがって、パーティションの開始セクターは、EFI モードのブートではそれほど重要ではありません。
代わりに、EFIモードのブートはパーティション自体を識別する何らかの方法に依存します。これは通常、グローバル一意識別子 (GUID、別名 UUID)ディスクとパーティションの両方に関連付けられた値。したがって、ディスクのクローン作成操作でディスクとパーティションのGUID値が保存されていれば、クローンされたディスクは起動可能なままであるはずです。そうでない場合、起動プロセスはどこかの段階で失敗する可能性があります。AOMEIがデフォルトでGUID値を保存するかどうかはわかりません。GUIDの複製は通常は推奨されません。これらは個性的値ですが、古いハードウェアを交換できるようにディスクを複製する場合は、NVRAM エントリを変更せずに新しいディスクを起動できるように、新しいディスクに GUID 値を複製することが望ましいです。
さらに複雑なのは、多くのEFIがNVRAMから無効なブートエントリを積極的に消去することです。したがって、ブートディスクを別のディスクに複製する場合、ないGUID 値が保持され、その後元のディスクを取り外すと、コンピュータは最初のディスクが起動可能であったことを「忘れる」可能性があります。そのため、元のディスクを再度差し込んでも起動しない可能性があります。
共通要因
原則として、ブートローダーとOSの設定はファイルシステムシリアル番号、UUID、または名前が構成に含まれます。これらの値は、パーティションGUID ですが、パーティション テーブルではなく、ファイル システムのデータ構造に保存されます。Windows がこれを実行するかどうかはすぐにはわかりませんが、ほとんどの Linux ディストリビューションは実行します。
起動の問題が発生した場合は、OS 中心のブート ローダー修復または再インストール手順を使用して問題を解決する必要があります。詳細は、起動方法によって異なります。たとえば、EFI モードの起動では MBR を復元するツールは使用しません。古い手順の多くは BIOS モードの起動を前提としているため、新しい EFI モードのインストールでは機能しません。