Course Environment Requirements?

I’ve had a long serious of problems trying to get Vagrant up and loading the starting environment. I can provide details of the issues but I believe they are likely specific to my environment, so it’s okay for me to work through them but no need to share that pain with all of you. I have documented them though if still interested.

But as the whole point of using vagrant is to ensure a common and known set of tools installed and available, to “simplify” the setup for the course, and I have now lost two evenings working through the issues, does this Vagrant setup not have a list of specific prerequisite tools that could simply be provided for those of us who are experiencing issues with the vagrant environment?

I already have multiple development machines, fully loaded with the usual webdev tools. I probably have everything necessary on one of those, and even if not, installing a specific version of Node or Yarn or anything would be easier than the pain I’m going through now.

What are the specific requirements for the course(s) that the vagrant setup is trying to resolve?

All of the problems I’ve run into so far have either been directly related to the VM environment, or the shared folder between environments. I’ve worked around them all except neither yarn nor npm can complete an install and setup of node_modules. I could just be running npm or yarn on one of my other machines, or the vagrant host.

I’m not looking for support for setting up the vagrant environment, although it’s close. I’m looking for info on the alternative to using it. What are the actual environmental requirements for the course(s)?


Hi Paul,

If you prefer, I can provide a Docker image of the same software.

Or, if you prefer to skip the virtualized environment, you’ll need to install the following on your local machine:

  • MongoDB
  • Node/NPM
  • Vue CLI
  • Heroku CLI
  • Chrome driver

You can also look at the provision file in printbay-vagrant and see exactly what it’s installing and install that same software on your own system.

Keep in mind if you persist with getting Vagrant running, it will be smooth sailing after that. If you skip it, you may run into config issues later in the course.

1 Like

Hi Paul,

Thanks to great work from @chiliconlatte we have a Docker script which can be used as an alternative to Vagrant. It’s much, much easier to install.

I’m preparing instructions for using it right now and will post here when it’s ready to go.

Thanks, that is what I need to know (and in fact already have those on every one of my development machines). I think I’m just going to continue with the course until something doesn’t match up, now that I know what to expect.

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.

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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”.

  5. 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

    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.

  6. 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 /home/vagrant/app
Stdout from the command:
Stderr from the command:
mount.nfs: Connection timed out

(blank lines removed)

  1. So I googled this error and found this link which suggests running vagrant up from an Administrator prompt:
    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:
    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).

Oh crap. :smile: I checked the Vagrantfile to look for components etc and didn’t see anything really other than Ubuntu, networking options and starting Mongo… I totally forgot about the other file there. Yeah, that is very clear on what is needed, what Vagrant is providing. Thanks again.

Hi Paul,

Sorry for the difficulty with this, I appreciate the detailed issue as well.

Today I’ve been testing a Docker script as a replacement. I’ll be providing detailed instructions in the next day or two in case you or others would like to use it.