Vagrant Installation Fails on Ubuntu 16.04 VM about deploy-ibm-cloud-private HOT 12 OPEN

I got the same error if using the cache server. Turned that off and the installation succeeded.

from deploy-ibm-cloud-private.

I have the same issue. For some reason it is unable to pull docker and install it on the Ubuntu VM.

FROM THE cfc-manager1 log
E: Failed to fetch https://download.docker.com/linux/ubuntu/dists/xenial/pool/stable/amd64/docker-ce_17.09.0~ce-0~ubuntu_amd64.deb GnuTLS recv error (-54): Error in the pull function.

from deploy-ibm-cloud-private.

The error message comes after checking to see if "eth0" and "docker0" are present when running "lxc list".

from deploy-ibm-cloud-private.

Did this work for anyone, Same problem here.

from deploy-ibm-cloud-private.

I rebooted and ran the "vagrant up" command again. It was successful and I did not change anything on my end other than a reboot.

from deploy-ibm-cloud-private.

@andrewyuau Can you explain how you turned off the cache server?

@bluegoose13 I've tried another reboot after cleaning the system up... vagrant destroy, removed the vboxnet0 NIC, removed the VirtualBox VMs folder... still fails the same way.

from deploy-ibm-cloud-private.

@ivandov The cache server is turned off by default https://github.com/IBM/deploy-ibm-cloud-private/blob/master/Vagrantfile#L45

Help me understand how you are running this. You mentioned in the original issue statement that you were successful at running this but then you "move this to it's own isolated x86 VM". What do you mean by that? Are you running the Vagrant inside of another VM? On your laptop or in a cloud somewhere?

