I have created a Windows 10 vagrant box by exporting an existing VM from Hyper-V, adding a metadata.json file, deleting the snapshot folder, then creating a tar archive and gzipping the tar. I then add it to the box catalog by running
vagrant add ...
No problem so far.
If I try to up a new instance of the box, it fails with:
Script: import_vm.ps1
Error:
Failed to import a virtual machine.
Error Code: 32784
Cause: VM version is unsupported
To test the contents of the VM, I tried to manually import the VM from the export folder. Import works fine, so it's not that the disk files etc are corrupt.
Considering that I am importing on the same machine that I exported from, how is it possible that the version is not supported?
There seems to have previously been a bug in vagrant with these symptoms but it was fixed 2.5 years ago: https://github.com/hashicorp/vagrant/issues/7706.
I am running Windows 10 (1607 - OS Build 14393.2759), Hyper-V 10.0.14393.0 and Vagrant 2.2.4.
Any assistance greatly appreciated.
Apologies for the late reply. As a first step, check the validity of your image. To do this see what happens if you import the VM directly through the Hyper-V Manager. This will rule out any issues with the version of vagrant you are using. I suspect Hyper-v manager will not be able to import the image either. The next thing I'd try is to upgrade your hyper-v version.
Related
VirtualBox 6.1.28 fails to start a box on Windows with the following error:
Failed to load R0 module C:\Program Files\Oracle\VirtualBox/VMMR0.r0:
SUP_IOCTL_LDR_OPEN failed (VERR_LDR_GENERAL_FAILURE).
Failed to load VMMR0.r0 (VERR_LDR_GENERAL_FAILURE).
VirtualBox v. 6.1.28 is buggy, use another version (e.g. 6.1.26 or 6.1.32) which you can download from https://www.virtualbox.org/wiki/Download_Old_Builds_6_1
The issue is tracked as https://www.virtualbox.org/ticket/20694 and was fixed in v. 6.1.32.
A workaround...
https://www.virtualbox.org/ticket/20694
"The Windows Hypervisor-enforced Code Integrity (HVCI) feature rejects the VirtualBox component VMMR0.r0 (*). A workaround is to disable HVCI aka Memory integrity as follows:
On your Windows host, go to Start > Settings > Update & security > Windows Security > Device security > Core isolation details, turn off Memory integrity and reboot the Windows host.
(*) In the Windows Event Log, under Applications and Service Logs\Microsoft\Windows\CodeIntegrity\Operational, an event with ID 3111 ("The file under validation did not meet the hypervisor-protected code integrity (HVCI) policy.") is logged."
Fixed moving to 6.1.26
On Windows 10:
Uninstall VirtualBox using the control panel "Program and functionalities" tool. DO NOT RESTART YET.
Manually check for the following folders and remove them if they are still there:
C:\Program Files\Oracle\VirtualBox
C:\Program Files (x86)\Oracle\VirtualBox
Note: The folders can be in a different place depending where you installed Oracle VirtualBox; make sure to check the correct folder in case you changed the installation directory.
Go to your %userprofile% directory (eg: C:\users\me) and delete the folders:
.VirtualBox
VirtualBox VMs
Go to RegEdit (WIN+R and type regedit) and click on Computer at the very top.
Then click on "Edit" > "Search" or hit CTRL+F. Type virtualbox and tick all checkboxes.
Find the key Oracle > VirtualBox. It should be in
Computer\HKEY_CURRENT_USER\SOFTWARE\Oracle\VirtualBox
Remove the VirtualBox key.
IMPORTANT: RESTART NOW. Restart your computer!
Install VirtualBox again with the new version.
Thanks to: https://forums.virtualbox.org/viewtopic.php?t=82689
I had the same problem and found a solution. You have to open Oracle VM VirtualBox.exe and move into your machine settings, make sure that in Controller: SATA you have only .iso of your machine, if you have something else, delete it, close Oracle VM VirtualBox. In Control panel find programs and features, delete your Oracle VM VirtualBox. Then download Oracle VM VirtualBox again, it's not necessary, which version you will launch but better the latest or the same you had before. After installation check out a capability of your machine, if it works, you may add other .iso back, if it doesn't work, open settings again and Controller: SATA delete all .iso exclude your machine .iso, then launch the machine again.
It works with my virtual machines, if it's not relevant to your occasion, you can try other variants.
I'm trying to test my development environment and keep getting this error while going through the "Building Your First Network". I've installed the prerequisites on a Windows 10 Home edition so I'm using Docker Toolbox. The error is described as follows and happens just after a execute the ./byfn.sh up -l node command:
2019-11-14 17:06:26.982 UTC [msp] loadCertificateAt -> INFO 002 Failed loading ClientOU certificate at [/var/hyperledger/orderer/msp/cacerts\ca.example.com-cert.pem]: [could not read file /var/hyperledger/orderer/msp/cacerts\ca.example.com-cert.pem: open /var/hyperledger/orderer/msp/cacerts\ca.example.com-cert.pem: no such file or directory]
As you can see there is a backslash just before the ca.example.com-cer.pem which I think is causing the problem. Anyone have an idea of how I might solve this issue?
Docker Toolbox for windows doesn't provide a great experience for users. It's limited in how it can share windows directories with linux containers running in the linux VM it creates. I believe it can be made to work but you have to use very specific folders in your home directory and you would have to google it to find all the details but it's a lot more of a hassle.
You have other options of course
Upgrade to Windows Pro and use Docker for Windows (which doesn't have the same sharing limitations, but still not a great experience and you can still encounter problems sharing the directories)
Install a hypervisor such as virtualbox and run a linux desktop distribution such as ubuntu or mint and use that instead (which I would recommend and would suggest ubuntu 18.04 mate edition)
Wait until next year when hopefully microsoft will release WSL2 for everyone (including home edition) and then Docker won't need a linux VM running and it should be a much better experience trying to run linux containers on windows.
As mentioned by lindluni here
Backslash problem in Hyperledger 2.0.1 when orderer/peer look for .pem files
the problem arises when one creates crypto artifacts under Windows since "golang filepath.Join uses the current OS's filepath scheme". Hence, under Windows backslash is used in all the generated config.yaml files found in crypto-config/*. One can replace this backslashes before the deployment to fix the issue.
So, I'm trying to run vagrant package on my current Vagrant VM, and it seems to be working fine(no errors reported); however, it is not saving the file to the location that it reports to be saving it. I cannot locate the file anywhere else on the system either, so I'm not sure if it's actually being created or if the command is silently failing.
I am running Vagrant 1.6.1 on Windows 8.1 and using virtualbox as my hypervisor. Are there logs that I can be looking at which might help diagnose the problem?
I figured out what the issue was. This is specifically related to using vagrant on windows with mingw. A DLL dependency is screwed up for bsdtar, so if you follow the steps in http://sourceforge.net/p/mingw/bugs/2150/, you should be fine.
Failed to load VMMR0.r0 (VERR_LDR_MISMATCH_NATIVE)
My VMs on Virtualbox 4.2 (on Windows 7 32-bit) were running absolutely fine until I started installing a new VM, which would not go beyond the Linux boot screen.
I deleted the VM and created new one, but it still didn't run.
So I installed the new version of VirtualBox (version 4.3.6.r91406) and rebooted the machine; but when I started any of my previously working VMs, I got the following error
Failed to open a session for the virtual machine m14
Failed to load VMMR0.r0
(VERR_LDR_MISMATCH_NATIVE
with the following details:
Result Code: E_FAIL (0x80004005)
Component: Console
Interface: IConsole
{8ab7c520-2442-4b66-8d74-4ff1e195d2b6}
On checking the forums, I saw few posts asking to check the .vbox files. In the directory of the VM, there are two, m14.vbox and m14.vbox-prev.
I removed the prev file and restarted the VM, again got same error, and the m14.vbox-prev file came again. So I then removed the original m14.vbox file and renamed the prev file to original and then started the VM: it still didn't work.
Any clues fixing this?
Hi I had the same problem in version 4.3
I disabled the floppy and the CD into the system configuration of the virtual machine and then the machine has started properly without realizing the error.
Add or update the extension pack.
If that doesn't solves the problem, then uninstall the Virtual Box, delete the following folder:
C:\USERS\<username>\AppData\Local\VirtualStore\Program Files\Oracle
then install Virtual Box again and run it as administrator. (In some cases running it as simple user may work too.)
Run as Administrator
I had the same problem after updating from 4.1 or 4.2, to 4.3.18.
I didn't reboot and the "Right click Virtualbox icon - Run as Administrator" technique worked for me (in Windows).
pls run the vbox-ssl-cacertificate.crt file. That may resolve above problem. This solution works for me.
FINALLY.
A while back I turned on ASLR for everything using EMET. Running EMET again and changing it back to the default of "Application OptIn" + reboot fixed it.
Like akshah123 I had driver verifier (verifier.exe) running because I was diagnosing random BSODs on my laptop. Running:
verifier.exe /reset
and then rebooting fixed this issue for me.
Launching VirtualBox as administrator got my VM running as normal.
Didn't need to try any other approach.
I had been running Fedora 9 for the last year --- I have a Windows box (actually a VM) that mounts a folder on the Fedora box using my own name/password. I do this so that I can run my version control program (Vault) on Windows. It has worked flawlessly for the last 6 months.
Yesterday, I upgraded Fedora from version 9 to version 11. Since doing so, I am no longer able to change file permissions from my Windows box. Nothing has changed, there's no firewall on the machine, SELinux is disabled (SELINUX=disabled in /etc/sysconfig/selinux), etc
I can still read the files. Any idea what has happened and how I might fix this?
Thanks,
David
P.S. The error I get is
An error occurred applying attributes to the file:
....my filename...
Access is denied.
P.P.S. I AM able to create a NEW file in the mounted folder. After doing so, I can change its properties to make it be read-only. BUT I then can NOT change its properties again to be writable. Hope this helps.
Turns out this would appear to be a bug in the latest version of Samba that you get when you install Fedora 11.
I manually built SAMBA 3.4.1 from source, installed it and my Windows machines work just fine with it.
(Just in case anyone else searches this site)