Estação de trabalho VMware usando o disco físico EFI

Estou tentando configurar uma VMware Virtual Machine em um host do Windows 10.

Atualmente tenho 1 disco rígido dividido em 2 partições, atualmente usando o Ubuntu com inicialização dupla.

Eu gostaria de montar o Ubuntu como convidado no host do Windows.

Eu tenho tentado configurar a partição do Ubuntu usando a opção de disco físico em VMware (eu tentei IDE, SCSI, Sata). Se eu disser ao VMware para usar o disco inteiro, receberei a mensagem "o disco atual está em uso". Se eu selecionar apenas as partições relevantes do Linux, ele dirá "Não é possível localizar o sistema operacional".

O que é estranho é que minha partição Linux está aparecendo como "sistema Efi" na coluna File System, enquanto eu pensei que deveria dizer "Linux" em File System. Devo tentar primeiro mudar o sistema de arquivos dessa partição para o Linux em vez do Efi? (Como eu faria isso?)

O VMware deve ser capaz de permitir que eu execute uma partição do Ubuntu como convidado, mesmo que esteja no mesmo disco rígido que o host, certo?

Edit: Para esclarecer, as informações acima são relatadas pelo VMware-Workstation.

No entanto, no Ubuntu Gparted é assim que minhas partições se parecem:

Meu disco rígido SSD atual está configurado desta forma (de acordo com o Linux GParted)

• / dev / nvme0n1p1 ntfs (diag)
• / dev / nvme0n1p2 fat32 (boot, esp)
• / dev / nvme0n1p3 desconhecido (msftres) [Partição reservada da Microsoft, seja o que for]
• / dev / nvme0n1p4 ntfs (msftdata) [Esta é a partição do Windows 10]
• / dev / nvme0n1p5 ext4 (boot, esp) [Esta é a minha partição Ubuntu]
• / dev / nvme0n1p6 linux-swap
• / dev / nvme0n1p7 ntfs (oculto, diag)

O GParted também informa que o ponto de montagem / está em nvme0n1p5 e ponto de montagem / boot / efi em nvme0n1p2.

[agora estou confuso, a minha máquina Ubuntu inicializou do nvme0n1p5 (com a inicialização de sinalizador) ou o nvme0n1p2 (com o ponto de montagem / boot / efi)?]

De qualquer forma, eu tentei anexar ambas as partições à opção de disco rígido de disco físico do Windows 10 VMWare-Workstation, mas a máquina ainda não inicializa o Ubuntu convidado.

Eu posso dual-boot (comutando "ordem de disco rígido" no BIOS - [embora haja apenas um disco rígido!)), Mas o que eu gostaria de fazer é inicializar e executar a partição do Ubuntu de dentro do Windows.

Editar 2:

Eu acho que posso estar entendendo o problema um pouco mais:

1. na primeira inicialização, seleciono o Windows 10 EFI como opção de inicialização
2. no windows, eu configurei uma máquina virtual para executar a segunda partição no mesmo disco rígido que está sendo executado atualmente como host
3. mas para inicializar a segunda partição, devo informar a configuração da máquina virtual para executar o mesmo gerenciador de inicialização EFI que (1)
4. ele falha ao executar o gerenciador de inicialização EFI (está em uso?) e me solta em um shell EFI interno
5. do EFI Shell Eu posso selecionar um sistema de arquivos e cd em / efi / boot e ver alguns arquivos .efi lá, mas eu não sei como inicializar a partir desses arquivos .efi.

Alguém pode me dizer como inicializar um arquivo .efi do shell EFI interno?

Parte disso já foi abordada nos comentários e não sou especialista em produtos VMware, mas:

Seu primeiro problema é o código do tipo de partição /dev/nvme0n1p5. De acordo com seu partedresumo, essa partição tem seu conjunto de sinalizadores "boot, esp". (Por razões que seria uma digressão, "boot" e "esp" são nomes de sinalizadores redundantes que se referem à mesma coisa, então eles sempre aparecem juntos em versões recentes de parted.) Em parted"sinalizadores" em discos GPT podem ser tanto partições atributos ou códigos de tipo de partição, e o sinalizador "boot, esp" é um código de tipo para a partição de sistema EFI (ESP). Esse sinalizador NÃO deve ser definido em uma /partição root ( ) do Linux - ou em qualquer outra partição somente do Linux. Como a página da Wikipedia à qual eu fiz a ligação explicou, o ESP é uma partição FAT que contém gerenciadores de inicialização e arquivos relacionados para todos os sistemas operacionais. Seu/dev/nvme0n1p5deve usar o código de tipo de dados do sistema de arquivos Linux, que partedidentifica como ausência de sinalizadores de código de tipo de partição em uma partição com um sistema de arquivos Linux.

