Verify that installation procedure works

[candu]

Description
Our installation process is described in the repo README, but it's never been tested end-to-end by someone who isn't @candu . You could be the one to change that 😄

Acceptance Criteria

• run through the installation process with help from @candu where roadblocks are encountered.
• document those roadblocks by updating the README.

[candu]

@chelsrosic - following up on our discussion, this would be a good task to tackle after getting the vector tiles bugs fixed. Having this set up on your machine will:

• make it easier for you to help out on more frontend-facing tasks later;
• allow us to get a proper feature branch / pull request / code review process going - we can submit the vector tiles script through this process;
• help me test this installation procedure out before we onboard another dev.

[candu]

@chelsrosic attempted setup here. vagrant up kept issuing "guest machine" errors; vagrant reload --provision got past those, but would hang forever during provisioning.

Not sure what's happening here. Some possible things to try, in the order I'd probably try them:

• make sure you have the most recent Vagrantfile (recent changes increase CPU / RAM limits for the VM);
• try some of the fixes mentioned here and here:
  • update to PowerShell 5.1;
  • add v.customize ["modifyvm", :id, "--nictype1", "82540EM"] in config.vm.provider block;
• comment out the config.vm.provision line in scripts/dev/Vagrantfile, and see if that helps;
• @candu could try provisioning on the Win 7 workstation at his desk, to see if it's an OS version-specific issue.

[chelsrosic]

So downloading powershell 5.1 kind of fixed the "guest machine" error after running vagrant up. As the command was running, it took way too much time to boot the virtual machine so I used Ctrl C to end the process entirely. After I ended the process I tried vagrant up again and it gave me the "guest machine" error, which it had not given the last time I ran the command. I tried fixing the VagrantFile which didn't work. What did work however, was deleting the virtual machine created by vagrant on Virtual Box before re-running vagrant up. So the guest machine error was now fixed (yet again). Now I am getting a new error:

There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "478a0e1e-9709-43de-99af-9a633be7dc3b", "--type", "headless
"]

Stderr: VBoxManage.exe: error: The native API dll was not found (C:\Windows\syst
em32\WinHvPlatform.dll) (VERR_NEM_NOT_AVAILABLE).
VBoxManage.exe: error: VT-x is disabled in the BIOS for all CPU modes (VERR_VMX_
MSR_ALL_VMX_DISABLED)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component ConsoleWrap,
 interface IConsole

After some research I found: hashicorp/vagrant#9318

Things I tried from this page:

• There was an error while executing VBoxManage, a CLI used by Vagrant for controlling VirtualBox. hashicorp/vagrant#9318 (comment)
• There was an error while executing VBoxManage, a CLI used by Vagrant for controlling VirtualBox. hashicorp/vagrant#9318 (comment)
• uninstalling and re-installing most recent version of virtual box
• Made sure Hyper V was disables in Turn windows feature on or off Control Panel options
• Ran the command in cmd as an administrator
• ran vagrant reload

[candu]

Thanks @chelsrosic for digging deeper on this! As per follow-up from @radumas, this is being escalated to IT to enable VT-x at the BIOS level; it looks like there's not a whole lot else that can be done on this until that happens.

[radumas]

Uma dropped by, played with the BIOS, and is going to come back in a bit.

[chelsrosic]

Uma dropped by again this morning,not sure what he did. I just checked to see if vagrant up works and I am still getting the BIOS error.

[candu]

😢 @radumas - sounds like we need to follow up with Uma again.

[chelsrosic]

Uma came back and fixed my error with the Virtual Box !

However, now I have another error. I see the word sudo so it could be a sudo error (since we do not have sudo privileges on these computers):

PS C:\Users\crosic\Documents\GitHub\bdit_flashcrow\scripts\dev> vagrant up --provision
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Configuring proxy environment variables...
==> default: Skipping configuration of npm_proxy
==> default: Configuring proxy for Yum...
==> default: Running provisioner: shell...
    default: Running: inline script
    default: /tmp/vagrant-shell: /vagrant/provision-admin.sh: /bin/bash^M: bad interpreter: No such file or directory
    default: sudo: unable to execute /vagrant/provision-user.sh: No such file or directory
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
PS C:\Users\crosic\Documents\GitHub\bdit_flashcrow\scripts\dev>

either that or the file does not exist and maybe I should re-install vagrant or something ?

[chelsrosic]

So Evan fixed the issue in the comment above. vagrant up ran for a while and then failed. Here is the next error that I encountered:

    default: You can now open Cypress by running: node_modules/.bin/cypress open
    default: https://on.cypress.io/installing-cypress
    default:
    default: npm
    default:  WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.7 (node_modules/fsevents):
    default: npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.7: wanted {"os":"darwin
","arch":"any"} (current: {"os":"linux","arch":"x64"})
    default: added 1753 packages from 853 contributors and audited 101914 packages in 335.1s
    default: found 0 vulnerabilities
    default: creating log directories...
    default: setting up PostgreSQL...
    default: initializing PostgreSQL database...
    default: /vagrant/provision-user.sh: line 135: pg_ctl: command not found
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

It seems to be another issue with the SSH.

[candu]

This line:

default: /vagrant/provision-user.sh: line 135: pg_ctl: command not found

...suggests PostgreSQL installation failed. While working on something else, I found a possible root cause of that: the PostgreSQL 9.6 repository that we were using has mysteriously disappeared from the PostgreSQL website.

I also hit the same HTTP 407 proxy authentication issues that @chelsrosic ran into the other day.

I've got some updates that should fix both issues - just tested them out now with a fresh vagrant destroy / vagrant up cycle, and they ran successfully. (This is obviously no guarantee that they'll work for others!) I'll get those into a pull request here by early Monday.

[candu]

Closed by #37 .