ubuntu 15.10 & 16.04 guests wont work with private networks #7155

Closed
kiorky opened this Issue Mar 18, 2016 · 48 comments

Comments

Projects
None yet
@kiorky

kiorky commented Mar 18, 2016

Vagrant version

Vagrant 1.8.1

Host operating system

ubuntu 15.04 (any ubuntu)

Guest operating system

ubuntu 16.04 (15.10+ exhibit the problem)

Vagrantfile

Vagrant.configure(2) do |config|
  config.vm.box = "xenial64"
  config.vm.box_url = "http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-vagrant.box"
  config.vm.network "private_network", ip: "192.168.33.10"
end

Debug output

Vagrant fails first with

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

hostname -f

Stdout from the command:
Stderr from the command:
sudo: unable to resolve host ubuntu-xenial
mesg: ttyname failed: Inappropriate ioctl for device
hostname: No address associated with hostname

If we create /etc/network/interfaces.d/eth1.cfg like this

:!cat /etc/network/interfaces.d/eth1.cfg
# The primary network interface
auto eth1
iface eth1 inet manual

And powerdown/vagrant up the vm, the provisionning will work

@sethvargo

This comment has been minimized.

Show comment
Hide comment
@sethvargo

sethvargo Mar 18, 2016

Contributor

Hi @kiorky

Thank you for opening an issue. I am unable to reproduce this issue with the following vanilla Vagrantfile. The Vagranfile you supplied is doing a lot of things including monkey-patching the ruby, defining helpers, and performing conditional execution that makes it very difficult to reason about the actual Vagrantfile that is being used and the parameters. Are you able to reproduce this with a vanilla Vagrantfile?

Vagrant.configure(2) do |config|
  config.vm.box = "bento/ubuntu-15.04"
  config.vm.network "private_network", ip: "33.33.33.10"
end

There are so many variables in your Vagrantfile that it's not possible to narrow down where the problem might be:

  1. You are binding to specific adapters
  2. You are pulling in data from the environment which could be changing
  3. You are using the non-stable versions of the ubuntu OS
  4. You are making system calls to determine resources
  5. You are monkey-patching Ruby's core library, which can have unintended side-effects on the way Vagrant evaluates code
  6. You are reading data from an external yaml file
  7. You are messing with Vagrant's internals

Unfortunately there are just too many variables. Could you please reduce to a vanilla Vagrantfile and see if the issue reproduces? If it does, I am happy to try and fix it. If it doesn't, it means there is an issue in one of the items in the list above. Thanks! 😄

Contributor

sethvargo commented Mar 18, 2016

Hi @kiorky

Thank you for opening an issue. I am unable to reproduce this issue with the following vanilla Vagrantfile. The Vagranfile you supplied is doing a lot of things including monkey-patching the ruby, defining helpers, and performing conditional execution that makes it very difficult to reason about the actual Vagrantfile that is being used and the parameters. Are you able to reproduce this with a vanilla Vagrantfile?

Vagrant.configure(2) do |config|
  config.vm.box = "bento/ubuntu-15.04"
  config.vm.network "private_network", ip: "33.33.33.10"
end

There are so many variables in your Vagrantfile that it's not possible to narrow down where the problem might be:

  1. You are binding to specific adapters
  2. You are pulling in data from the environment which could be changing
  3. You are using the non-stable versions of the ubuntu OS
  4. You are making system calls to determine resources
  5. You are monkey-patching Ruby's core library, which can have unintended side-effects on the way Vagrant evaluates code
  6. You are reading data from an external yaml file
  7. You are messing with Vagrant's internals

Unfortunately there are just too many variables. Could you please reduce to a vanilla Vagrantfile and see if the issue reproduces? If it does, I am happy to try and fix it. If it doesn't, it means there is an issue in one of the items in the list above. Thanks! 😄

@valkum

This comment has been minimized.

Show comment
Hide comment
@valkum

valkum Mar 18, 2016

@sethvargo I think u misread the issue. Try a 16.04 box as guest.
Try this Vagrantfile:


Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/xenial-cloud"
  config.vm.box_url = "http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-vagrant.box"
  config.vm.network "private_network", ip: "192.168.33.10"
end

The problem seems to be a upgrade of ifupdown package.
In ifupdown (0.8.7) the now return an error instead to the previous behaviour.

