ubuntu 15.10 & 16.04 guests wont work with private networks

[kiorky]

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]

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]

@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]

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

[kiorky]

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]

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]

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

[valkum]

#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]

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]

i confirm this to be a dup of #6871

[sevein]

0505771 worked for me, thanks!

[valkum]

@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]

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

[dougneal]

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). mitchellh#7241 has a fix to adapt the network configuration logic to the new interface naming scheme.

[DBeazy]

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]

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]

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: mitchellh#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.

[taylorotwell]

Also having this problem.

[ryanwohara]

+1 I am also encountering this issue

[Repox]

+1
When will the fix be released?

[jhulick]

+1

[hbokh]

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]

@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]

@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]

@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]

@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]

@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]

@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]

@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)

[designermonkey]

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]

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]

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]

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

[ericpulvino]

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]

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 would be really great if it got released and bumped. Affected as well.

[jayywolff]

looks like the update was finally released. Thanks guys!

[designermonkey]

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]

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]

@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]

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

[flowerett]

$ 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]

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]

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

[foxx]

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

[virgofx]

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]

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]

affected as well.

[sethvargo]

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.