Clonei um disco formatado em GPT que contém um dual boot (Windows + Linux Debian) que funciona perfeitamente bem na máquina real.
Tentei criar uma VM com o Qemu que usa o disco clonado para inicializar na partição Debian, mas o melhor que consegui fazer foi inicializar o Windows.
Aqui está o comando que usei:
virt-install \
--name "vm-test_dual_boot" \
--boot loader=/usr/share/OVMF/OVMF_CODE.fd \
--vcpus 2 --memory 8192 --osinfo debian11 \
--network bridge=br0 \
--graphics=vnc \
--disk path=/home/user/vm/clone.qcow2 \
--import -v
Não consigo fazer a mesma coisa que a máquina UEFI real que associa um HD(1,GPT,unique_identifier)
sistema de arquivos ao \EFI\debian\shimx64.efi
arquivo.
Você poderia me ajudar a inicializar o Debian?
Graças ao @telcoM alterei o comando em:
boot_config=\
"loader=/usr/share/OVMF/OVMF_CODE_4M.fd,"\
"loader.readonly=yes,"\
"loader.type=pflash,"\
"nvram.template=/usr/share/OVMF/OVMF_VARS_4M.ms.fd,"\
"nvram=/home/user/vm/clone_nvram.fd" ;
virt-install \
--name "vm-test_dual_boot" \
--boot $boot_config \
--vcpus 2 --memory 8192 --osinfo win10 \
--network bridge=br0 \
--graphics=vnc \
--disk path=/home/user/vm/clone.qcow2 \
--import -v
Notas:
do diretório
/usr/share/OVMF
loader
deve corresponder aonvram.template
entãoOVMF_CODE_4M.fd
paraOVMF_VARS_4M.ms.fd
, então no meu caso isso disparou este erro: "O convidado não inicializou o display (ainda)".o usuário definido em
/etc/libvirt/qemu.conf
(padrão :libvirt-qemu
), deve ter direitos de leitura e execução nonvram
arquivo, caso contrário isso acionará um erro de permissão.no meu caso
--osinfo win10
é obrigatório, pois a inicialização EFI vHD padrão é o Windows (antes eu tentava,debian11
mas terminava em BSOD ).para a
--network
parte assume-se que temos umbr0
dispositivo de ponte (veja aqui para ponte temporária comNetwork Manager
ou aqui comiproute
e aqui para ponte permanente comifup
).
Depois de criada, configure a VM EFI para inicializar a partição correta (veja a resposta detalhada de @telcoM para fazer isso temporariamente ou permanentemente).
Você não definiu um armazenamento NVRAM para variáveis de boot, então não há lugar para armazenar persistentemente as variáveis de boot UEFI. Como resultado, o sistema sempre retornará para a inicialização de
\EFI\boot\bootx64.efi
... e, por padrão, o Windows coloca seu bootloader de backup lá.Você precisará fazer algo como:
Isso reservará um espaço para as configurações de inicialização UEFI na forma de um pequeno arquivo localizado em
/home/user/vm/clone_nvram.fd
. Este arquivo representará o armazenamento NVRAM persistente na placa-mãe virtual.A VM de inicialização dupla ainda inicializará no Windows na primeira vez, porque o caminho do bootloader de fallback ainda mantém o bootloader do Windows (e a "autocorreção" do Windows moderno provavelmente o manterá assim).
O próximo passo é entrar no menu de configurações de inicialização do firmware UEFI da VM. Se você for realmente rápido, pode conseguir chegar lá pressionando F2enquanto a VM estiver inicializando, mas uma maneira mais fácil é dizer ao Windows para reinicializar e ir lá na próxima inicialização (da Microsoft ):
Uma vez lá, você pode ir para
Boot Maintenance Manager
o submenu, selecionarBoot from File
, selecionar seu disco virtual, então selecionar a<EFI>
pasta, então a<debian>
subpasta e então oshimx64.efi
arquivo. Isso permitirá que você inicialize o GRUB, e assim o Debian, na VM.Para criar uma entrada de inicialização persistente para o GRUB, use
grub-install --target=x86_64-efi /dev/sda
(supondo que seu disco do sistema seja/dev/sda
; se seu disco do sistema for/dev/vda
, ajuste adequadamente) para reinstalar o carregador de inicialização GRUB e reescrever a variável de inicialização UEFI para ele.(Você também pode fazer isso usando o
efibootmgr
comando, mas usargrub-install
provavelmente é mais fácil.)Ao clonar um sistema Linux não dualboot, você pode evitar complicações como essa com sistemas UEFI (virtuais ou não) fazendo um
no sistema original antes de cloná-lo. Isso colocará uma segunda cópia de
shimx64.efi
para/boot/efi/EFI/boot/bootx64.efi
, o que efetivamente tornará o disco (e seus clones futuros) UEFI-bootáveis mesmo se as configurações de NVRAM forem perdidas... ou deixadas para trás no chip UEFI NVRAM do sistema original ao clonar sistemas ou convertê-los em VMs.