From the changelog (http://changelogs.ubuntu.com/changelogs/pool/main/i/ifupdown/ifupdown_0.8.10ubuntu1/changelog)

"Return an error when trying to ifup/ifdown/ifquery an unknown interface
(unless it is ignored due to --allow or --exclude)."

As debian/cap/configure_networks.rb:L44 always tries to ifdown an interface, even if it is not defined for the system, because first start and the fact that all interfaces except eth0 are removed from /etc/network/interfaces by debian/cap/configure_networks.rb:L16-17 this now throws an error as the command returns non-zero.

valkum commented Mar 18, 2016

@sethvargo I think u misread the issue. Try a 16.04 box as guest.
Try this Vagrantfile:


Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/xenial-cloud"
  config.vm.box_url = "http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-vagrant.box"
  config.vm.network "private_network", ip: "192.168.33.10"
end

The problem seems to be a upgrade of ifupdown package.
In ifupdown (0.8.7) the now return an error instead to the previous behaviour.

From the changelog (http://changelogs.ubuntu.com/changelogs/pool/main/i/ifupdown/ifupdown_0.8.10ubuntu1/changelog)

"Return an error when trying to ifup/ifdown/ifquery an unknown interface
(unless it is ignored due to --allow or --exclude)."

As debian/cap/configure_networks.rb:L44 always tries to ifdown an interface, even if it is not defined for the system, because first start and the fact that all interfaces except eth0 are removed from /etc/network/interfaces by debian/cap/configure_networks.rb:L16-17 this now throws an error as the command returns non-zero.

@kiorky

This comment has been minimized.

Show comment
Hide comment
@kiorky

kiorky Mar 19, 2016

i said 15.10+ and you edited what i gave to use 15.04... come on.
Well...

kiorky commented Mar 19, 2016

i said 15.10+ and you edited what i gave to use 15.04... come on.
Well...

@kiorky

This comment has been minimized.

Show comment
Hide comment
@kiorky

kiorky Mar 19, 2016

BTW; ubuntu16.04 is the next lts, which is coming soon ;) and cyring on users to adapt a bit their vagrantfile is a bit chilly where there is a bug on the first place.
Making such a report takes time, replying also. being so rude on the first comment, after a big misread of the bug can just make your users runaway ...

kiorky commented Mar 19, 2016

BTW; ubuntu16.04 is the next lts, which is coming soon ;) and cyring on users to adapt a bit their vagrantfile is a bit chilly where there is a bug on the first place.
Making such a report takes time, replying also. being so rude on the first comment, after a big misread of the bug can just make your users runaway ...

@sethvargo

This comment has been minimized.

Show comment
Hide comment
@sethvargo

sethvargo Mar 19, 2016

Contributor

Hi @kiorky

Thank you for your reply. My intent was not to be rude, so I apologize if it came off that way. Please understand that your Vagrantfile is very complex with many variables, so I was trying to help you narrow down the cause of the issue. @valkum was able to provide a much smaller reproduction case, which we can convert into a test case and fix the bug.

Contributor

sethvargo commented Mar 19, 2016

Hi @kiorky

Thank you for your reply. My intent was not to be rude, so I apologize if it came off that way. Please understand that your Vagrantfile is very complex with many variables, so I was trying to help you narrow down the cause of the issue. @valkum was able to provide a much smaller reproduction case, which we can convert into a test case and fix the bug.

@kiorky

This comment has been minimized.

Show comment
Hide comment
@kiorky

kiorky Mar 20, 2016

yes, i reproduce it with this vagrantfile:

Vagrant.configure(2) do |config|
  config.vm.box = "xenial64"
  config.vm.box_url = "http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-vagrant.box"
  config.vm.network "private_network", ip: "192.168.33.10"
end
==> default: Checking for guest additions in VM...
==> default: Configuring and enabling network interfaces...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
/sbin/ifdown eth1 2> /dev/null
Stdout from the command:
Stderr from the command:
sudo: unable to resolve host ubuntu-xenial
mesg: ttyname failed: Inappropriate ioctl for device

kiorky commented Mar 20, 2016

yes, i reproduce it with this vagrantfile:

Vagrant.configure(2) do |config|
  config.vm.box = "xenial64"
  config.vm.box_url = "http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-vagrant.box"
  config.vm.network "private_network", ip: "192.168.33.10"
end
==> default: Checking for guest additions in VM...
==> default: Configuring and enabling network interfaces...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
/sbin/ifdown eth1 2> /dev/null
Stdout from the command:
Stderr from the command:
sudo: unable to resolve host ubuntu-xenial
mesg: ttyname failed: Inappropriate ioctl for device

sethvargo pushed a commit that referenced this issue Mar 20, 2016

Seth Vargo
Do not return an error if ifdown fails
Ubuntu versions prior to 16.04 always returned a successful exit status,
even if one tried to down an interface that does not exist. This
behavior changed in Ubuntu 16.04 to return an error. This commit
preserves the old behavior.

Fixes GH-7155

@sethvargo sethvargo added the has-pr label Mar 20, 2016

@valkum

This comment has been minimized.

Show comment
Hide comment
@valkum

valkum Mar 20, 2016

#6871 is the same problem. Maybe you mark one as a duplicate.
When can we expect a 1.8.2 with the fix included? Want to know until when i need to use a development version of vagrant.

valkum commented Mar 20, 2016

#6871 is the same problem. Maybe you mark one as a duplicate.
When can we expect a 1.8.2 with the fix included? Want to know until when i need to use a development version of vagrant.

@ecirtap

This comment has been minimized.

Show comment
Hide comment
@ecirtap

ecirtap Mar 20, 2016

Waiting for the fix, I used the following workaround to test my puppet code base against Xenial:

Vagrant.configure(2) do |config|
  config.vm.box = "xenial64"
  config.vm.box_url = "http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-vagrant.box"
  config.vm.network "private_network", ip: "192.168.33.10", auto_config: false
  config.vm.provision 'shell', inline: "ifconfig eth1 192.168.33.10"
