Previously using a custom 15.04 all worked fine
==> dev: Setting hostname...
==> dev: Configuring and enabling network interfaces...
==> dev: Mounting shared folders...
new custom 15.10 box, virtually no changes to box just an updated ubuntu version
==> dev: Setting hostname...
==> dev: 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/ip addr flush dev eth1 2> /dev/null
Stdout from the command:
Stderr from the command:
mesg: ttyname failed: Inappropriate ioctl for device
Similar to #6577 but I'm already on vagrant 1.8
$ vagrant -v
Vagrant 1.8.1
Same here with 1.8.1
with this config
config.vm.box = "ubuntu/wily64"
config.vm.provision "shell", run: "always", inline: "route add default gw 1.2.3.4"
Anyone had a chance to look into this?
Take a look at this http://askubuntu.com/questions/671228/lost-network-device-on-upgrade-to-15-10-on-test-vm
eth0
was changed to enp0s3
In moving forward in fixing this issue. Would need more looking into.
@RudyJessop this is a fresh vm so makes perfect sense
enp0s3 is the name of an Ethernet device as given by the new version of udev, which enables stateless persistant network interface names.
I think this is a duplicate of #6653 and would be fixed in pull #6724 if it gets merged.
@schmunk42, I think you are experiencing a related but different issue. The ubuntu/wily64
box seems to be failing at the initial ssh connection during boot and is outlined in #6683.
@gMagicScott Yes, I think you're right. I just get the error mesg: ttyname failed: Inappropriate ioctl for device
and I must not use run: "always",
- it's working fine for me so far.
@gMagicScott that makes sense thanks, let's hope the pr get's merged sometime
I'm seeing the same thing here for debian sid, which is using a 4.3 kernel now, and vagrant 1.8.1. Debug log in the gist https://gist.github.com/dch/0cc4735b81cf84cf3f73 along with this simply ugly hack to get things working:
--- ./plugins/guests/debian/cap/configure_networks.rb.orig 2016-02-19 14:04:24.000000000 +0100
+++ ./plugins/guests/debian/cap/configure_networks.rb 2016-02-19 14:35:15.000000000 +0100
@@ -42,8 +42,8 @@
# each specifically, we avoid reconfiguring eth0 (the NAT interface) so
# SSH never dies.
interfaces.each do |interface|
- comm.sudo("/sbin/ifdown eth#{interface} 2> /dev/null")
- comm.sudo("/sbin/ip addr flush dev eth#{interface} 2> /dev/null")
+ comm.sudo("/sbin/ifdown eth#{interface} 2> /dev/null || /bin/true")
+ comm.sudo("/sbin/ip addr flush dev eth#{interface} 2> /dev/null || /bin/true")
end
comm.sudo('cat /tmp/vagrant-network-interfaces.pre /tmp/vagrant-network-entry /tmp/vagrant-network-interfaces.post > /etc/network/interfaces')
A real fix for this is sorely needed, I'm not sure if my hack above is appropriate for a PR or not.
I'm having the same problem with Ubuntu Xenial. To work around it, I ended up forcing net.ifnames=0
in the kernel boot arguments for my base box in Packer. This has to be done both in the kernel arguments passed by keyboard, and in the preseed.cfg for the box (or else /etc/network/interfaces references the wrong ifnames on reboot and the VM never comes online). The latter itself is really frustrating because of a grub-installer bug, so I landed on this:
d-i preseed/late_command string sed -i 's/\(GRUB_CMDLINE_LINUX_DEFAULT=\).*/\1\"quiet splash net.ifnames=0\"/g' /target/etc/default/grub; in-target update-grub
Just for the record, i've the same problem (tried with http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-vagrant.box), which should be working out of the box.
If i don't specify any network, it runs fine.
As soon as i add an extra network, it fails with the same error.
In this case, eth1 is not found.
Just as an additional note, i tryed with the Atlas debian/jessie64 box, and it works fine (but i also note that the box is creating the network devices with eth0, eth1 and lo - which match the old name convention).
Cheers,
LF
Indeed jessie is fine AFAICS but current testing is problematic. I can confirm the issue on a box based on testing (created using https://github.com/tiwilliam/vagrant-debian).
The update of ifupdown (0.8.7) is causing this. The behaviour of ifupdown is changed if the interface doesn't exists. With 0.8.7 it returns an error.
@sethvargo The Fix in #7159 is not complete. I still get errors after applying that patch:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
/sbin/ip addr flush dev eth1 2> /dev/null
Stdout from the command:
Stderr from the command:
mesg: ttyname failed: Inappropriate ioctl for device
And if I add the same || true
bit to that command I get:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
/sbin/ifup eth1
Stdout from the command:
Failed to bring up eth1.
Stderr from the command:
mesg: ttyname failed: Inappropriate ioctl for device
Cannot find device "eth1"
Confirmed that using net.ifnames=0
by @jgoldschrafe when building the box works fine.
I think evaluating the PR in #6724 is probably worthwhile to make Vagrant handle the new behaviour more gracefully?
The relevant Vagrantfile bits from my host:
def linux config, ip, box, hostname
config.vm.define hostname.to_sym do |c|
c.vm.network :private_network, ip: ip
c.vm.box = box
c.vm.hostname = '%s.local' % hostname.to_sym
c.vm.boot_timeout = 900
end
end
Vagrant.configure('2') do |config|
linux config, '10.0.0.154', 'denis/ubuntu-16.04-amd64', 'ubuntu-16.04-amd64'
end
I am having the same issues as @denisbr. This patch isn't working for me.
Here is the link to my Vagrantfile.
vagrant up xenial64
@sethvargo looks like this is still broken, can we reopen this issue?
This definitely needs to be reopened - it's a showstopper for anyone needing more than one network interface on Xenial. It looks as though in the systemd world, the new interface naming scheme is The Way Of The Future (for better or worse). I've put together PR https://github.com/mitchellh/vagrant/pull/7241 to adapt the interface configuration logic to handle this in both the old world and the new. This is a slightly different approach to @gMagicScott's in that it doesn't introduce a distinction between Debian and Ubuntu, and assumes that Debian will go the same way.
Having the same problem here with ubuntu/xenial64 build running on Arch Linux and vagrant 1.8.1
Note that I think I've now found about 20 different forum posts, GitHub issues, etc. pointing either at this issue (closed) or at the PR mentioned earlier (https://github.com/mitchellh/vagrant/pull/7241).
AFAICT, for many (most?) uses, Vagrant configs won't work with 15.10 or 16.04 boxes. I only deal with LTS releases for my needs, so this is the first time I've run into this issue (I'm trying to build my 16.04 minimal base box with Packer, and everything works except for Configuring and enabling network interfaces...
—I can manually vagrant ssh
into the machine after I do a vagrant up
that errors out.
The network interface I get by default is enp0s3
.
just to add my 2p worth, none of the workarounds work for me (true's everywhere, editing /etc/default/grub and so on) on debian sid 64-bit host, ubuntu/xenial64 guest, virtualbox 5.0.19 test build is needed to even get xenial to boot, running vagrant 1.8.1
seems the only way to get it working is to make your own packer image with the grub change.
is there no working PR yet? #7241 is incomplete it seems.
also any idea why this wasn't picked up with e.g. centos7 guests, as they use the same naming convention....? or is there something else afoot?
@sej7278 - Here's my fix: https://github.com/geerlingguy/packer-ubuntu-1604/issues/1 — of course building my own image with Packer here... no simple way I can see this being fixed on a base box that's already built without the grub/networking changes in place until Vagrant supports predictable network interface names.
@geerlingguy yes i've been reading that issue, it does seem like a bit of a nightmare, essentially i think they'll have to follow the same logic as the netdev code for finding/allocating interface names, or convince ubuntu to change their cloud image
i've tried your grub/interfaces workarounds (btw iface eth1 inet dhcp
should be eth0) and still i have to apt-get install python
and add 127.0.1.1 ubuntu-xenial
to /etc/hosts, then it works, but it takes about 3mins to boot due to not finding the network interfaces or something odd, and they're not using the vagrant username!
Hey,
anything new about this issue? It's closed but still occurs on Ubuntu 16.04 and vagrant 1.8.1
@sethvargo Please reopen
Gi @fsvehla
This issue is fixed, it just hasn't been released yet. Please review the history - there is a merged PR that fixes this.
@sethvargo, the merged fix doesn't actually fix the issue. When I tried it with xenial beta2, it failed to fix the issue. Has anyone tried it with the released xenial image?
Hi @chrisvire
Have you tried it with the final release? A number of people are reporting success with that patch, so perhaps your issue is slightly different.
@sethvargo: I am working on verifying it right now.
@sethvargo: Yes, I have tried these changes with my rebuilt xenial box and it doesn't solve the issue.
Here is the link to my Vagrantfile.
git clone https://github.com/chrisvire/vagrant-sil
cd vagrant-sil
vagrant up xenial64
This will download my xenial-unity-amd64.box (2.1GB) which has a bridged interface. This image is used to test desktop linux software so it needs the full desktop environment.
@sethvargo: Running ifconfig inside the VM gives these network adapters: enp0s3, enp0s8, lo. So it fails when trying to do any operations on eth1.
Just tried with 3 different images (Ubuntu / BoxCutter / geerlingguy ) on fresh clone and install of master (1.8.2.dev). I can confirm that Vagrant up still produces this same error. "Inappropriate ioctl for device"
I am also encountering this issue.
I've still got the issue with Ubuntu 16.04 guests too.
I don't really understand why this doesn't effect fedora23, centos7, debian8 etc; as they all use this stupid nic naming convention.
@sethvargo even the new bento/ubuntu-16.04
box from https://github.com/chef/bento with Ubuntu 16.04 fails with:
==> 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/ifup eth1
Stdout from the command:
Failed to bring up eth1.
Stderr from the command:
mesg: ttyname failed: Inappropriate ioctl for device
Cannot find device "eth1"
Because of enp0s3, enp0s8, lo
devices instead of eth0, eth1, lo
I guess we need a way to detect the interfaces instead of having a static assignment.
I guess we need a way to detect the interfaces instead of having a static assignment.
yup, as you can't just add the biosdevname=0 net.ifnames=0
kernel parameter, because you need to do that before the box has booted (chicken & egg!) and then edit the interfaces and hosts files too.
I created a pull request https://github.com/mitchellh/vagrant/pull/7253 to fix this issue and also a patch to vagrant 1.8.1 https://github.com/mitchellh/vagrant/pull/7253#issuecomment-216125836
@sethvargo this still seems to be a problem, can we please get this issue re-opened?
cc @mitchellh
+1
+1
+1
What worked for me, using a custom 16.04 box:
auto eth2
iface eth2 inet manual
+1
The above by @Roensby didn't work for me. This is what did:
sudo pico /etc/systemd/system/vagrant-network.service
[Unit]
Description=Rename vagrant network device
[Service]
Type=oneshot
ExecStart=/sbin/ip link set name eth1 dev enp0s8
[Install]
WantedBy=default.target
sudo systemctl enable vagrant-network.service
auto eth1
iface eth1 inet manual
tarek : )
still not fixed
ubuntu/xenial64 (20160610.0.0)
Vagrant 1.8.4
ubuntu 16.04
vagrant 1.8.1
-1 to my original +1 to @silesky's issue. Upgraded to 1.8.4 and ran without any issue.
did not work in vagrant 1.8.1 but works in 1.8.4
@chrisbaldauf
Update my vagrant from 1.8.1 to 1.8.4 fix the issue
Just encountered this similar issue for guest ubuntu/xenial64
.
$ vagrant --version
Vagrant 1.8.6
Note that the host is running MacOS Sierra 10.12
and VirtualBox 5.1.8
.
Here's the tail of logs after running vagrant up
.
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
set -e
mkdir -p /mnt/wf-dev
mount -o vers=3,udp 172.17.9.1:/Users/neilcalabroso/Projects/wf-dev /mnt/wf-dev
if command -v /sbin/init && /sbin/init --version | grep upstart; then
/sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=/mnt/wf-dev
fi
Stdout from the command:
Stderr from the command:
mesg: ttyname failed: Inappropriate ioctl for device
mount.nfs: Connection timed out
I'm having the same error with ubuntu/xenial64
and Vagrant 1.8.6
.
==> default: mesg: ttyname failed: Inappropriate ioctl for device
I'm having the same error with ubuntu/xenial64
and Vagrant 1.8.7
.
==> default: mesg: ttyname failed: Inappropriate ioctl for device
I'm having the same error with ubuntu/xenial64 and Vagrant 1.9.0.
==> default: mesg: ttyname failed: Inappropriate ioctl for device
Same for me with Vagrant 1.9.0 provisioning Ubuntu Zesty Zapus from:
config.vm.box = "ubuntu/zesty64"
==> default: Running provisioner: shell...
default: Running: inline script
==> default: mesg: ttyname failed: Inappropriate ioctl for device
SOLVED: Upgrading to Vagrant 1.9.1 (from Hashicorp's site; aptitude installs 1.8.1 by default) fixed my issue.
Original Text
Same issue for me too on Vagrant 1.8.1 / Ubuntu 16.04. Link to my vagrantfile. Output of vagrant up
:
==> stompbox: Setting hostname...
==> stompbox: 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:
mesg: ttyname failed: Inappropriate ioctl for device
I'm seeing the following error when I try to run vagrant provision
using the puppetlabs ubuntu 16.04 box (https://atlas.hashicorp.com/puppetlabs/boxes/ubuntu-16.04-64-puppet/)
==> default: Running provisioner: puppet...
==> default: Running Puppet with init.pp...
==> default: mesg:
==> default: ttyname failed
==> default: :
==> default: Inappropriate ioctl for device
==> default: Error: Could not parse application options: invalid option: --manifestdir
I am using Vagrant 1.9.1 (downloaded from vagrantup.com) on an Ubuntu 16.04 host.
Ah nevermind - I see that it is a separate issue: #5615
@Jsgoller1 solution (upgrade to vagrant 1.9.1 from official site) solved my issue
Original problem:
==> 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:
Same issue with boxcutter/ubuntu1604
, Vagrant 1.9.1 does not solve the problem.
vagrant up
...
==> default: Running provisioner: shell...
default: Running: /var/folders/nj/fmxrcw_x4qd_16y0m69gyl8hp5tlq1/T/vagrant-shell20170102-64311-11944tx.sh
==> default: mesg: ttyname failed:
==> default: Inappropriate ioctl for device
@khromov Are you trying to read something from stdin? Because that is not possible.
after update to 1.9.1 still getting issue with
config.vm.box = "ubuntu/xenial64"
==> default: Running provisioner: shell...
default: Running: inline script
==> default: mesg: ttyname failed: Inappropriate ioctl for device
Updating from 1.8.3 to 1.9.3 resolved the issue for me.
I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
@sethvargo this still seems to be a problem, can we please get this issue re-opened?