No mínimo, você precisará dar acesso à VMware para ambos /dev/nvme0n1p2e /dev/nvme0n1p5, mas também pode querer dar acesso /dev/nvme0n1p6, já que esse é o espaço de troca do Linux. Corrigir esse problema de acesso à partição não corrigirá seu problema geral, mas provavelmente será um pré-requisito necessário.

Para o resto, eu recomendo fortemente que você leia um pouco sobre como um computador baseado em EFI é inicializado. Especificamente, leia pelo menos um, e de preferência todos os três, do seguinte:

• Entrada do blog de Adam Williamson sobre como o EFI funciona - Esta página descreve a teoria por trás do modo de inicialização EFI.
• Uma pergunta e respostas sobre as diferenças entre o BIOS e a inicialização EFI no Superuser.com - Isso fornece os fundamentos do precedente, mas é mais conciso.
• Minha página em carregadores de inicialização EFI para Linux - Esta página descreve as opções do carregador de boot EFI para sistemas Linux. Leia a página introdutória e as subpáginas sobre princípios e instalação do gerenciador de inicialização EFI; você pode pular a maioria das páginas em carregadores de boot específicos, a menos que você esteja interessado em instalar algo fora do padrão.

O shell EFI interno que você descreve é ​​semelhante a um prompt do DOS, uma janela do Prompt de Comando no Windows ou um shell Bash no Linux. Você pode usar comandos como cdalterar diretórios lsou dirver arquivos, etc .; a maioria desses comandos é emprestada do DOS / Windows ou Unix. Os programas EFI, incluindo os carregadores de inicialização EFI, possuem .efiextensões e você os executa digitando seus nomes, como em:

bootloader.efi

O Ubuntu instala seu gerenciador de inicialização EFI como EFI\ubuntu\grubx64.efi, embora isso geralmente seja iniciado por meio de um pré-carregador de inicialização chamado shimx64.efi. O Shim é assinado pela chave de inicialização segura da Microsoft e estende o subsistema de inicialização segura do computador para permitir que o GRUB e o kernel do Linux sejam inicializados. Você precisará iniciar via shimx64.efise seu ambiente virtualizado estiver configurado com inicialização segura ativada. Se não, você pode executar shimx64.efiou grubx64.efi.

Uma complicação é que o GRUB pode sufocar em uma visualização do disco que não corresponde à do disco original - isto é, se a partição real 5 parecer ser a partição 2, o GRUB pode se desintegrar e se recusar a funcionar. Se isso acontecer, recomendo alternar para outro carregador de inicialização em pelo menos um ambiente (real versus virtualizado). Se cada ambiente usa seu próprio gerenciador de inicialização, suas configurações podem diferir radicalmente e os dois ambientes não interferem uns nos outros. Além disso, alguns carregadores de inicialização não se importam com os números de partição alterados. Isto é verdade para o meu gerenciador de boot rEFInd, por exemplo. Eu gostaria de enfatizar, porém, que eu não seise o GRUB for desconectado. Seu arquivo de configuração normalmente inclui referências a números de partição (o que sugere que ele pode falhar), mas também inclui comandos de "pesquisa" que podem anular esses (o que sugere que pode ser OK). Além disso, não sei como o VMware gerencia o mapeamento de partições; eles podem manter os mesmos números de partição, caso em que não deve haver problemas por causa disso.

Outra questão é se o sistema operacional host permitirá mapear o ESP, pois ele pode estar em uso ou fora dos limites para isso. Nesse caso, talvez seja necessário criar um disco virtual ou outra partição para ser usado como um ESP para o ambiente virtual. Você pode então copiar o carregador de boot do ESP real para o virtual real ou instalar um carregador de boot diferente nele.

Por fim, conforme descrito nas leituras que recomendei, os computadores baseados em EFI contam com dados residentes em NVRAM para localizar o carregador de boot. A maioria dos softwares de virtualização cria dados "falsos" de NVRAM, portanto, uma VM não inicializa normalmente, a menos que você crie novas entradas NVRAM para apontar para o carregador de boot. Você pode usar o shell EFI para iniciar seu SO uma vez, mas precisará registrar o carregador de boot com a VM. No Ubuntu, você usaria efibootmgrpara fazer isso:

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

Este exemplo registra \EFI\ubuntu\grubx64.efino Ubuntu /dev/sda1como um gerenciador de inicialização. Você deve alterar os detalhes conforme necessário para sua configuração. Observe que os IDs de disco e de partição são aqueles na máquina virtual, não no ambiente host.

Uma ressalva é que algumas VMs "esquecem" suas entradas NVRAM quando você as encerra. Isto é verdade para o VirtualBox, por exemplo. Não tenho ideia se a VMware melhora. Caso contrário, talvez seja necessário copiar o carregador de boot para o nome de arquivo de fallback ( EFI\BOOT\bootx64.efi) no ESP. Essa abordagem é descrita com mais detalhes em minha página sobre os carregadores de inicialização EFI e também no blog de Adam Williamson.