web-dev-qa-db-ja.com

物理ディスクEFIを使用したVMwareWorkstation

Windows10ホストでVMware仮想マシンをセットアップしようとしています。

私は現在、1台のハードドライブを2つのパーティションに分割しており、現在、デュアルブートでUbuntuを使用しています。

UbuntuをゲストとしてWindowsホストにマウントしたいと思います。

VMwareで[物理ディスク]オプションを使用してUbuntuパーティションをセットアップしようとしています（IDE、SCSI、Sataを試しました）。 VMwareにディスク全体を使用するように指示すると、「現在のディスクは使用中です」というメッセージが表示されます。関連するLinuxパーティションのみを選択すると、「オペレーティングシステムが見つかりません」と表示されます。

奇妙なことに、私のLinuxパーティションは[ファイルシステム]列に「Efiシステム」と表示されていますが、[ファイルシステム]では「Linux」と表示されているはずです。最初にそのパーティションのファイルシステムをEfiではなくLinuxに変更する必要がありますか？ （どうすればいいですか？）

VMwareは、ホストと同じハードドライブ上にある場合でも、Ubuntuパーティションをゲストとして実行できるはずです。

編集：明確にするために、上記の情報はVMware-Workstationによって報告されています。

ただし、Ubuntu Gpartedでは、これが私のパーティションの外観です。

私の現在のSSDハードドライブは現在このようにセットアップされています（LinuxGPartedによる）

  • / dev/nvme0n1p1 ntfs（diag）
  • / dev/nvme0n1p2 fat32（boot、esp）
  • / dev/nvme0n1p3不明（msftres）[Microsoft予約パーティションそれが何であれ]
  • / dev/nvme0n1p4 ntfs（msftdata）[これはWindows10パーティションです]
  • / dev/nvme0n1p5 ext4（boot、esp）[これは私のUbuntuパーティションです]
  • / dev/nvme0n1p6linux-スワップ
  • / dev/nvme0n1p7 ntfs（非表示、診断）

GPartedは、マウントポイント/がnvme0n1p5にあり、マウントポイント/ boot/efiがnvme0n1p2にあることも報告します。

[今私は混乱しています、私のUbuntuマシンはnvme0n1p5（フラグブート付き）またはnvme0n1p2（マウントポイント/ boot/efi付き）から起動しましたか？]

とにかく、両方のパーティションをWindows 10 VMWare-Workstationの物理ディスクハードドライブオプションに接続しようとしましたが、マシンはまだゲストUbuntuを起動しません。

デュアルブートはできますが（BIOSで「ハードドライブの順序」を切り替えることで-[ハードドライブは1つしかないのに！]）、Windows内からUbuntuパーティションをブートして実行したいと思います。

編集2：

私は問題をもう少し理解しているかもしれないと思います：

  1. 最初の起動時に、起動オプションとしてWindows 10EFIを選択します
  2. windowsでは、現在ホストとして実行されているのと同じハードドライブで2番目のパーティションを実行するように仮想マシンをセットアップします
  3. ただし、2番目のパーティションを起動するには、仮想マシンのセットアップに（1）と同じEFIブートマネージャーを実行するように指示する必要があります。
  4. eFIブートマネージャーの実行に失敗し（使用中ですか？）、内部EFIシェルにドロップします
  5. eFIシェルからファイルシステムを選択して/ efi/bootにcdし、そこにいくつかの.efiファイルを表示できますが、それらの.efiファイルから起動する方法がわかりません。

内部EFIシェルから.efiファイルを起動する方法を教えてもらえますか？

linuxwindows-10multi-bootvmware-workstationefi
2
Azrudi

この一部はすでにコメントで取り上げられており、私はVMware製品の専門家ではありませんが、次の点に注意してください。

最初の問題は、/dev/nvme0n1p5のパーティションタイプコードです。 partedの要約によると、このパーティションには「boot、esp」フラグが設定されています。 （余談になる理由から、「boot」と「esp」は同じものを参照する冗長なフラグ名であるため、最近のバージョンのpartedでは常に一緒に表示されます。）parted、GPTディスクの「フラグ」はパーティション属性またはパーティションタイプコードのいずれかであり、「boot、esp」フラグは EFIシステムパーティション（ESP）]のタイプコードです。 このフラグは[〜＃〜] not [〜＃〜]はLinuxルート（/）パーティション-または他のLinuxのみのパーティション。リンク先のウィキペディアのページで説明されているように、ESPは、すべてのOSのブートローダーと関連ファイルを保持するFATパーティションです。 /dev/nvme0n1p5は、Linuxファイルシステムデータ型コードを使用する必要があります。これは、partedが、Linuxファイルシステムのパーティションにパーティションタイプコードフラグがないことを示します。

