[SOLVED] how to boot grubx64.efi after import from Hyper-V

[ljety]

I imported the hard disk with debian from Hyper-V. In Hyper-V machine booted with grubx64.efi firmware and now in Proxmox its hanging during start up.

Inside the firmware I had this:

Value: \HD(1,GPT0310255F-3885-4C33-A5C2-4D3B7E6DFB84,2048,1048576)\EFI\debian\grubx64.efi

Firmware device path: \HD(1,GPT0310255F-3885-4C33-A5C2-4D3B7E6DFB84,2048,1048576)\EFI\debian\grubx64.efi

Guess it has to do something with grub, isn't it? How I can fix the start up?

 

[aaron]

Did you set the BIOS setting of the VM to "OMVF (UEFI)"?

See the manual [0] regarding the need of an EFI disk to store the EFI settings.

You then need to create the UEFI entry again. See the ArchWiki how to use "efibootmgr" to do this [1].

[0]: https://pve.proxmox.com/pve-docs/chapter-qm.html#qm_bios_and_uefi
[1]: https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#efibootmgr

 

[ljety]

Thank you aaron. I found solution in this topic How-to: fix non-booting (Linux) VM imported from a Gen2 VM Hyper-V source.

Solution from GuiltyNL here again:

1. Create a VM in Proxmox like you normally do including a harddisk on 'local'
2. Change the BIOS to OVMF (UEFI) in the Options section
3. Add an EFI disk to that same VM on 'local'
4. Convert your .vdhx disk to .qcow2 with the qemu-img tool (alternatively you can use the qm importdisk command line if you prefer that)
5. Overwrite the empty created .cqow drive Proxmox created with the qcow2 disk you just converted (example: /var/lib/vz/images/111/vm-111-disk-1.qcow2)
6. Boot the VM
7. Connect to the Console of the VM and press ESC immediately. You are now in the BIOS
8. Go to 'Boot Maintenance Manager'
9. Go to 'Boot Option'
10. Go to 'Add Boot Option'
11. Press enter on the 'PciRoot' volume
12. Select EFI and press enter
13. Select the folder of your OS (in my case it was 'ubuntu') and press enter
14. Select the EFI file (in my case it was shimx64.efi) and press enter
15. Fill out a description at 'Input the description' (I called it 'Boot From File')
16. Press F10 to save (just to be sure)
17. Go to 'Commit Changes and Exit'
18. Select 'Change Boot Order'
19. Press enter to get the blue pop-up
20. Go to 'Boot From File' option (or the name you filled out at step 15)
21. Press + until this boot option is on top of the list and press enter
22. Press F10 to save (just to be sure)
23. Select 'Commit Changes and Exit'
24. Exit and voila, your VM boots!

 

[losarbitan]

Thank you aaron. I found solution in this topic How-to: fix non-booting (Linux) VM imported from a Gen2 VM Hyper-V source.

Solution from GuiltyNL here again:

1. Create a VM in Proxmox like you normally do including a harddisk on 'local'
2. Change the BIOS to OVMF (UEFI) in the Options section
3. Add an EFI disk to that same VM on 'local'
4. Convert your .vdhx disk to .qcow2 with the qemu-img tool (alternatively you can use the qm importdisk command line if you prefer that)
5. Overwrite the empty created .cqow drive Proxmox created with the qcow2 disk you just converted (example: /var/lib/vz/images/111/vm-111-disk-1.qcow2)
6. Boot the VM
7. Connect to the Console of the VM and press ESC immediately. You are now in the BIOS
8. Go to 'Boot Maintenance Manager'
9. Go to 'Boot Option'
10. Go to 'Add Boot Option'
11. Press enter on the 'PciRoot' volume
12. Select EFI and press enter
13. Select the folder of your OS (in my case it was 'ubuntu') and press enter
14. Select the EFI file (in my case it was shimx64.efi) and press enter
15. Fill out a description at 'Input the description' (I called it 'Boot From File')
16. Press F10 to save (just to be sure)
17. Go to 'Commit Changes and Exit'
18. Select 'Change Boot Order'
19. Press enter to get the blue pop-up
20. Go to 'Boot From File' option (or the name you filled out at step 15)
21. Press + until this boot option is on top of the list and press enter
22. Press F10 to save (just to be sure)
23. Select 'Commit Changes and Exit'
24. Exit and voila, your VM boots!

You are my hero thanks. This also fixed my problem after I changed my cluster node's hostname and the vm that used a local drive for storage did not want to boot anymore.