The networking setup of the VM is dependent on two virtualbox network adaptors. The first is the "management" adaptor that vagrant sets up by default. This is a NATed adaptor that vagrant uses for "management" tasks such as starting/stoping/sshing to the machine. The second is the "host-only" adaptor which is the one defined in the Vagrantfile (https://github.com/IBM/deploy-ibm-cloud-private/blob/master/Vagrantfile#L972) The "host-only" adaptor has limited external connectivity (can only communicate with the host computer) and relies on the first "management" adaptor to NAT all traffic to/from external addresses (external to the host machine). This NATted traffic is achieved using IPtable rules on the vm that Vagrant stands up by executing a script to tell iptables on the Ubuntu VM to automatically NAT traffic via the first "management" adaptor (https://github.com/IBM/deploy-ibm-cloud-private/blob/master/Vagrantfile#L306-L308) All this to say that if you are running the Vagrant inside of another VM which is hosted on your laptop the networking will likely "break-down" as it will have to perform double-nating to traverse two layers of networking adaptors to route traffic in/out of the vagrant vm. This is not a scenario that I have even tested as the purpose of Vagrant is to provide an isolated VM based environment so running it inside another "isolated vm environment" is redundant.

from deploy-ibm-cloud-private.

That is correct, I have an Ubuntu 16.04 (server edition) VM under VMWare where I am following the Vagrant Installation docs. The VM is hosted on a large VMWare installation within our intranet, so essentially a "cloud somewhere".

I had anticipated the installation failing due to possible networking problems via this "double VM" style of installation. But, I was hoping that the VMWare hypervisor wasn't the culprit behind this. I will try the standalone node installation on this Ubuntu VM and avoid the Vagrant installation path as this is already an isolated environment.

from deploy-ibm-cloud-private.

I'm coping with this too. One problem I've found is in the Vagrantfile - the 'here document' that creates docker/daemon.json creates a file with syntax errors. This actually happens in two places.

On line 255, if #{docker_mirror} is null, then the daemon.json file is correct. If #{docker_mirror} has a value, however then you'll have errors restarting docker.service after the file is created.

This is also true at line 443.

These errors depend on the handling of 'docker_mirror'. However they can occur indirectly, as in my case where on line 45 use_cache is defined (I WANTED that cache server!). Line 156 is where the script would then define docker_mirror.

I hope this helps someone. The fix would be very easy in ksh/pdksh, where I'm expert. I would place this variable expression at the end of the line above each docker_mirror reference: "${docker_mirror:+,}", which would place the ',' only if docker_mirror has a value.

I'm a newbie at vagrant but perhaps someone can translate the above var expr so it would work.

from deploy-ibm-cloud-private.

I have the same experience installing it on Mac as ivandov documented at the beginning of the thread.
Reboot several times. I have checked network connectivity - which seems to be okay from the host and from the master node.
docker ps returns a reasonable list on the master node.
when running curl -https://192.168.27.100:8443 I get an 403 pointing to some 1.11.x network segment which I con't understand. But I can even ping this segment.
This is the console when running vagrant up:
icp: PLAY RECAP *********************************************************************
icp: 192.168.27.100 : ok=194 changed=59 unreachable=0 failed=0
icp: 192.168.27.101 : ok=112 changed=39 unreachable=0 failed=0
icp: 192.168.27.102 : ok=112 changed=39 unreachable=0 failed=0
icp: 192.168.27.111 : ok=112 changed=39 unreachable=0 failed=0
icp: localhost : ok=201 changed=100 unreachable=0 failed=0
icp:
icp:
icp: POST DEPLOY MESSAGE ************************************************************
icp:
icp: UI URL is https://192.168.27.100:8443 , default username/password is admin/admin
icp:
icp: Playbook run took 0 days, 0 hours, 16 minutes, 12 seconds
==> icp: Running provisioner: shell...
icp: Running: script: install_kubectl
==> icp: Running provisioner: shell...
icp: Running: script: create_persistant_volumes
==> icp: Running provisioner: shell...
icp: Running: script: install_helm
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.

When restarting: vagrant up

==> icp: Machine already provisioned. Run vagrant provision or use the --provision
==> icp: flag to force provisioning. Provisioners marked to run always will still run.
==> icp: Running provisioner: shell...
icp: Running: script: ensure_services_up
icp: Waiting for all IBM Cloud Private Services to start...
icp: All IBM Cloud Private Services have been successfully started...
icp: NAME READY STATUS RESTARTS AGE
icp: auth-apikeys-wqp3q 1/1 Running 0 8m
icp: auth-idp-pbh82 3/3 Running 0 9m
icp: auth-pap-df5l4 1/1 Running 0 8m
icp: auth-pdp-gpfpk 1/1 Running 0 8m
icp: calico-node-amd64-4zhx8 2/2 Running 0 14m
icp: calico-node-amd64-vt2qn 2/2 Running 0 14m
icp: calico-node-amd64-xpnhq 2/2 Running 0 14m
icp: calico-node-amd64-z2qk6 2/2 Running 0 14m
icp: calico-policy-controller-1048521425-wbf79 1/1 Running 0 14m
icp: catalog-catalog-apiserver-1cqwv 1/1 Running 0 8m
icp: catalog-catalog-controller-manager-3100032879-mq1vb 1/1 Running 0 7m
icp: catalog-ui-535rf 1/1 Running 0 8m
icp: default-http-backend-198681862-nfd6n 1/1 Running 0 8m
icp: elasticsearch-client-3479638665-bvjzm 2/2 Running 0 8m
icp: elasticsearch-data-0 1/1 Running 0 8m
icp: elasticsearch-master-1570256108-lc2rs 1/1 Running 0 8m
icp: filebeat-ds-amd64-755tp 1/1 Running 0 8m
icp: filebeat-ds-amd64-j1rrq 1/1 Running 0 8m
icp: filebeat-ds-amd64-sddht 1/1 Running 0 8m
icp: filebeat-ds-amd64-w4gt5 1/1 Running 0 8m
icp: heapster-1250025240-rrt12 2/2 Running 0 8m
icp: helm-api-2338777260-txvpf 1/1 Running 0 7m
icp: helmrepo-1949990944-qxn7v 1/1 Running 0 7m
icp: icp-ds-0 1/1 Running 0 12m
icp: icp-router-sjsr1 1/1 Running 0 7m
icp: image-manager-0 2/2 Running 0 8m
icp: k8s-etcd-192.168.27.100 1/1 Running 0 14m
icp: k8s-mariadb-192.168.27.100 1/1 Running 0 14m
icp: k8s-master-192.168.27.100 3/3 Running 0 14m
icp: k8s-proxy-192.168.27.100 1/1 Running 0 15m
icp: k8s-proxy-192.168.27.101 1/1 Running 0 14m
icp: k8s-proxy-192.168.27.102 1/1 Running 0 14m
icp: k8s-proxy-192.168.27.111 1/1 Running 0 14m
icp: kube-dns-1038623989-p8f0w 3/3 Running 0 12m
icp: logstash-4245234969-0nmbl 1/1 Running 0 8m
icp: nginx-ingress-lb-amd64-p4cl4 1/1 Running 0 8m
icp: platform-api-4tct4 1/1 Running 0 8m
icp: platform-ui-fgsjk 1/1 Running 0 8m
icp: rescheduler-42dch 1/1 Running 0 8m
icp: tiller-deploy-2307655136-b4br9 1/1 Running 0 8m
icp: unified-router-p4ck3 1/1 Running 0 8m

Any thoughts?

from deploy-ibm-cloud-private.

I run into the same problem except my local machine is a mac.

from deploy-ibm-cloud-private.

I've got this issue as well. How did everyone solve it?

    icp: Starting worker1
    icp: Creating worker2
    icp: Starting worker2
==> icp: Running provisioner: shell...
    icp: Running: script: wait_for_worker_nodes_to_boot
    icp: Preparing nodes for IBM Cloud Private community edition cluster installation.
    icp: This process will take approximately 10-20 minutes depending on network speeds.
    icp: Take a break and go grab a cup of coffee, we'll keep working on this while you're away ;-)
    icp: .
    icp: .
    icp: .
    icp: Failed to install docker on lxc nodes...
    icp: You may need to change the 'base_segment' value in the 'Vagrantfile' to another subnet like '192.168.56'.
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.

I'm installing on Ubuntu 18.04 (Not a VM).
Virtualbox 5.2.20 r125813
Vagrant 2.2.3

from deploy-ibm-cloud-private.