Forum posts / articles related to this topic:
My Setup
- Windows 11 Pro + Manjaro dual boot
- Windows and Manjaro are installed on separate physical hard drives
- UEFI boots from grub installed on Manjaro. Grub has options to boot from either Windows or Manjaro.
My goal is to be able to keep the option of booting directly into Manjaro while also being able to run the same(not a clone) system on Windows with Hyper-V.
There is nothing specific to Manjaro, so it should also work with other Linux distro.
Steps
Assuming both systems are installed properly and Hyper-V is also installed & enabled on Windows.
1. Disconnect the hard drive with Manjaro installed on Windows
Open a powershell terminal with admin privilege, run disk part, then list disk. This should display a list of disk on your system (they should by default all have 'Online' status). Then run select disk <target disk id number>. Diskpart should respond that the disk has been selected. Run offline disk to set its status to offline. Re-run list disk to confirm that the disk is offline. You can also double-check by going to Windows Disk Management:
2. Create VM in Hyper-V and set the physical drive as its drive
In Hyper-V, create a new generation 2 VM. When asked to connect a virtual hard disk, select 'Attach a virtual hard disk later'. Gen 2 is important as it provides UEFI-firmware, which is what both systems use in my setup.
Go to the setting page of the VM. Under 'Security', disable Secure Boot. Under SCSI Controller, add a hard drive and select 'Physical hard disk'. Select the drive that was disconnected in step 1. If it is not listed as an option under 'Physical hard disk' or the section is greyed-out, re-check if step 1 is performed properly and the hard drive has the proper 'disconnected' status. Then, go to 'Checkpoints' section and disable checkpoints. The setting should look similar to the following image:
3. Fix any potential boot problems
Try to boot the VM as-is and you should be able to see the grub page. If you are lucky (I guess?), you should be able to boot into your linux system with no problem. This was not the case for me, and here are some problems I encountered (in the order they appeared):
Grub reports 'out of range pointer'
I solved this problem by first booting into Manjaro's installation media ISO. You can set this up by adding a DVD Drive in SCSI Controller section of your VM setting and provide the path to the ISO image file of your OS's installation media (in Windows). You can then change the boot order in Firmware section and set DVD drive to be the first option. The installation environment gives the option to detect available EFI boot options. From there, try to boot from grubx64.efi (which should have a path similar to /EFI/Manjaro/grubx64.efi) instead of bootx64.efi (which should have a path similar to /EFI/boot/bootx64.efi). The latter is what's being used by default.
If this solves the 'out of range pointer' issue, you can reboot your PC to your linux system, then overwrite the original bootx64.efi with a copy of grubx64.efi. They should be located in the directory where you mounted the EFI partition. On my Manjaro, the two files are located at /boot/efi/EFI/boot and /boot/efi/EFI/Manjaro. This fixed the 'invalid pointer' problem for me without having to boot into the installation media first. Remember to back up the original bootx64.efi just in case!
ERROR: device not found. skipping fsck
This error happens after grub has successfully initiated the boot sequence. You can first reboot and go to the advanced boot options in grub and try to boot from the alternate image instead. If it still gives the same error, boot into the linux system (physically, not in VM) and replace UUID-based drive/partition indexing with label-based indexing. You can reference this post on how to do so. For me, I deleted all the search --fs-uuid lines and replaced the kernel boot image lines linux ... root=<YOUR_UUID> with linux ... root=LABEL=<YOUR_DRIVE_LABEL>. You may also need to first set the drive labels as they may be unset.
Essentially this problem is caused by the system not being able to find the root hard drive defined in your grub config, either by UUID or by label or by id, which I think is somewhat caused by the change in hard drive layout when using VM (since the system would only be able to see one hard drive in VM). Either of the solution listed above might work.
Service startup failures during boot sequence
When the 'device not found' problem is fixed, you should see the normal linux boot log (XXX: clean, xxx/xxx files, xxx/xxx blocks). At this step, any subsequent error will be related to services on your system that failed to start, probably due to the VM environment (On my system, hardware monitoring sensors failed to start, which is common in a VM environment). These issues have to be solved independently, depending on what services are installed in the system.
No Display
If the boot hangs and there is no display, you can try to press 'Alt+F2' to open a new terminal. If the terminal opens normally and you can login and use the system, then the system has already booted; it is just missing the graphic desktop environment. Most likely it is caused by the linux system using the physical graphic driver of your graphics card instead of using the Hyper-V's virtual graphic driver. I did not try to solve this problem, as I work on CUDA projects and I still want to use the desktop environment normally when I boot my PC in linux, so I did not tamper with graphic driver related settings. Instead, I simply use XRDP and SSH with the VM's IP address.
Failed to complete boot task
At boot time, some boot tasks may be stuck waiting for device and then eventually fail due to timeout. In my environment, this error occurred on Ubuntu but not Manjaro. This is caused by /etc/fstab referencing disks with path/uuid instead of labels. A simple fix is to modify /etc/fstab to use LABEL=<your_label> to index disks instead.
4. Post-boot
If you encountered the 'device not found' error and were able to solve it by using the alternative boot image, you can run mkinitcpio -P after boot to update and regenerate the boot images.
After a successful VM boot, always remember to reboot your PC to double-check if the normal boot is not being interrupted (it should not be!).