If you saw the trouble I had with vagrant, I think you’d understand why running into some minor difference during the course is the lesser of evils, and bound to be less trouble.
Here’s my log of efforts so far with Vagrant:
-
Course requires vagrant VMs. My primary machine is Windows, but I have several Linux installations as well. So I started with Windows. Vagrant chose VirtualBox which worked to a point then failed to start with an error about an invalid certificate on NTDLL.DLL.
a) (Not recommended for others, but…) I had previously installed the Beta Channel of the Windows Insider version of Windows 10, then reverted back to the Release Preview version. I suspect that left me with a Windows that did not apply new updates as beta versions expired. Trying to return to the Beta channel did not result in any updates, so on a hunch I upgraded my Windows 10 installation to the latest Dev version of Windows insider. This did trigger a system upgrade, and after that completed, it no longer complained about NTDLL.DLL.
b) I still had compatibility conflicts with my VM setup (Hyper-V support is mutually-exclusive with VirtualBox) so I needed to disable Hyper-V (which breaks WSL2 which really sucks) but allows use of VirtualBox. So disabling the Hyper-V and the VM options allowed VirtualBox to start the Vagrant box.
I could probably dig and find a more compatible host environment for Vagrant but “out of the box” (pardon the pun), this is what I got.
-
Vagrantfile syntax/options errors:
config.vm.synced_folder "../data", "/home/vagrant/app", type: "nfs", mount_options: ['actimeo=1']
In this case, it was a Windows 10 machine, NFS is not supported out of the box (but see point 7).
a) I just removed the “type” option and let it default. This managed to get much further, but still an error.
-
Vagrantfile syntax/options errors with:
config.vm.synced_folder "../data", "/home/vagrant/app", mount_options: ['actimeo=1']
In this case, it got a lot further but then did not recognized the ‘actimeo’ option.
a) Again I just removed the incompatible option.
-
I think the virtual machine started up after this. I began following the instructions, cloning the repo on the Windows side, running “npm i”. This failed with:
Error: EACCES: permission denied, access ‘/opt/node-v10.15.3-linux-x64/lib/node_modules’
a) I have found yarn more reliable in these cases and switched. I ran “npm i -g yarn” and then “yarn” instead of “npm i”.
-
It got a lot farther but then:
error An unexpected error occurred: "EPROTO: protocol error, symlink '../../../parser/bin/babel-parser.js' -> '/home/vagrant/app/node_modules/@babel/core/node_modules/.bin/parser'".
There were lots of warnings but that is not unusual for node_modules. However, this was an error.
a) It looked perhaps related to the file system and I’m thinking it may be dependent on Linux symlinks. So this seemed like another incompatibility of vagrant under Windows. But I’m surprised I got this far with Windows. So I ran “yarn” on the Windows side in the “data” folder in an effort to populate the node_modules folder with any platform-independent modules. Yarn completed there.
b) So I went back to the Linux side and reran “yarn” there too and it continued (looks like from where it left off) after the babel-jest warnings, with a progress bar of 33760 packages to fill, but no error during the progress bar. However as soon as it filled, I received the same EPROTO error as above.
c) So I tried a manual symlink of those paths:
vagrant@mevn:~/app$ ln -s node_modules/@babel/parser/bin/babel-parser.js node_modules/@babel/core/node_modules/.bin/parser
and received the same error (so at least that confirms the issue is that it cannot create a symlink, probably because I removed the type: “nfs” option.
ln: failed to create symbolic link 'node_modules/@babel/core/node_modules/.bin/parser': Protocol error
d) So I went back to the Windows side and created a symlink there, using the mklink command (symlinks are definitely possible on Windows, in three different techniques, not counting shortcuts which aren’t symlinks of course). Note that “mklink” reverses the order of “ln -s” commands:
vuejsdevelopers\printbay-vagrant\data> mklink "node_modules/@babel/core/node_modules/.bin/parser" "node_modules/@babel/parser/bin/babel-parser.js"
symbolic link created for node_modules/@babel/core/node_modules/.bin/parser <<===>> node_modules/@babel/parser/bin/babel-parser.js
e) Back to the Linux side again:
vagrant@mevn:~/app$ ls -la node_modules/@babel/core/node_modules/.bin total 4
drwxrwxrwx 1 vagrant vagrant 0 Dec 1 06:20 .
drwxrwxrwx 1 vagrant vagrant 4096 Dec 1 06:18 ..
lrwxrwxrwx 1 vagrant vagrant 0 Dec 1 06:20 parser -> node_modules/@babel/parser/bin/babel-parser.js
vagrant@mevn:~/app$
Okay, looking good. But same error again, and the symlink that I created was removed by yarn, perhaps clearning a “foreign” item before starting.
f) So I went back to Windows and recreated the symlink.
g) Back again to Linux, this time running npm i in case each tool was letting me get a little farther with node_modules.
Much to my surprise, this worked farther, but then I got another ETXTBSY message from npm.
h) So I ran yarn again. Back at the EPROTO error. So I’ve looped on my attempts.
-
As it looks like it is problems in the expectations of shared folder support, which didn’t include NFS after my changes, I decide to abandon this non-NFS shared folder directive after finding out there was a Vagrant NFS plugin for Windows 10. Simply run:
vagrant plugin install vagrant-winnfsd
and then:
vagrant reload
This left me very optimistic, yet when I tried it, this failed to start, due to a timeout:
==> default: Configuring and enabling network interfaces...
==> default: Installing NFS client...
==> default: Exporting NFS shared folders...
==> default: Preparing to edit nfs mounting file.
[NFS] Status: halted
[NFS] Start: started
==> default: Mounting NFS shared folders...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
mount -o vers=3,udp,rw,async,fsc,nolock,vers=3,udp,rsize=32768,wsize=32768,hard,noatime,actimeo=2 10.10.30.1:/C/dev/vuejsdevelopers/printbay-vagrant/data /home/vagrant/app
Stdout from the command:
Stderr from the command:
mount.nfs: Connection timed out
(blank lines removed)
-
So I googled this error and found this link which suggests running vagrant up from an Administrator prompt:
https://github.com/winnfsd/vagrant-winnfsd/issues/79
a) It suggests running the vagrant up command from an Administrator command prompt. So I gave that a try. Same timeout.
Then this page suggested adding some uart options to avoid an Ubuntu problem, which didn’t make a lot of sense to me but it worked for other folks so:
https://stackoverflow.com/questions/65010457/vagrant-freezes-when-using-vagrant-up-on-virtualbox-ubuntu
No joy. It always hangs for a couple of minutes after “Mounting NFS shared folders…” then reports the timeout error.
At least I was able to get to the point where Vagrant is able to start a VM. I thought my Windows virtual machine hosting problems were fatal, but once I decided to try to force an upgrade with the Dev build of Windows Insider releases, and disabled Hyper-V and a few other VM-related options, it resolved the issues there. It’s seems to leave problems related to the shared folder though. It may require the VirtualBox extensions, since they provide shared folder support in VBox, and Vagrant doesn’t have an update with VBox extensions that supports the current version (6.1) of VBox. In fact they seem annoyed that anyone would want this. They do seem to support an older version of VBox (5.2? if my memory serves) so if I continue with these attempts, I may try downgrading VirtualBox to something Vagrant has built-in support for, and hopefully gain working shared folder support.
But I’m just trying to take a course in Vue, not invest in a career learning the details of VirtualBox under Vagrant. Thus my question (which has been answered, thank you).
I checked the