end

The argument of ifconfig (eth1) may depend on the Xenial box you use; the one I built today using packer replaces eth1 by enp0s8 as soon as it can:

[    1.427584] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 08:00:27:4a:2c:32
[    1.427588] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[    1.802749] e1000 0000:00:08.0 eth1: (PCI:33MHz:32-bit) 08:00:27:60:5a:83
[    1.802754] e1000 0000:00:08.0 eth1: Intel(R) PRO/1000 Network Connection
[    1.803680] e1000 0000:00:08.0 enp0s8: renamed from eth1
[    1.805088] e1000 0000:00:03.0 enp0s3: renamed from eth0

(and ... I don't know why).

ecirtap commented Mar 20, 2016

Waiting for the fix, I used the following workaround to test my puppet code base against Xenial:

Vagrant.configure(2) do |config|
  config.vm.box = "xenial64"
  config.vm.box_url = "http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-vagrant.box"
  config.vm.network "private_network", ip: "192.168.33.10", auto_config: false
  config.vm.provision 'shell', inline: "ifconfig eth1 192.168.33.10"
end

The argument of ifconfig (eth1) may depend on the Xenial box you use; the one I built today using packer replaces eth1 by enp0s8 as soon as it can:

[    1.427584] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 08:00:27:4a:2c:32
[    1.427588] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[    1.802749] e1000 0000:00:08.0 eth1: (PCI:33MHz:32-bit) 08:00:27:60:5a:83
[    1.802754] e1000 0000:00:08.0 eth1: Intel(R) PRO/1000 Network Connection
[    1.803680] e1000 0000:00:08.0 enp0s8: renamed from eth1
[    1.805088] e1000 0000:00:03.0 enp0s3: renamed from eth0

(and ... I don't know why).

@kiorky

This comment has been minimized.

Show comment
Hide comment
@kiorky

kiorky Mar 21, 2016

i confirm this to be a dup of #6871

kiorky commented Mar 21, 2016

i confirm this to be a dup of #6871

@sevein

This comment has been minimized.

Show comment
Hide comment
@sevein

sevein Mar 24, 2016

0505771 worked for me, thanks!

sevein commented Mar 24, 2016

0505771 worked for me, thanks!

@valkum

This comment has been minimized.

Show comment
Hide comment
@valkum

valkum Mar 24, 2016

@ecirtap Thats another new feature with ubunut. The chaning the devise names to pci port and slot to better find a defunct network port in real life.
I think (at least the 16.04 cloud image on my machine doesn't change it) there is a kernel boot param or kernel flag to use the old naming scheme.

valkum commented Mar 24, 2016

@ecirtap Thats another new feature with ubunut. The chaning the devise names to pci port and slot to better find a defunct network port in real life.
I think (at least the 16.04 cloud image on my machine doesn't change it) there is a kernel boot param or kernel flag to use the old naming scheme.

@hbokh

This comment has been minimized.

Show comment
Hide comment
@hbokh

hbokh Mar 27, 2016

@valkum and @ecirtap Check Ask Ubuntu for the specific kernel boot parameters: http://askubuntu.com/a/732638/16590

hbokh commented Mar 27, 2016

@valkum and @ecirtap Check Ask Ubuntu for the specific kernel boot parameters: http://askubuntu.com/a/732638/16590

@sethvargo sethvargo closed this in #7159 Mar 31, 2016

kamigerami added a commit to kamigerami/vagrant that referenced this issue Apr 1, 2016

Do not return an error if ifdown fails
Ubuntu versions prior to 16.04 always returned a successful exit status,
even if one tried to down an interface that does not exist. This
behavior changed in Ubuntu 16.04 to return an error. This commit
preserves the old behavior.

Fixes GH-7155
@dougneal

This comment has been minimized.

Show comment
Hide comment
@dougneal

dougneal Apr 18, 2016

Although this could be worked around by sending the net.ifnames=0 kernel parameter, this is actually requesting legacy behaviour (and also requires a rebuild of the box). #7241 has a fix to adapt the network configuration logic to the new interface naming scheme.

Although this could be worked around by sending the net.ifnames=0 kernel parameter, this is actually requesting legacy behaviour (and also requires a rebuild of the box). #7241 has a fix to adapt the network configuration logic to the new interface naming scheme.

@DBeazy

This comment has been minimized.

Show comment
Hide comment
@DBeazy

DBeazy Apr 19, 2016

Is there a fix for this in the mean time, if that PR ever gets merged and put in a tag release, as this issue is causing halts in development cycles for myself and clients.

DBeazy commented Apr 19, 2016

Is there a fix for this in the mean time, if that PR ever gets merged and put in a tag release, as this issue is causing halts in development cycles for myself and clients.

@ashantyk

This comment has been minimized.

Show comment
Hide comment
@ashantyk

ashantyk Apr 21, 2016

i can confirm i had the same issue and ended up making my own box (vagrant init gbarbieru/xenial) using this script bit.ly/vagrant-xenial .
the latest official ubuntu/xenial64 still doesn't work with private networks with the current version of vagrant (1.8.1)

i can confirm i had the same issue and ended up making my own box (vagrant init gbarbieru/xenial) using this script bit.ly/vagrant-xenial .
the latest official ubuntu/xenial64 still doesn't work with private networks with the current version of vagrant (1.8.1)

@cnk

This comment has been minimized.

Show comment
Hide comment
@cnk

cnk Apr 22, 2016

I have been able to get a xenial box working using the code currently on vagrant master (the gem calls itself 1.8.2-dev) + the vbox image from boxcutter - boxcutter/ubuntu1604. The official ubuntu/xenial64 image is missing libnss-myhostname so all the sudo hostname calls error with a message about the current hostname not resolving - see related issue: #7241 (comment)

I would love to find contact info for the maintainers of the official ubuntu vagrant images. It looks like a relatively small change might make the current code on master work.

cnk commented Apr 22, 2016

I have been able to get a xenial box working using the code currently on vagrant master (the gem calls itself 1.8.2-dev) + the vbox image from boxcutter - boxcutter/ubuntu1604. The official ubuntu/xenial64 image is missing libnss-myhostname so all the sudo hostname calls error with a message about the current hostname not resolving - see related issue: #7241 (comment)

I would love to find contact info for the maintainers of the official ubuntu vagrant images. It looks like a relatively small change might make the current code on master work.

@Ma27 Ma27 referenced this issue in Sententiaregum/Sententiaregum Apr 30, 2016

Closed

use ubuntu/xenial64 basebox #264

@taylorotwell

This comment has been minimized.

Show comment
Hide comment
@taylorotwell

taylorotwell May 1, 2016

Also having this problem.

Also having this problem.

simbo added a commit to simbo/packer-ubuntu that referenced this issue May 1, 2016

@ryanwohara

This comment has been minimized.

Show comment
Hide comment
@ryanwohara

ryanwohara May 3, 2016

+1 I am also encountering this issue

+1 I am also encountering this issue

@Repox

This comment has been minimized.

Show comment
Hide comment
@Repox

Repox May 4, 2016

+1
When will the fix be released?

Repox commented May 4, 2016

+1
When will the fix be released?

@jhulick

This comment has been minimized.

Show comment
Hide comment

jhulick commented May 4, 2016

+1

@hbokh

This comment has been minimized.

Show comment
Hide comment
@hbokh

hbokh May 4, 2016

All,
If you really need a working Ubuntu 16.04 / xenial64 on Virtualbox today, try @geerlingguy 's VB-image named geerlingguy/ubuntu1604 (URL: https://atlas.hashicorp.com/geerlingguy/boxes/ubuntu1604/)

hbokh commented May 4, 2016

All,
If you really need a working Ubuntu 16.04 / xenial64 on Virtualbox today, try @geerlingguy 's VB-image named geerlingguy/ubuntu1604 (URL: https://atlas.hashicorp.com/geerlingguy/boxes/ubuntu1604/)

@ar-lex

This comment has been minimized.

Show comment
Hide comment
@ar-lex

ar-lex May 4, 2016

@cnk, the package libnss-myhostname isn't missing, it isn't recommended - see https://bugs.launchpad.net/ubuntu/+source/libnss-myhostname/+bug/1162478/comments/6
The only "official" workaround for now is to manually add 127.0.1.1 hostname record to /etc/hosts file.
I assume that systemd itself should handle that, but Debian developers aren't using this feature yet.

ar-lex commented May 4, 2016

@cnk, the package libnss-myhostname isn't missing, it isn't recommended - see https://bugs.launchpad.net/ubuntu/+source/libnss-myhostname/+bug/1162478/comments/6
The only "official" workaround for now is to manually add 127.0.1.1 hostname record to /etc/hosts file.
I assume that systemd itself should handle that, but Debian developers aren't using this feature yet.

@topikito

This comment has been minimized.

Show comment
Hide comment
@topikito

topikito May 12, 2016

@hbokh I don't know if you know @geerlingguy, but I found in his image that theres a lock file at /var/lib/dpkg/lock which makes me have to remove it first before I can provision the machine (in my case with Ansible) - Is this only happening to me?

@hbokh I don't know if you know @geerlingguy, but I found in his image that theres a lock file at /var/lib/dpkg/lock which makes me have to remove it first before I can provision the machine (in my case with Ansible) - Is this only happening to me?

@geerlingguy

This comment has been minimized.

Show comment
Hide comment
@geerlingguy

geerlingguy May 12, 2016

Contributor

@topikito / @hbokh - Yikes! Sorry about that... I didn't run into it in my testing, but I did just notice someone else having an issue with apt being locked last night.

Can you file an issue upstream, in the Packer config? https://github.com/geerlingguy/packer-ubuntu-1604

Contributor

geerlingguy commented May 12, 2016

@topikito / @hbokh - Yikes! Sorry about that... I didn't run into it in my testing, but I did just notice someone else having an issue with apt being locked last night.

Can you file an issue upstream, in the Packer config? https://github.com/geerlingguy/packer-ubuntu-1604

@gretel

This comment has been minimized.

Show comment
Hide comment
@gretel

gretel May 12, 2016

@topikito @hbokh @geerlingguy it works as intended when unattended-upgrades are enabled. there is a python3 process (pgrep for unattended-upgrade) since 16.04 which manages apt. during it's run the locking occurs. due to the fact that a freshly provisioned boxen can install quite a bunch of updates and do it just after boot it can take a while until the lock is gone.

possible solutions:

  • turn off unattended-upgrades by default (in the packer config d-i pkgsel/update-policy select unattended-upgradesd-i pkgsel/update-policy select unattended-upgrades)
  • use a hack like mine (check wait_pids)

it's a good idea to have it enabled, at least for the sake of security. in my case i will re-enable it later on.

gretel commented May 12, 2016

@topikito @hbokh @geerlingguy it works as intended when unattended-upgrades are enabled. there is a python3 process (pgrep for unattended-upgrade) since 16.04 which manages apt. during it's run the locking occurs. due to the fact that a freshly provisioned boxen can install quite a bunch of updates and do it just after boot it can take a while until the lock is gone.

possible solutions:

  • turn off unattended-upgrades by default (in the packer config d-i pkgsel/update-policy select unattended-upgradesd-i pkgsel/update-policy select unattended-upgrades)
  • use a hack like mine (check wait_pids)

it's a good idea to have it enabled, at least for the sake of security. in my case i will re-enable it later on.

@geerlingguy

This comment has been minimized.

Show comment
Hide comment
@geerlingguy

geerlingguy May 12, 2016

Contributor

@gretel - I like the idea of unattended upgrades being enabled—but for various reasons in provisioning, I don't like having it enabled out of the box (I didn't realize it was this way in 16.04)—I always use my Ansible security role to enable and configure it as part of my provisioning process.

I'm torn on whether I'd like to disable by default... knowing that my boxes are used (hopefully) only for local development environments (inaccessible outside local private networks), it wouldn't be a major security concern.

Contributor

geerlingguy commented May 12, 2016

@gretel - I like the idea of unattended upgrades being enabled—but for various reasons in provisioning, I don't like having it enabled out of the box (I didn't realize it was this way in 16.04)—I always use my Ansible security role to enable and configure it as part of my provisioning process.

I'm torn on whether I'd like to disable by default... knowing that my boxes are used (hopefully) only for local development environments (inaccessible outside local private networks), it wouldn't be a major security concern.

@gretel

This comment has been minimized.

Show comment
Hide comment
@gretel

gretel May 12, 2016

@geerlingguy personally, i also prefer unattended-upgrades but not before they get enabled by the automation approach in place. as i usually use ansible to kick chef-solo to work i let it enable it as the last thing on the first successful run.

gretel commented May 12, 2016

@geerlingguy personally, i also prefer unattended-upgrades but not before they get enabled by the automation approach in place. as i usually use ansible to kick chef-solo to work i let it enable it as the last thing on the first successful run.

@topikito

This comment has been minimized.

Show comment
Hide comment
@topikito

topikito May 13, 2016

@geerlingguy Sorry for the delay - timezone differences made me unavailable until now. I guess you've already opened an issue so no need for me to do ;)

geerlingguy/packer-ubuntu-1604#3 (comment)

@geerlingguy Sorry for the delay - timezone differences made me unavailable until now. I guess you've already opened an issue so no need for me to do ;)

geerlingguy/packer-ubuntu-1604#3 (comment)

@tersmitten tersmitten referenced this issue in Oefenweb/ansible-percona-server May 13, 2016

Merged

Removal of deprecated operating systems #16

@legal90 legal90 referenced this issue in Parallels/vagrant-parallels May 15, 2016

Closed

Can't up public network with ubuntu 16.04 #264

@designermonkey

This comment has been minimized.

Show comment
Hide comment
@designermonkey

designermonkey May 19, 2016

When is this going to be addressed as a bugfix release into vagrant? We have today just upgraded to 1.8.1 and found this issue which has now derailed our project, in that we can't mirror our live environment.

I notice there is a has-pr label attached. What is the PR? When will this be merged?

When is this going to be addressed as a bugfix release into vagrant? We have today just upgraded to 1.8.1 and found this issue which has now derailed our project, in that we can't mirror our live environment.

I notice there is a has-pr label attached. What is the PR? When will this be merged?

@designermonkey

This comment has been minimized.

Show comment
Hide comment
@designermonkey

designermonkey May 19, 2016

Additional: I have tried to install vagrant from git too to get around this, and I must say it ain't as simp,e as rake install. bundler won't install, gems won't install.

This really needs addressing as the fix has been available for ages now. Someone needs to take the lead here and resolve this.

Additional: I have tried to install vagrant from git too to get around this, and I must say it ain't as simp,e as rake install. bundler won't install, gems won't install.

This really needs addressing as the fix has been available for ages now. Someone needs to take the lead here and resolve this.

@macchickpro

This comment has been minimized.

Show comment
Hide comment
@macchickpro

macchickpro May 19, 2016

Vagrant 1.8.1
Virtual box 5.0.20 r106931
Host: MACOSX 10.11.5

I had to do a little bit more work (hope that helps)

  1. I didn't care whether the interface was called eth1 or the default enp0s8. Wanted it to be called eth1 made me do more work. So I kept the default

  2. I add the have the auto-config false because if not, it would fail while configuring and nothing else will happen (that is, inline script would not run, /vagrant wouldn't mount...)

  3. adding the ifconfig enp0s8 192.168.33.18 was required to then bind the IP to the interface since I had auto-config false.

  4. I don't use the ubuntu box because it requires a ubuntu user/password and I know I can tell it do do something else, but private network is much more important for my project spec that I used the bento box instead which does the normal vagrant user/keys auth

config.vm.box = "bento/ubuntu-16.04" <br \>
config.vm.network :private_network, ip: "192.168.33.18", auto_config: false
config.vm.provision "shell",
    inline: 'echo "
    # The private net network interface
     auto enp0s8
     iface enp0s8 inet manual
     pre-up sleep 2" >>  /etc/network/interfaces.d/enp0s8.cfg; ifup enp0s8;ifconfig enp0s8 192.168.33.18'

I still get the error on provisioning:

mesg: 
ttyname failed
Inappropriate ioctl for device

and I'm not sure what's that is referring to but I can ping the machine with my private address, so for now I'm good.

Thanks for the people that posted their working solution that really helped me getting to that one that worked in my environment!

Vagrant 1.8.1
Virtual box 5.0.20 r106931
Host: MACOSX 10.11.5

I had to do a little bit more work (hope that helps)

  1. I didn't care whether the interface was called eth1 or the default enp0s8. Wanted it to be called eth1 made me do more work. So I kept the default

  2. I add the have the auto-config false because if not, it would fail while configuring and nothing else will happen (that is, inline script would not run, /vagrant wouldn't mount...)

  3. adding the ifconfig enp0s8 192.168.33.18 was required to then bind the IP to the interface since I had auto-config false.

  4. I don't use the ubuntu box because it requires a ubuntu user/password and I know I can tell it do do something else, but private network is much more important for my project spec that I used the bento box instead which does the normal vagrant user/keys auth

config.vm.box = "bento/ubuntu-16.04" <br \>
config.vm.network :private_network, ip: "192.168.33.18", auto_config: false
config.vm.provision "shell",
    inline: 'echo "
    # The private net network interface
     auto enp0s8
     iface enp0s8 inet manual
     pre-up sleep 2" >>  /etc/network/interfaces.d/enp0s8.cfg; ifup enp0s8;ifconfig enp0s8 192.168.33.18'

I still get the error on provisioning:

mesg: 
ttyname failed
Inappropriate ioctl for device

and I'm not sure what's that is referring to but I can ping the machine with my private address, so for now I'm good.

Thanks for the people that posted their working solution that really helped me getting to that one that worked in my environment!

@cinvoke

This comment has been minimized.

Show comment
Hide comment
@cinvoke

cinvoke May 30, 2016

i get the same.
Host: El Capitan.
vbox: 5.0.10 r104061
vagrant: 1.7.4
Guest: Ubuntu 16.04
config.vm.network "private_network", ip: "192.168.16.2"

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
/sbin/ifdown eth1 2> /dev/null

Stdout from the command:

Stderr from the command:

mesg: ttyname failed: Inappropriate ioctl for device

it does however seem to be populating interfaces file just fine.
im going to try updating vagrant ...

cinvoke commented May 30, 2016

i get the same.
Host: El Capitan.
vbox: 5.0.10 r104061
vagrant: 1.7.4
Guest: Ubuntu 16.04
config.vm.network "private_network", ip: "192.168.16.2"

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
/sbin/ifdown eth1 2> /dev/null

Stdout from the command:

Stderr from the command:

mesg: ttyname failed: Inappropriate ioctl for device

it does however seem to be populating interfaces file just fine.
im going to try updating vagrant ...

@tersmitten tersmitten referenced this issue in Oefenweb/ansible-mydumper May 30, 2016

Merged

Added support for Ubuntu 16.04 #5

@ericpulvino

This comment has been minimized.

Show comment
Hide comment
@ericpulvino

ericpulvino May 30, 2016

Contributor

FYI as a workaround you can try not setting the IP. I never use Vagrant to set the IP's... instead use a provisioner and that works just fine for my particular use case but since I work for Cumulus Networks I hit the networking with a lot of other things than just and IP and Vagrant doesn't support them all so for me there is no sense in fragmenting the provisioning between vagrant and another tool. Plus then I can reuse the automation in production with little/no modification. YMMV.

Contributor

ericpulvino commented May 30, 2016

FYI as a workaround you can try not setting the IP. I never use Vagrant to set the IP's... instead use a provisioner and that works just fine for my particular use case but since I work for Cumulus Networks I hit the networking with a lot of other things than just and IP and Vagrant doesn't support them all so for me there is no sense in fragmenting the provisioning between vagrant and another tool. Plus then I can reuse the automation in production with little/no modification. YMMV.

@foxx

This comment has been minimized.

Show comment
Hide comment
@foxx

foxx Jun 9, 2016

Still having this problem;

Vagrant 1.8.1

config.vm.box = "ubuntu/xenial64"
config.vm.synced_folder ".", "/opt/code", type: "nfs"
config.vm.network "private_network", type: "dhcp"

foxx commented Jun 9, 2016

Still having this problem;

Vagrant 1.8.1

config.vm.box = "ubuntu/xenial64"
config.vm.synced_folder ".", "/opt/code", type: "nfs"
config.vm.network "private_network", type: "dhcp"
@ryanmcgrath

This comment has been minimized.

Show comment
Hide comment
@ryanmcgrath

ryanmcgrath Jun 10, 2016

This would be really great if it got released and bumped. Affected as well.

This would be really great if it got released and bumped. Affected as well.

@jayywolff

This comment has been minimized.

Show comment
Hide comment
@jayywolff

jayywolff Jun 11, 2016

looks like the update was finally released. Thanks guys!

looks like the update was finally released. Thanks guys!

@designermonkey

This comment has been minimized.

Show comment
Hide comment
@designermonkey

designermonkey Jun 11, 2016

Unfortunately, I now have the following error:

Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:

mount -t vboxsf -o uid=`id -u ubuntu`,gid=`getent group ubuntu | cut -d: -f3` vagrant /vagrant
mount -t vboxsf -o uid=`id -u ubuntu`,gid=`id -g ubuntu` vagrant /vagrant

The error output from the last command was:

sudo: unable to resolve host ubuntu-xenial
mesg: ttyname failed: Inappropriate ioctl for device
mount: unknown filesystem type 'vboxsf'

For reference (I can't see this linked here as I scan over the issue): https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1561250

designermonkey commented Jun 11, 2016

Unfortunately, I now have the following error:

Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:

mount -t vboxsf -o uid=`id -u ubuntu`,gid=`getent group ubuntu | cut -d: -f3` vagrant /vagrant
mount -t vboxsf -o uid=`id -u ubuntu`,gid=`id -g ubuntu` vagrant /vagrant

The error output from the last command was:

sudo: unable to resolve host ubuntu-xenial
mesg: ttyname failed: Inappropriate ioctl for device
mount: unknown filesystem type 'vboxsf'

For reference (I can't see this linked here as I scan over the issue): https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1561250

@flowerett

This comment has been minimized.

Show comment
Hide comment
@flowerett

flowerett Jun 14, 2016

confirm, same error for me when I try to add synced_folder with xenial(16.04)
but works for this wily(15.10) image:
https://cloud-images.ubuntu.com/vagrant/wily/current/wily-server-cloudimg-amd64-vagrant-disk1.box

confirm, same error for me when I try to add synced_folder with xenial(16.04)
but works for this wily(15.10) image:
https://cloud-images.ubuntu.com/vagrant/wily/current/wily-server-cloudimg-amd64-vagrant-disk1.box

@foxx

This comment has been minimized.

Show comment
Hide comment
@foxx

foxx Jun 14, 2016

@flowerett Have you tried with the latest Vagrant? There was a new release a few days ago, but it's broken other things too

foxx commented Jun 14, 2016

@flowerett Have you tried with the latest Vagrant? There was a new release a few days ago, but it's broken other things too

@flowerett

This comment has been minimized.

Show comment
Hide comment
@flowerett

flowerett Jun 14, 2016

$ vagrant --version
Vagrant 1.8.3
will try 1.8.4, thanks!

$ vagrant --version
Vagrant 1.8.3
will try 1.8.4, thanks!

@flowerett

This comment has been minimized.

Show comment
Hide comment
@flowerett

flowerett Jun 14, 2016

$ vagrant --version
Vagrant 1.8.4

got this error now:

Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:

mount -t vboxsf -o uid=`id -u ubuntu`,gid=`getent group ubuntu | cut -d: -f3` code_searchapp /code/searchapp
mount -t vboxsf -o uid=`id -u ubuntu`,gid=`id -g ubuntu` code_searchapp /code/searchapp

The error output from the last command was:

sudo: unable to resolve host ubuntu-xenial
mesg: ttyname failed: Inappropriate ioctl for device
mount: unknown filesystem type 'vboxsf'
$ vagrant --version
Vagrant 1.8.4

got this error now:

Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:

mount -t vboxsf -o uid=`id -u ubuntu`,gid=`getent group ubuntu | cut -d: -f3` code_searchapp /code/searchapp
mount -t vboxsf -o uid=`id -u ubuntu`,gid=`id -g ubuntu` code_searchapp /code/searchapp

The error output from the last command was:

sudo: unable to resolve host ubuntu-xenial
mesg: ttyname failed: Inappropriate ioctl for device
mount: unknown filesystem type 'vboxsf'
@foxx

This comment has been minimized.

Show comment
Hide comment
@foxx

foxx Jun 14, 2016

Possibly related to #7433. If you need a quick fix, then the only latest Ubuntu image that will work with Vagrant is trusty64. However if you /really/ need support for Xenial then you can custom build an image using bento.

Based on historic waiting times, this probably won't get fixed for quite a while. If you need it urgently then don't wait for a fix, roll your own.

foxx commented Jun 14, 2016

Possibly related to #7433. If you need a quick fix, then the only latest Ubuntu image that will work with Vagrant is trusty64. However if you /really/ need support for Xenial then you can custom build an image using bento.

Based on historic waiting times, this probably won't get fixed for quite a while. If you need it urgently then don't wait for a fix, roll your own.

@mylons

This comment has been minimized.

Show comment
Hide comment
@mylons

mylons Jun 14, 2016

upped to vagrant 1.8.4, and also affected by the same issue as @flowerett and, 26 days later completely agree with @designermonkey

mylons commented Jun 14, 2016

upped to vagrant 1.8.4, and also affected by the same issue as @flowerett and, 26 days later completely agree with @designermonkey

@foxx

This comment has been minimized.

Show comment
Hide comment
@foxx

foxx Jun 14, 2016

@mylons I've reached out to both Seth and Mitchell on Twitter asking what the state of Vagrant here.

image

foxx commented Jun 14, 2016

@mylons I've reached out to both Seth and Mitchell on Twitter asking what the state of Vagrant here.

image

@virgofx

This comment has been minimized.

Show comment
Hide comment
@virgofx

virgofx Jun 14, 2016

Agreed. As a windows user, the past year of upgrading has caused problems every time. In the process of going from 1.8.3 to 1.8.4 now to fix the maximum nic issue.

virgofx commented Jun 14, 2016

Agreed. As a windows user, the past year of upgrading has caused problems every time. In the process of going from 1.8.3 to 1.8.4 now to fix the maximum nic issue.

@sebastiaanluca

This comment has been minimized.

Show comment
Hide comment
@sebastiaanluca

sebastiaanluca Jun 18, 2016

Thought 1.8.4 would fix this as it fixes a lot of similar issues, but running into the same problem:

sudo: unable to resolve host ubuntu-xenial
mesg: ttyname failed: Inappropriate ioctl for device

I can SSH into the virtual machine, but cannot provision it.

Thought 1.8.4 would fix this as it fixes a lot of similar issues, but running into the same problem:

sudo: unable to resolve host ubuntu-xenial
mesg: ttyname failed: Inappropriate ioctl for device

I can SSH into the virtual machine, but cannot provision it.

@jnardiello

This comment has been minimized.

Show comment
Hide comment
@jnardiello

jnardiello Jun 25, 2016

affected as well.

affected as well.

@sethvargo

This comment has been minimized.

Show comment
Hide comment
@sethvargo

sethvargo Jun 25, 2016

Contributor

Hi all,

As I said to @foxx on Twitter, the boxes published by canonical under the ubuntu namespace for 16.04 are very broken. They do not follow the recommended guides for how to build a Vagrant box, and they are missing key components such as guest additions, required packages, or they do things like hardcode the hostname to make running concurrent VMs impossible. None of these are bugs in Vagrant, and, unfortunately there is not very much Vagrant can do to make this experience better. There are bare minimum requirements for building base boxes with Vagrant, and that image is simply malformed.

In general, users have had more success with the boxes under the bento namespaces. A common misconception is that a namespace like "ubuntu" represents the canonical space for Ubuntu boxes. This is untrue. Namespaces on Atlas behave very similarly to namespaces on GitHub, for example. Just as GitHub's support team is unable to assist with issues in someone's repository, HashiCorp's is not able to assist with third-party published boxes. You can open bugs on launchpad, but I would highly recommend trying the bento boxes instead.

The bento boxes are open source and they are built using best practices and Packer. Unlike the "ubuntu" boxes, the bento boxes also support more providers such as VMware, Virtualbox, and Parallels.

It's my least favorite thing to do, but I'm going to lock this issue. I'm doing this because I don't want this issue to become a black hole of "me too" and potentially mask real bugs. If you do continue to encounter errors, please open a new issue and follow the issue template that appears. This will assist us in providing a timely response and fix.

Contributor

sethvargo commented Jun 25, 2016

Hi all,

As I said to @foxx on Twitter, the boxes published by canonical under the ubuntu namespace for 16.04 are very broken. They do not follow the recommended guides for how to build a Vagrant box, and they are missing key components such as guest additions, required packages, or they do things like hardcode the hostname to make running concurrent VMs impossible. None of these are bugs in Vagrant, and, unfortunately there is not very much Vagrant can do to make this experience better. There are bare minimum requirements for building base boxes with Vagrant, and that image is simply malformed.

In general, users have had more success with the boxes under the bento namespaces. A common misconception is that a namespace like "ubuntu" represents the canonical space for Ubuntu boxes. This is untrue. Namespaces on Atlas behave very similarly to namespaces on GitHub, for example. Just as GitHub's support team is unable to assist with issues in someone's repository, HashiCorp's is not able to assist with third-party published boxes. You can open bugs on launchpad, but I would highly recommend trying the bento boxes instead.

The bento boxes are open source and they are built using best practices and Packer. Unlike the "ubuntu" boxes, the bento boxes also support more providers such as VMware, Virtualbox, and Parallels.

It's my least favorite thing to do, but I'm going to lock this issue. I'm doing this because I don't want this issue to become a black hole of "me too" and potentially mask real bugs. If you do continue to encounter errors, please open a new issue and follow the issue template that appears. This will assist us in providing a timely response and fix.

@hashicorp hashicorp locked and limited conversation to collaborators Jun 25, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.