Remove hack used to disable Predictable Network Interface naming #2

geerlingguy · 2016-04-22T15:36:50Z

See related:

geerlingguy · 2016-07-25T01:39:43Z

Note: it seems VirtualBox 5.1.2 and Vagrant 1.8.5 with a freshly-built Packer box (not just this one, but all my boxes, with the exact same config that was working with VirtualBox 5.0.24) is resulting in the host-only network/private network interface not being brought up.

Looking at debug level output, it seems the hostonly adapter is brought up correctly:

...
Name:            vboxnet26
GUID:            786f6276-656e-4274-b600-0a002700001a
DHCP:            Disabled
IPAddress:       172.16.3.1
NetworkMask:     255.255.255.0
IPV6Address:     
IPV6NetworkMaskPrefixLength: 0
HardwareAddress: 0a:00:27:00:00:1a
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-vboxnet26
...
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG network: Adapter configuration: {:adapter=>2, :hostonly=>"vboxnet26", :mac_address=>nil, :nic_type=>nil, :type=>:hostonly}
 INFO network: Enabling adapters...
 INFO interface: output: Preparing network interfaces based on configuration...
 INFO interface: output: ==> ubuntu1604: Preparing network interfaces based on configuration...
==> ubuntu1604: Preparing network interfaces based on configuration...
 INFO interface: detail: Adapter 1: nat
 INFO interface: detail:     ubuntu1604: Adapter 1: nat
    ubuntu1604: Adapter 1: nat
 INFO interface: detail: Adapter 2: hostonly
 INFO interface: detail:     ubuntu1604: Adapter 2: hostonly
    ubuntu1604: Adapter 2: hostonly
 INFO subprocess: Starting process: ["/usr/local/bin/VBoxManage", "modifyvm", "a6adba53-7e78-47c2-8c81-8aa67e3e42ed", "--nic1", "nat", "--nic2", "hostonly", "--hostonlyadapter2", "vboxnet26", "--cableconnected2", "on"]
DEBUG subprocess: Command not in installer, not touching env vars.
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO warden: Calling IN action: #<VagrantPlugins::ProviderVirtualBox::Action::NetworkFixIPv6:0x00000102976320>
 INFO warden: Calling IN action: #<VagrantPlugins::ProviderVirtualBox::Action::ForwardPorts:0x00000100e0f898>
 INFO interface: output: Forwarding ports...
 INFO interface: output: ==> ubuntu1604: Forwarding ports...
==> ubuntu1604: Forwarding ports...

The output from the vagrant up command that now fails:

$ vagrant up ubuntu1604 --provider=virtualbox
Bringing machine 'ubuntu1604' up with 'virtualbox' provider...
==> ubuntu1604: Clearing any previously set forwarded ports...
==> ubuntu1604: Pruning invalid NFS exports. Administrator privileges will be required...
==> ubuntu1604: Clearing any previously set network interfaces...
==> ubuntu1604: Preparing network interfaces based on configuration...
    ubuntu1604: Adapter 1: nat
    ubuntu1604: Adapter 2: hostonly
==> ubuntu1604: Forwarding ports...
    ubuntu1604: 22 (guest) => 2222 (host) (adapter 1)
==> ubuntu1604: Running 'pre-boot' VM customizations...
==> ubuntu1604: Booting VM...
==> ubuntu1604: Waiting for machine to boot. This may take a few minutes...
    ubuntu1604: SSH address: 127.0.0.1:2222
    ubuntu1604: SSH username: vagrant
    ubuntu1604: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

geerlingguy · 2016-07-25T02:16:37Z

During boot, if I inspect the VirtualBox console using v.gui = true, then I see the following timeout after 5 minutes:

a start job is running for raise network interfaces

Pictorially:

So something's not getting configured inside the VM correctly.

Glancing at the VM settings inside VirtualBox's GUI, everything seems correct with the 2nd network interface/adapter:

Inside the VM:

ip a returns lo, eth0, and eth1, but none have an IP4 address.
/etc/network/interfaces has an entry for auto eth1 with iface eth1 inet manual

I'm going to bring up a working 16.04 VM with my latest (old) published release and see if I can spot any differences.

geerlingguy · 2016-07-25T02:23:53Z

I'm going to try to revert the hack from #1 and see if just doing that works with Vagrant 1.8.5... maybe the manual network changes were causing an issue (but it seems they shouldn't be an issue, since the same config worked and still works in the previous build for the same box.

geerlingguy · 2016-07-25T03:26:22Z

Removing the hack seems to work-ish... but it still doesn't allow SSH to connect.

Tried running sudo ifup enp0s3 but that just looped in the 'waiting for DHCP' segment for a while.

I'm wondering if hashicorp/vagrant#6683 is still not fully resolved :-/

But the weirdest thing is, why is the older box that was generated with VirtualBox 5.0.24 working fine in 5.1.2, but a box with the exact same config generated in 5.1.2 isn't?

