[Solved] Scripted VM suddenly starts throwing CPU errors, but only with a scripted VM

[bruce.desertrat]

I've got a simple script set to build a Windows 10_64 VM on our Mac hosts via our MDT system that has been working fine, and I'm not sure where the issue is.

The problem is that on the initial boot to the LiteTouchPE boot ISO I'll get the bluescreen error: "Kernel Security Check Failure". Windows has not been installed on the system yet; I can't find anything online about this error that doesn't say 'roll back to the previous version of Windows'.

Host OS OS X 10.13.6 or 10.12.6

The script I'm using is this (it is run as root via 'sudo -s' to get a root shell):

Code: Select all

VBoxManage createhd disk --filename /Users/Shared/VirtualBoxVMS/HDs/Win10.vdi --size 81920
VBoxManage createvm --register --name "Windows10" --basefolder /Users/Shared/VirtualBoxVMS/VMfiles
VBoxManage storagectl "Windows10" --name "SATA Controller" --add sata --controller IntelAHCI
VBoxManage storageattach "Windows10" --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium "/Users/Shared/VirtualBoxVMS/HDs/Win10.vdi"
VBoxManage storagectl "Windows10" --name "IDE Controller" --add ide
VBoxManage storageattach "Windows10" --storagectl "IDE Controller" --port 0 --device 1 --type dvddrive --medium /Volumes/copds2013/Boot/LiteTouchPE_mdt2013_internal_x64.iso
VBoxManage modifyvm "Windows10" --ostype Windows10_64 --memory 3072 
VBoxManage modifyvm "Windows10" --acpi on --ioapic on
VBoxManage modifyvm "Windows10" --nic1 nat --nictype1 82540EM --cableconnected1 on --usb on --clipboard bidirectional --accelerate3d on --accelerate2dvideo on
VBoxManage modifyvm Windows10 --audio coreaudio --audiocontroller hda --vram 128
VBoxManage sharedfolder add Windows10 --name SharedWithMac --hostpath /Users/Shared/VirtualboxVMS/SharedWithMac --automount
VBoxManage startvm Windows10

Now as far as I can tell the ISO has not been modified since the last time it worked, the modification date in the MDT server is back in June, I successfully built two of them since. This happens in both the latest version of VirtualBox and the one I used the last time it worked.

MDT has no logs I can determine because it never actually boots to the MDT interface.

The script runs without errors, it's just that the VM will not boot. I get the blue Windows logo on a black screen, the littler spinner dots start, it freezes there and eventually bluescreens.

If I build a Windows 10_64 system in the GUI, configured as far as I can tell the same way as the script, and using the MDT iso file to boot from, it works: The system boots and proceeds to the MDT setup windows.

Is there a way to extract the requisite VBoxManage commands to create a VM from a VDI file? That way I could see what would be set from the GUI-generated VDI and maybe find what's causing my script-built VM to fail

[socratis]

Try defining the port count:

• VBoxManage storagectl "Windows10" --name "SATA Controller" --portcount 2

or by amending your existing command:

• VBoxManage storagectl "Windows10" --name "SATA Controller" --add sata --controller IntelAHCI --portcount 2

I have no clue what the "LiteTouchPE boot ISO" or what it does, but can you try with a standard Windows 10 ISO? https://www.microsoft.com/en-us/softwar ... ndows10ISO

Is there a way to extract the requisite VBoxManage commands to create a VM from a VDI file?

You can compare the VM that you created via the script, with a standard VM created from the GUI. The VM recipes are simple text files, simply with a .vbox extension. Use FileMerge from Xcode (if you have it) or TextWrangler. Or whatever file comparison program works for you. 'diff' could also work...

PS. Moving to "Using VirtualBox" since the "OSX host" is not important. If anything, the Win10 guest and its LiteTouchPE might turn out to be.

[bruce.desertrat]

MDT is "Microsoft Deployment Toolkit" and the liteTouch iso is the boot iso to present the pre-scripted dialog to deploy a Windows desktop.

https://docs.microsoft.com/en-us/window ... nt-toolkit see https://docs.microsoft.com/en-us/window ... components

The script worked when I tried it on a PC running Windows 10 and the same version of VirtualBox, so the issue is peculiar to an OS X host, but since a GUI config with the same iso as the failing one worked, I don't think it's the MDT environment something that the GUI is setting is something I"m not doing in my script.

Thanks for the info about the VBox files, I'll do that. Being able to use MDT is a huge time saver for me; makes installing Windows almost as pain free as installing OS X

[socratis]

The script worked when I tried it on a PC running Windows 10 and the same version of VirtualBox, so the issue is peculiar to an OS X host

Not really. I tried your script on my OSX host. I copied pasted the commands. The only difference was the ISO that I used when booting the VM. And just to be exact, here's the difference and the output:

...
$ VBoxManage storageattach "Windows10" \
           --storagectl "IDE Controller" \
           --port 0 \
           --device 1 \
           --type dvddrive \
           --medium /Volumes/750-VBox/___LiveDVDs/Win10_1803_English_x64.iso
...
$ VBoxManage startvm Windows10
Waiting for VM "Windows10" to power on...
VM "Windows10" has been successfully started.

So, can you try with the Microsoft ISO and see what's going on?

The only "issue" that I saw when I was starting the VM was the following messages:

ata0  slave: VBOX CD-ROM ATAPI-6 CD-ROM/DVD-ROM
ata2 master: Unknown device
ata2  slave: Unknown device
ata3 master: Unknown device
ata3  slave: Unknown device

which was fixed when I modified the port count.

[bruce.desertrat]

Well, upon adding the --portcount 2 option to the storagectl commands...it now works. Either that or the phase of the moon has shifted enough for it to work, because I don't see how the storage control error would cause the CPU error I saw, but I'll take the win.

Thanks for your help!

[socratis]

Well, upon adding the --portcount 2 option to the storagectl commands...it now works.

Great, thanks for the feedback. Marking as [Solved].

Either that or the phase of the moon has shifted enough for it to work

You can easily try it again, just remove the "portcount" option...

I don't see how the storage control error would cause the CPU error I saw

Same here. Doesn't necessarily compute, but I remember that they started matching the ports available to the ports actually used because there were problems in the resource allocation (if memory serves me right).