少なくとも、VMwareに/dev/nvme0n1p2と/dev/nvme0n1p5の両方へのアクセスを許可する必要がありますが、/dev/nvme0n1p6へのアクセスも許可する必要があります。これはLinuxのスワップスペースだからです。このパーティションアクセスの問題を修正しても、全体的な問題は修正されませんが、必要な前提条件になる可能性があります。

残りの部分については、EFIベースのコンピューターの起動方法について少し読むことを強くお勧めします。具体的には、次のうち少なくとも1つ、できれば3つすべてを読んでください。

説明する内部EFIシェルは、DOSプロンプト、Windowsのコマンドプロンプトウィンドウ、またはLinuxのBashシェルに似ています。 cdなどのコマンドを使用してディレクトリを変更したり、lsまたはdirを使用してファイルを表示したりできます。これらのコマンドのほとんどは、DOS/WindowsまたはUnixから借用しています。 EFIブートローダーを含むEFIプログラムには、.efi拡張子があり、次のように名前を入力して実行します。

bootloader.efi

UbuntuはEFIブートローダーをEFI\ubuntu\grubx64.efiとしてインストールしますが、これは通常shimx64.efiと呼ばれるプリブートローダーを介して起動されます。 Shimは、Microsoftのセキュアブートキーによって署名され、コンピューターのセキュアブートサブシステムを拡張して、GRUBとLinuxカーネルを起動できるようにします。仮想化環境がセキュアブートを有効にしてセットアップされている場合は、shimx64.efiを介して起動する必要があります。そうでない場合は、shimx64.efiまたはgrubx64.efiのいずれかを実行できます。

厄介な問題の1つは、元のディスクのビューと一致しないディスクのビューでGRUBが詰まる可能性があることです。つまり、実際のパーティション5がパーティション2のように見える場合、GRUB剥がれ落ちて、作業を拒否する可能性があります。これが発生した場合は、少なくとも1つの環境（実際の環境と仮想化された環境）で別のブートローダーに切り替えることをお勧めします。各環境が独自のブートローダーを使用している場合、それらの構成は根本的に異なる可能性があり、2つの環境は互いに踏むことはありません。また、一部のブートローダーはパーティション番号の変更を気にしません。これは私の rEFIndブートマネージャー、 などにも当てはまります。ただし、GRUBがフレークアウトするかどうかはわからないことを強調したいと思います。その構成ファイルには通常、パーティション番号への参照が含まれていますが（フレークアウトする可能性があることを示唆しています）、それらをオーバーライドする可能性のある「検索」コマンドも含まれています（問題がない可能性があることを示唆しています）。また、VMwareがパーティションのマッピングをどのように管理しているかわかりません。同じパーティション番号を維持している可能性があります。その場合、このため問題は発生しません。

もう1つの質問は、ホストOSがESPのマッピングを許可するかどうかです。これは、ESPが使用中または立ち入り禁止になっている可能性があるためです。その場合、仮想環境のESPとして使用する仮想ディスクまたは別のパーティションを作成する必要がある場合があります。次に、ブートローダーを実際のESPから仮想のものにコピーするか、そこに別のブートローダーをインストールできます。

最後に、私が推奨した読み方で説明されているように、EFIベースのコンピューターはNVRAM常駐データに依存してブートローダーを見つけます。ほとんどの仮想化ソフトウェアは「偽の」NVRAMデータを作成するため、ブートローダーを指す新しいNVRAMエントリを作成しない限り、VMは正常に起動しません。 EFIシェルを使用してOSを一度起動できますが、その後、ブートローダーをVMに登録する必要があります。 Ubuntuでは、これを行うためにefibootmgrを使用します。

Sudo efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\ubuntu\\grubx64.efi -L ubuntu

この例では、Ubuntuの\EFI\ubuntu\grubx64.efiに/dev/sda1をブートローダーとして記録します。セットアップに必要な詳細を変更する必要があります。ディスクIDとパーティションIDは、ホスト環境ではなく、仮想マシン内のものであることに注意してください。

これに関する1つの注意点は、一部のVMは、シャットダウン時にNVRAMエントリを「忘れる」ことです。これは、たとえばVirtualBoxにも当てはまります。 VMwareがもっとうまくいくかどうかはわかりません。そうでない場合は、ブートローダーをESPのフォールバックファイル名（EFI\BOOT\bootx64.efi）にコピーする必要がある場合があります。このアプローチについては、EFIブートローダーに関する私のページで詳しく説明されています。また、AdamWilliamsonのブログでも説明されていると思います。

2
Rod Smith