回答:
ファイルをコピーするだけでは、起動可能なドライブは作成されません。ブート可能にするのはUSBフラッシュドライブ上のファイルだけでなく、パーティションテーブルの構成、ドライブのコンテンツの編成に関するメタデータ、ブート可能かどうか、およびMBRかGPTかをPCに通知します。
各ディスクとパーティションには、何らかの署名とメタデータ/マジックストリングがあります。ディスクを構成するか、ドライバーを接続してシステムにディスクをマウントするために、オペレーティングシステムによって使用されるメタデータ。
ただし、dd、 EaseUS Todo Backup、優れたオープンソースのClonezillaおよびRufusなどの多くのツールを使用して、フラッシュドライブのクローンを作成できます。(ddとRufusについてのリマインダーについてはAlexに感謝します)。
dd
:simple cp
が作業を行います-ファイルシステムのコンテンツの代わりにデバイスノードでそれを使用するようにしてください。
cp
単にデバイスノードをコピーするという彼の主張に対する回答でした。混乱を防ぐために、コメントも削除しました。
コピーは、フォーマットされたパーティション内のファイルのみを処理します。ブートフラグの設定、ブートローダーの書き込み、または通常のファイルをパーティションの正しい場所(読み取り:セクター)にコピーしてファイルの属性を設定するなど、ブートプロセスに必要な特別なことはできません。 /許可。以前にブートディスクを作成したり、ブートローダーをMBRに書き込むフォーマットツールなどのために、これらのものを使用できるのが幸運でない限り、ディスクをブート可能にするためにさらに手順を実行する必要があります。
特に起動時 BIOSモードで、BIOSは最初のセクター(MBR)を検索して、有効な起動シグネチャ0xAA55があるかどうかを確認します。はいの場合、そのセクターをロードし、MBRのブートローダーに制御を転送します。MBRはパーティション構成を記述するため、パーティション内に配置することはできず、通常のツールでコピーできるものではありません。
さらに、MBRは小さすぎて有用ではないため、最新のブートローダーのほとんどは、ブートプロセスを複数の段階に分割します。にし、MBRのブートコードが次のステージをロードします。さらなるイントラステージは、しばしばパーティションの外側の領域に配置されます。EBRに入れることもありますが、grubは通常、最初のパーティションとMBR後のギャップと呼ばれるMBRの間の空き領域に2番目のステージを置きます。そのため、パーティションを適切に配置しないと、grubがブートコードを配置するスペースがないため、埋め込みエラーが発生します。
LILOや古いWindows / DOSブートローダーなどの多くのブートローダーも は、次のステージやシステムファイルの位置など、MBRに情報をハードコードします。パーティションデータを読み取っても機能しませんが、代わりにハードコードされたセクターを読み取ります。ファイルシステムを解析するにはコードがかかりすぎるため、MBRやMBR後のギャップなどの小さなスペースに絞り込めないためです。grubでさえ、このようなハードコーディングをサポートしています。つまり、一部のシステムファイルはセクターごとに正確な場所に配置する必要があり、通常のコピーでは実現できません。これが、「移動できないシステムファイル」が表示される理由です Windowsデフラグツールの実行中またはファイルシステムの縮小中に、実際には正しくない場合があります。これは、最新のブートローダーがはるかに賢く、そのようなことを気にしなくても、Windowsがそれらのファイルを移動するのを恐れているためです。
そして、結局のところ、ブートローダーにブート対象を知らせるために、ブートパーティションをアクティブに設定する必要もあります。これは、パーティション領域の外側にも配置されるため、パーティションツールまたは手動で16進編集する必要があります。
UEFIでは、作業がずっと簡単です。FATファイルシステム(および非標準の実装ではさらに多くのファイルシステム)を認識しているため、ブートファイルは EFIシステムパーティション、別名ESPに。UEFIはESPに* .efiアプリケーションをロードし、オペレーティングシステムをロードします。
UEFIファームウェアは、USBフラッシュドライブなどのリムーバブルストレージデバイスからの起動をサポートしています。そのためには、リムーバブルデバイスをFAT12、FAT16、またはFAT32ファイルシステムでフォーマットする必要がありますが、ブートローダーは標準のESPファイル階層に従って格納するか、ブートローダーの完全なパスをシステムに提供する必要がありますブートマネージャ。
したがって、基本的には* .efiファイルをESPにコピーし、システムファイルを正しいフォルダーに入れるだけです。ただし、*。efiファイルを含むFATパーティションは、パーティション外のMBRまたはGPTテーブルでESPとしてマークする必要があり、上記のようにコピーすることではできないため、まだ小さな問題があります。特に、パーティションタイプを0Ch / 0Bh / whateverから MBRのEFhおよびC12A7328-F81F-11D2-BA4B-00A0C93EC93Bに変更する必要があります。 ESPは実際にはFAT12 /ではなく、独立したファイルシステムである GPTのに FATファイルシステムファミリ
また、BSDディスクラベルやAPMのような他の多くのパーティションスキームがまだあり、それらをブートするには異なる方法で変更する必要があります。または、USBスティックはパーティションテーブルなしでフォーマットされている場合があります(AFAIK Windowsはデフォルトでこれを行います)。したがって、起動可能にする方法は異なります。ただし、同じ制限が適用されます。非パーティション領域を変更する必要があります
従来、BIOSブートには特別な非表示マーカーが必要でした。以下に例を示します。
そのような場合、ファイルを単純にコピーすることはできません。これらの特別なマーカーがないため、結果のドライブは起動できなくなります。
ただし、UEFIブートは特別でスマートであり、特にこれらの問題に対処します。いつものように、UEFIの簡単な入門書としてこのブログ投稿を読むことをお勧めします。フォールバックブートセクションに特に注意してください。これについては、ここでもう少し詳しく説明します。
これが機能するために必要なのは、ファームウェアが検索するパーティション内の特定のパスにあるファイルです。最適な互換性のために1、はい、これはGPTパーティションディスクでEFIシステムパーティションとしてマークされたFAT32フォーマットのパーティションである必要があります。ただし、ほとんどのファームウェアは、MBRパーティションおよび非パーティション(スーパーフロッピー)ディスク上の(単一の)パーティションも検索します。
つまり、UEFIブートに本当に必要なのは、フォールバックブートエントリを含むFAT32 1形式の単一パーティションだけです。x86_64アーキテクチャでは、これは\EFI\BOOT\BOOTx64.EFI
ファイルが必要なことを意味します。そのファイルを含めて、あるフラッシュドライブから別のフラッシュドライブにコピーするだけで、すべてが機能するはずです。
1 FAT32およびGPTは標準で必要です。MBRとsuperfloppyは知らないが、それらのサポートはデスクトップハードウェアの間でかなり普遍的です。ラップトップはもう少し難解です。タブレットは手間がかかり、Mac EFIはユニークです。
2 UEFI規格にはFAT32サポートが必要です。一部のファームウェアはNTFSをサポートする場合もありますが(保証にはほど遠い)、実際にFAT32 ESP内にNTFSドライバーを組み込むことができます。