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

2

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?

Azrudi
fonte
Duas perguntas: 1) O que você está usando? ([VMware] é uma empresa, por favor altere as tags para [vmware-player], [wmware-workstation] etc). 2) [u] EFI usou uma partição FAT32 para inicializar todos os sistemas operacionais. Aquele pode estar em uso. Você pode tornar mais explícito o que você quer dizer quando escreve aquela linu xis aparecendo como sistema efi?
Hennes
Obrigado ou a resposta. 1) Avaliação do VMware-Workstation. 2) Eu atualizei minha estrutura atual de disco rígido no post original.
Azrudi
Eu acho que o meu problema é o sistema EFI. Eu tentei o Oracle VirtualBox e passei pela configuração vboxmanage para usar um disco bruto - e depois de conectar o disco bruto ao Virtualbox, ele ainda não me permite inicializar normalmente ou como EFI. 1) inicialização normalmente resulta em nenhum sistema operacional encontrado 2) escolhendo "boot EFI em vez de BIOS" me leva a um estranho EFI Internal Shell Menu e eu posso retornar ao EFI Boot Manager e navegar "Set Boot Option" para encontrar grubx64.efi, mas selecionar esse arquivo não faz nada, mas estou esfaqueando no escuro, na verdade.
Azrudi
ESP (partição do sistema EFI) é a partição normalmente usada para armazenar os gerenciadores de inicialização para todos os sistemas operacionais. Geralmente, há apenas uma partição sunch e, a menos que você tenha um MAC, ele é formatado com FAT32. Agora, quando eu olho para / dev / nvme0n1p5 eu vejo que é ext4 e é a sua partição Ubuntu. Também é marcado esp. Isso me confunde.
Hennes
re 3). Eu estou fora da minha profundidade aqui. Mas você pode verificar se o ESP não está montado pelo Windows? Na maioria das vezes, as janelas parecem deixar isso de lado (por exemplo, tive que forçar minha instalação atual do Windows a mapear uma letra de unidade para ele), mas a verificação do mais recente dói. Caso contrário, bom post. Espero que seja respondido com uma solução adequada.
Hennes

Respostas:

2

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:

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.

Rod Smith
fonte
Obrigado, eu vou passar por isso esta noite. Parece muito abrangente. Eu quero perguntar isso agora, só para esclarecer: eu deveria ser capaz de digitar shimx64.efi em seu diretório em (eu acho / boot / EFI) o shell EFI interno e se não houver nenhum outro problema eu normalmente deveria estar capaz de inicializar o convidado Linux? Vou ler os blogs e sua resposta com mais detalhes quando voltar para casa hoje à noite. Eu removi o boot e esp flag em nvme0n1p5 usando o Free Minitool Partition Wizard para Windows, mas ainda não vejo diferença antes de sua resposta.
Azrudi
Oi Rod, eu li o terceiro link. A maioria foi um pouco acima da minha cabeça neste momento, mas eu li a parte sobre o carregador de stub EFI. Eu tentei replicar, mas tenho erros estranhos que eu não entendo: i.imgur.com/F4RRACw.png Ele diz parâmetros inválidos, mas eu incluí todos os parâmetros relevantes. Você pode ajudar a traduzir em termos leigos? Note que eu acho que a partição EFI em si é bom porque eu posso inicializar o Ubuntu se eu inicializar a partir do BIOS (aquele em que eu pressiono a tecla del quando o logo do fabricante aparece)
Azrudi
3
Eu tenho que trabalhar! Fiz 3 alterações: 1) removi o boot & esp flag com o Minitool Partition Wizard e o rotulei como partição msftdata (ou Partition ID = Partição de Dados Básicos do Windows no Minitool) 2) alterado em VM> Configurações> Opções> Geral> Versão do Ubuntu para Ubuntu 64-bit 3) mudou o disco rígido em VM> Configurações> Disco Rígido (SCSI)> verificar partição EFI, partição raiz e partição swap, clique no botão Avançado e pegou Modo> Independente> Não persistente Agora funciona! Sem (3) eu tenho "disco rígido inacessível \\. \ PhysicalDrive0". Marcou isso como solução.
Azrudi