I'm also going to switch back to Ubuntu 16.04.0 (I switched to .1) and see if that helps. But it seems like it won't—Vagrant isn't happy connecting to any of my new boxes, CentOS 6/7, Ubuntu 12/14/16, if I build them in 5.1.2.

Jalle19 · 2016-08-09T11:39:09Z

Just stumbled over the same issue myself (networking broken after updating to Vagrant 1.8.5 and VirtualBox 5.1). I'll downgrade and see what happens.

geerlingguy · 2016-08-10T03:17:34Z

@Jalle19 - :(

Yeah, after spending about 4 hours on this a couple weeks ago, I haven't had the time to devote to digging deep and finding the exact issue.

Jalle19 · 2016-08-10T08:15:18Z

Me neither, I downgraded back to Vagrant 1.8.4 and VirtualBox 5.0.22 for now (newer VirtualBox 5.0 releases have the networking bug which can cause provisioning to stall unless you start pinging something from the virtual machine).

geerlingguy · 2016-08-10T12:11:23Z

Possibly related:

A more reliable way to detect Ubuntu hashicorp/vagrant#7524
Authentication failure after inserting new key with Vagrant 1.8.5. [PATCH] hashicorp/vagrant#7610 (but that's likely a different issue)
1.8.5 failling to bring private interface up using vbox hashicorp/vagrant#7613
1.8.5: Unable to use private network after switching from ifconfig to ip hashicorp/vagrant#7668

chrisroberts · 2016-08-12T15:41:09Z

Hi @geerlingguy! I'm curious if the problem you're hitting may be resolved by hashicorp/vagrant#7705. If you have a chance to give it a try, I'd be interested to know if it fixes things up. Thanks!

geerlingguy · 2016-09-05T02:03:14Z

@chrisroberts - Unfortunately with some crazy life events happening right now, I'm going to have to wait to test things out—if there's a new Vagrant release (1.8.6) soon, that could expedite things, but until that happens I am putting updating any of my base boxes on hold, because even if it does solve the issue (it seems like it will), I'd rather not require those using my public boxes have to apply patches to Vagrant to keep working.

For now, the existing versions of my boxes are working, and I've already burned a bit too much time on this issue :P

geerlingguy · 2016-09-05T02:03:43Z

But THANK YOU for posting that, and for referencing the upstream issue. I think that could be the problem, just looking over the details, what changed, etc.

MiLk · 2016-09-06T08:26:42Z

I had a similar issue where the "Cable connected" checkbox was not checked for the NAT interface, and by generating the box with VirtualBox 5.0.26, it's now working.

geerlingguy · 2016-10-28T02:43:37Z

The hack was removed in 9455d86, and I'm going to leave it out; it seems VirtualBox is working fine now, though I'm hitting a snag with VMware Fusion 8.5 builds. So I'll open a separate issue for that.

MiLk · 2016-10-28T02:54:51Z

I confirm that it has been fixed in VirtualBox 5.1.6.

geerlingguy · 2016-10-30T20:52:17Z

@MiLk - Thanks! I just tested in 5.1.8 and built a new base box, and it seems to be working well now.

geerlingguy closed this as completed Oct 28, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove hack used to disable Predictable Network Interface naming #2

Remove hack used to disable Predictable Network Interface naming #2

geerlingguy commented Apr 22, 2016

geerlingguy commented Jul 25, 2016

geerlingguy commented Jul 25, 2016

geerlingguy commented Jul 25, 2016

geerlingguy commented Jul 25, 2016

Jalle19 commented Aug 9, 2016

geerlingguy commented Aug 10, 2016

Jalle19 commented Aug 10, 2016

geerlingguy commented Aug 10, 2016

chrisroberts commented Aug 12, 2016

geerlingguy commented Sep 5, 2016

geerlingguy commented Sep 5, 2016

MiLk commented Sep 6, 2016

geerlingguy commented Oct 28, 2016

MiLk commented Oct 28, 2016

geerlingguy commented Oct 30, 2016

Remove hack used to disable Predictable Network Interface naming #2

Remove hack used to disable Predictable Network Interface naming #2

Comments

geerlingguy commented Apr 22, 2016

geerlingguy commented Jul 25, 2016

geerlingguy commented Jul 25, 2016

geerlingguy commented Jul 25, 2016

geerlingguy commented Jul 25, 2016

Jalle19 commented Aug 9, 2016

geerlingguy commented Aug 10, 2016

Jalle19 commented Aug 10, 2016

geerlingguy commented Aug 10, 2016

chrisroberts commented Aug 12, 2016

geerlingguy commented Sep 5, 2016

geerlingguy commented Sep 5, 2016

MiLk commented Sep 6, 2016

geerlingguy commented Oct 28, 2016

MiLk commented Oct 28, 2016

geerlingguy commented Oct 30, 2016