私はラップトップにWindowsとLinuxのデュアルブートをインストールする簡単な方法を考えましたが、必ずしもこの順序ではありません。通常、最初にWindowsをインストールし、次にlinuxをインストールして、GRUBでWindowsを処理できるようにする必要があります。
したがって、私が達成しようとしているのは、その厄介なインストールプロセス（Windows）をバイパスし、イメージを使用してドライブに直接コピーする方法を見つけることです。これにより、ブートマネージャー（GRUB）を保持することもできます。（後で復元することはできませんが、独占することはマイクロソフトのポリシーです。この場合、システム内の他のブートマネージャーの存在を拒否します）。
最初にWindows 8.1の合法的なコピーを入手し、次にVirtualBoxを使用して仮想マシンにインストールしました。次に、GPTパーティションハードドライブにNTFSパーティションを作成し、Windowsパーティションの内容を.vdiイメージから新しく作成したパーティションにコピーしました。
もちろん、まだ動作しません。bootmgrを置き換える方法がわかりません。それは与えます
File: \Boot\BCD
Status: 0xc000000e
Info: The Boot Configuration Data for your PC is missing or contains errors.
起動、システム回復などに使用される他のパーティションからそのファイルを見つけることができないためです。
ここで、bootmgrが最終的にwinload.exeを実行してWindowsを起動することを読みました。次に何をすべきかわかりません。
Windowsの実行に必要なすべてのファイルがあるので、理論的には機能するはずです。また、これを考えたのは私だけではないので、基本的なことは見当たらないかもしれません。多分それはすでに行われていますか？
ブートがどのように機能するのか私にはほとんどわかりません。私が理解できたのは、WindowsとLinuxをデュアルブートすると、WindowsブートローダーをLinuxにチェーン接続するということです。したがって、私が達成しようとしているのは、どういうわけかWindowsブートローダーを取り除くことです。
編集
私はバイナリファイルbootmgrとを見てきました\Boot\BCD。bootmgrBCDファイルを読み取り、オプションをリストします。その中から選択して起動できます。
したがって、実行などの情報winload.exeはBCDファイルにあります。さて、bootmgrそれ自体はchain.c32モジュールを使用してsyslinuxによって実行されると思います。私がやろうとしているのは、どういうわけか、Windowsブートローダーを実行する、つまりwinload.exesyslinuxから直接（可能な場合）、またはBCDやその他を検索せずにそれ自体がbootmgr実行されるように変更することですwinload.exe（パスはbootmgr実行可能ファイルに直接あります）。
この段階では、休止状態（別の手順が必要）は私には関係ありません。
質問を編集して、ファームウェアタイプ、および（EFIの場合）ファームウェアのセットアップで互換性サポートモジュールを有効にしたかどうかをお知らせください
私のファームウェアはEFI（CSMが有効になっている）で、通常はGRUBを使用してArch Linuxを起動します。レガシーシステムとEFI でbootmgr実行されることを発見しました。System32\winload.exeSystem32\winload.efi
私は0.0ここから何をすべきかについて考えがあります。過去10日間、私はBCDに変更を加えようとしており、私は成功に近づいていると思います。しかし、それは無関係です。私が本当にやりたいことは、Windowsブートマネージャーを完全にバイパスすることだからです。
winload.efiEFIシェルから実行する方法（推測）があるか、チェーンローダーなしでWindowsをEFIモードで起動するようにGRUBに他の変更を加えているかどうかがわからない場合。
アドバイスは大歓迎です。
補遺
以下のフォーラム投稿は、いくつかの有用な洞察を提供する可能性があります。
http://reboot.pro/topic/19371-chainload-directly-to-winloadexe/
1。
現在、grub4dosはブートローダー（NTLDRやBOOTMGRなど）をチェーンロードできます。これは、grub4dosが「通常の」ブートセクター（つまり、300バイトのマシンコードなど）に含まれるコードの代わりとして機能できるためです。
このコードは、いくつかのパラメーターを設定し、ローダーを呼び出します。
それでも、異なるコードを理解して複製することはまったく簡単ではありませんでした。
BOOTMGRのようなNTシステムローダーは、単一の.exeに多かれ少なかれ「リアルモード」オペレーティングシステム（DOSとは完全に異なるわけではありません）とプレーンテキストとレジストリハイブの両方を解析するための機能/ツールを備えています。ゼロから簡単に書ける。
良い人@ReactOSは、YEARS以来、FREELDR（より単純なNTLDRの代替となることを目的としています）の作成に取り組んでいます（そして、ReactOSプログラマーの中には、本当に優秀な人がいると信じています）。
そうです、彼らはNTLDRと実験Server 2003を起動するために管理していること（それが明確に文書化されていません）。
2。
（U）EFIのサポートの導入により、BootMgrはBIOSと（U）EFIの違いを抽象化するのに役立ちます。たとえば、次の2つのシーケンスがあります。
BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows 64-bit (U)EFI -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> WindowsWinLoadは、特定の環境（APIを含む）が存在することを期待しています。BootMgrがこれを処理するので、[ほぼ]同じWinLoadプログラムがどちらの環境でも機能します。
実際、（U）EFIはブートパラメータを格納およびフェッチする方法を定義しているため、BIOS /（U）EFIに関係なく、BootMgrのBCDは同じ目的をカバーしています。
しかし、BIOSと（U）EFIの違いを超えて、BootMgrは「ブートの選択」を可能にしますが、WinLoadは、ブート方法を知っている特定のオペレーティングシステムをブートします。
WinLoadが存在すると想定する環境の量によっては、WinLoadを直接呼び出すことができる場合があります。マイケルブラウンのwimbootはBootMgr PE [1]を直接呼び出すため、WinLoadがおそらくより多くの環境を必要とする場合を除いて、WinLoadを直接呼び出すことができます。あなたはそれを試すことができます！
[1] GRUB4DOSおよびSyslinuxのchain.c32が呼び出すことができるBootMgrと混同しないでください。そのBootMgrには、埋め込まれたBootMgr PEを呼び出す方法を知っているスタブが含まれています。
setupユーティリティで互換性サポートモジュールを有効にしたかどうか（EFIの場合）をお知らせください。