I have a dual-boot setup on my computer, the Windows 10 was already installed and is locked to the hardware („digital license“). After resizing the Windows partition, I was able to install ubuntu as a secondary operation system. I could change between system after a reboot, but I was unsatisfied that I had to reboot from Linux to Windows only for a short usage of the latter.
So I installed VirtualBox and instead of creating a new virtual Windows 10 which would require a different license, I figured out how to use the raw partition with the activated windows 10 within VirtualBox.
VirtualBox does support access to the raw disk, but there are some ceavats that need to be considered.
First, you’ll have to figure out which partition are EFI and belong the Windows 10 as well. Using gparted, you’ll quickly find the partitons which are labeled like this:
EFI system partition (fat32)
Microsoft reserved partition (unknown)
Basic data partiton (ntfs)
Using these partition information, you can now create a „raw vmdk“ file which can be used by VirtualBox. If the mentioned partitions are for example /dev/sda1, /dev/sda2 and /dev/sda3, issue this command (compensate for different device names, if necessary):
sudo VBoxManage internalcommands createrawvmdk -filename win10native.vmdk -rawdisk /dev/sda -partitions 1,2,3 -relative
I have named the raw file here „win10native.vmdk“, it will create a secondary file with „-pt.vdmk“ at the end, we won’t be using it here, but please leave it where it is. Now change the ownership of these two files to the user you want to use VirtualBox with (change „user“ and „group“ accordingly):
sudo chown -R user:group win10native*
Your current user must have disk access to continue. Beware, this literally means that this user is essentially given root rights as he can access all data on any disc. (Change „user“ accordingly)
sudo usermod -aG disk,vboxusers user
Enable „EFI“-Support in your System Settings of your VirtualBox.
If you would boot now your new virtual machine with the win10native.vmdk attached, Windows 10 can be booted, but as it detects different hardware, it will complain that it is not activated. To circumvent this, we have to read your system-uuid and write it to the virtual machine. The following command will print you the ID:
sudo dmidecode -s system-uuid
Modify your VM to change the system-uuid to the value you have just received (correct the XXX accordingly):
VBoxManage modifyvm Win10native --hardwareuuid XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
If you boot now, you’ll most certainly only see a shell from „GRUB 2.02“ or something similar, as grub can’t find the Windows bootloader, this information is missing inside the UEFI from VirtualBox (and grub can’t find its root partition). To test your windows installation and activation, simply type these commands (you might have to change the „(hd0,gpt1)“-part – in fact, as the „root“ variable was already pointing to the correct device, I didn’t need to change it at all) and you can boot into windows. Remember that you only have the US-keyboard-layout.
And here’s the result with an activated Windows 10 within Virtual Box. I can still boot native into Windows 10 without any further trouble. Don’t forget to install the VirtualBox Guest Addins for more comfort.
To circumvent the grub shell, you’ll have to enter the UEFI of VirtualBox. Boot the VM and immediatly (!) hit the F12-Button to enter the settings.
Add Boot Option and select the entry beginning with „SYSTEM“, this will let you traverse the directory path. Navigate to EFI/Microsoft/Boot/bootmgfw.efi and press ENTER. Add something at „Input the description“, press „F10“ and acknowledge with „Y“ then commit your changes.
In Boot -> Change Boot Order, select the EFI-Entry together with your newly created entry, highlight your entry and press „+“ until it is on the very top.
As the last step, „Reset system“ and it will boot Windows 10 directly. The changes made here a NOT permanent and will be lost the next time you boot (hey, at least you don’t have to type all those command on a us-layout-keyboard). This is a known issue by VirtualBox.