Xenial vagrant image is missing its hostname in /etc/hosts

[LoOoD]

The vagrant build for xenial is missing an in /etc/hosts. This generates an error when running sudo.

ubuntu@ubuntu-xenial:~$ cat /etc/hosts
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
ubuntu@ubuntu-xenial:~$ sudo echo see the error ^^^^
sudo: unable to resolve host ubuntu-xenial
see the error ^^^^
ubuntu@ubuntu-xenial:~$

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1561250/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Leo Tindle (leonexis)]

Adding the following line to /etc/hosts will work around this issue:

127.0.1.1 ubuntu-xenial

According to Ubuntu's profile on https://atlas.hashicorp.com/ubuntu/, bugs should be filed on the cloud-images project (https://bugs.launchpad.net/cloud-images).

[Mostafa Razavi (elektito)]

Unfortunately the above-mentioned fix is not possible when your Vagrantfile contains extra network configuration. In those cases, you get something like this before you get a chance to update the hosts file:

    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

This renders the image useless to many who want to use it with a non-trivial Vagrantfile.

[Bryan Wyatt (brwyatt)]

This also prevents changing the box's hostname, as the command `sudo hostname -f` not only gets the sudo warning on stdout as mentioned above, but the `hostname -f` also fails with a non-zero exit code since resolution fails.

[Adam Chou (adam-chou)]

Just to expand on this, this issue is also present in the latest Xenial AWS AMI, with ID ami-64140d0e. This makes running Xenial on AWS difficult, to say the least.

[Nayeem Syed (developerinlondon)]

is there any fixes to this? If we can look at the code that creates the vagrant-image I am happy to try to find a fix for it?

[Chris Pick (cpick)]

@Nayeem I *believe* the image building process is described here:
https://help.ubuntu.com/community/UEC/Images#Building_Your_Own_Ubuntu_Cloud_Guest_images

[GGeorg (georg-ubuntu-com)]

as far as i could see the problem is within the package live-build which is used to build the cloud-images

There is a hook for vagrant. i assume this is rather bogus, the hostname should not be something that changes per relesase, its better to have some solid default like "localhost" that is resolveable using /etc/hosts without any additional component. This will fix the issue for vagrant cloud images without breaking other images.

[GGeorg (georg-ubuntu-com)]

Root Cause:

Setting the hostname to "ubuntu-${release}" in cloud-images causes the hostname not to be resolvable using /etc/hosts. Running hostname -f will fail due to unresolveable default hostname causing a failure when setting up the proper hostname by vagrant.

Suggested Fix:

Set the hostname to "localhost"

How to reproduce (Option 1):

1.) Install Oracle Virtualbox
2.) Install Vagrant
3.) Create a empty directory and download attached VagrantFile
4.) Run "vagrant up"

Error:

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

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "live-build.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[LoOoD (gman)]

How were precise and trusty images built? They worked fine.

[christophe (christophe-bornet)]

On trusty, the hostname was not in /etc/hosts and it was working fine. The real issue here is that sudo looks into DNS before hostname.

In /etc/nsswitch.conf, we had on trusty:
hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns

We now have:
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname

[christophe (christophe-bornet)]

Actually, we now have:
hosts: files mdns4_minimal [NOTFOUND=return] dns
since libnss-myhostname is not installed

[Bob Tanner (tanner)]

Still see the problems with 'ubuntu/xenial64' (v20160527.0.0)

Switching from the user vagrant and ssh key authentication to user ubuntu and password authentication lets things progress a little further but run into hostname problem.

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

Which looks like this is tracked in:

https://bugs.launchpad.net/cloud-images/+bug/1565985

[Dan Watkins (oddbloke)]

So I have just looked in to this, and I can't reproduce it. I did the following:

$ vagrant --version
Vagrant 1.8.1
$ vagrant init ubuntu/xenial64
<snip>
$ vagrant up
<snip>
$ vagrant ssh -- sudo grep hosts /etc/nsswitch.conf
hosts: files dns

(I've also done some interactive sudo'ing in there, and I haven't seen any issues)

I've done this with both the default hostname, and setting a hostname in the Vagrantfile.

If someone can provide full reproduction steps, I'd be more than happy to reopen this and address it, but as of now I can't find a bug to fix. :)

[Toni Viemerö (todeveni-deactivatedaccount)]

Host: OS X 10.11.5, VirtualBox 5.0.20

⇒ vagrant --version
Vagrant 1.8.1
⇒ vagrant init ubuntu/xenial64
<snip>
⇒ vagrant box list|grep xenial
ubuntu/xenial64 (virtualbox, 20160531.0.0)
⇒ vagrant up
<snip>
⇒ vagrant ssh -- sudo grep hosts /etc/nsswitch.conf
sudo: unable to resolve host ubuntu-xenial
hosts: files dns

[Dan Watkins (oddbloke)]

Hmm, thanks for that, Toni.

I'm on Virtualbox 5.0.18, so I'm building 5.0.20 to test that version on my machine.

[Chris Pick (cpick)]

To confirm Toni's comment, my testing yields the same result:

$ vboxmanage --version
5.0.20r106931

$ vagrant --version
Vagrant 1.8.1

$ vagrant box list | grep xenial
ubuntu/xenial64 (virtualbox, 20160531.0.0)

$ vagrant init ubuntu/xenial64
$ vagrant up

$ vagrant ssh -- sudo grep hosts /etc/nsswitch.conf
sudo: unable to resolve host ubuntu-xenial
hosts: files dns

[Chris Pick (cpick)]

Dan if it helps reproduce:
I'm running a 64bit trusty host using the "virtualbox-5.0" package from the "deb http://download.virtualbox.org/virtualbox/debian trusty contrib" repository.

[Bob Tanner (tanner)]

I'll be surprised if the problem is in the Virtualbox 5.0.20, what is the xenial image you are testing against Dan? Your vagrant box list | grep xenial?

I had the same problem with 5.0.18, but no longer have it installed.

[Dan Watkins (oddbloke)]

$ vagrant box list | grep xenial
Odd_Bloke/xenial64 (virtualbox, 20160319.0.0)
ubuntu/xenial64 (virtualbox, 20160319.0.0)
ubuntu/xenial64 (virtualbox, 20160418.0.0)
ubuntu/xenial64 (virtualbox, 20160420.3.0)
ubuntu/xenial64 (virtualbox, 20160521.0.0)
ubuntu/xenial64 (virtualbox, 20160531.0.0)
xenial-release (virtualbox, 0)
xenial64 (virtualbox, 0)

So... I'm very confused as to why I'm not seeing this. :)

[Dan Watkins (oddbloke)]

(I have tested 5.0.20; I still can't reproduce)

[LoOoD (gman)]

$ : vboxmanage --version
5.0.20r106931

$ : vagrant --version
Vagrant 1.8.0

$ : vagrant box list |grep -i xenial

$ : vagrant init ubuntu/xenial64
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

$ : vagrant plugin list
vagrant-share (1.1.5, system)

$ : vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'ubuntu/xenial64' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'ubuntu/xenial64'
    default: URL: https://atlas.hashicorp.com/ubuntu/xenial64
==> default: Adding box 'ubuntu/xenial64' (v20160531.0.0) for provider: virtualbox
    default: Downloading: https://atlas.hashicorp.com/ubuntu/boxes/xenial64/versions/20160531.0.0/providers/virtualbox.box
==> default: Successfully added box 'ubuntu/xenial64' (v20160531.0.0) for 'virtualbox'!
==> default: Importing base box 'ubuntu/xenial64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/xenial64' is up to date...
==> default: Setting the name of the VM: ubuntu-xenial-16.04-cloudimg
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: ubuntu
    default: SSH auth method: password
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...

$ : vagrant ssh -- sudo grep hosts /etc/nsswitch.conf
sudo: unable to resolve host ubuntu-xenial
hosts: files dns

$ : vagrant ssh -- sudo grep ubuntu /etc/hosts
sudo: unable to resolve host ubuntu-xenial

$ : vagrant ssh -- sudo grep 127 /etc/hosts
sudo: unable to resolve host ubuntu-xenial
127.0.0.1 localhost

[LoOoD (gman)]

Dan, could you also run these commands?? And purge all your boxes before "vagrant up"?

vagrant ssh -- sudo grep ubuntu /etc/hosts
vagrant ssh -- sudo grep 127 /etc/hosts

[Bob Tanner (tanner)]

host: OS X 10.11.5

$ vboxmanage --version
5.0.20r106931

$ vagrant --version
Vagrant 1.8.1

$ vagrant init ubuntu/xenial64
<snip>

$ vagrant box list|grep xenial
ubuntu/xenial64 (virtualbox, 20160531.0.0)

$ vagrant up
<snip>

$ vagrant ssh -- sudo grep hosts /etc/nsswitch.conf
sudo: unable to resolve host ubuntu-xenial
hosts: files dns

$ vagrant ssh -- sudo grep ubuntu /etc/hosts
sudo: unable to resolve host ubuntu-xenial

$ vagrant ssh -- sudo grep 127 /etc/hosts
sudo: unable to resolve host ubuntu-xenial
127.0.0.1 localhost

$ cat /etc/hosts
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

[Garrick P. (gpeterson-j)]

Also seeing this:

$ vboxmanage --version
5.0.10r104061

$ vagrant --version
Vagrant 1.8.1

$ vagrant box list |grep -i xenial
ubuntu/xenial64 (virtualbox, 20160420.3.0)
ubuntu/xenial64 (virtualbox, 20160509.0.0)
ubuntu/xenial64 (virtualbox, 20160531.0.0)

$ vagrant init ubuntu/xenial64
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'ubuntu/xenial64' is up to date...
==> default: Setting the name of the VM: ubuntu-xenial-16.04-cloudimg
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2200 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2200
    default: SSH username: ubuntu
    default: SSH auth method: password
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Authentication failure. Retrying...
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...

$ vagrant ssh -- sudo grep hosts /etc/nsswitch.conf
sudo: unable to resolve host ubuntu-xenial
hosts: files dns

$ vagrant ssh -- sudo grep ubuntu /etc/hosts
sudo: unable to resolve host ubuntu-xenial

$ vagrant ssh -- sudo grep 127 /etc/hosts
sudo: unable to resolve host ubuntu-xenial
127.0.0.1 localhost

[Chris Pick (cpick)]

Dan, is it possible that there's a resolver on your machine/network that is resolving that hostname for you?

[LoOoD (gman)]

Can we unmark this as "Incomplete"?

[Dan Watkins (oddbloke)]

It turns out that it _isn't_ resolving, which my ISP then redirects to a portal to try and get advertising clicks. Thanks, BT.

[Robert Hafner (tedivm)]

Can confirm I am also running into this. It's preventing vagrant configurations that involve private networking from loading as this error stops the provisioning process- basically making it impossible to use these images for testing certain (fairly common) scenarios using vagrant.

If there's a reason to keep the hostname out of /etc/hosts then disabling DNS in sudo and ssh should resolve some of the issues.

[Keilo (keilo)]

I am able to reproduce this as well.

Example:

-------------------------------------------------------------------
$ vagrant --version
Vagrant 1.8.3

$ vboxmanage --version
5.0.20r106931

$ vagrant init ubuntu/xenial64

$ vagrant box list | grep xenial
ubuntu/xenial64 (virtualbox, 20160610.0.0)

$ vagrant up

$ vagrant ssh

ubuntu@ubuntu-xenial:~$ sudo cat /etc/hosts
sudo: unable to resolve host ubuntu-xenial
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
-------------------------------------------------------------------

In the above command line log you can see "sudo: unable to resolve host ubuntu-xenial".
The error makes it difficult to automatically configure the vm because commands return non zero exit status due to this error.

[Pri Vate (pri-v-ate)]

==> default: Box 'ubuntu/xenial64' (v20160615.1.0) is running the latest version.

vagrant --version
Vagrant 1.8.1

vboxmanage --version
5.0.20r106931

(Host OS)
uname -a
15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu 3248.50.21~8/RELEASE_X86_64 x86_64

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

[Pri Vate (pri-v-ate)]

The problem went away after upgrading to the following versions.

vagrant --version
Vagrant 1.8.4
vboxmanage --version
5.0.22r108108

[Keilo (keilo)]

I can confirm this issue is also present when running on macOS.

-------------------------------------------------------------------------------------
$ uname -a
Darwin 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64

$ vagrant --version
Vagrant 1.8.4

$ vboxmanage --version
5.0.22r108108

$ vagrant box list | grep xenial
ubuntu/xenial64 (virtualbox, 20160615.1.0)

$ vagrant init ubuntu/xenial64

$ vagrant ssh

$ sudo cat /etc/hosts
sudo: unable to resolve host ubuntu-xenial
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
-------------------------------------------------------------------------------------

Note the "sudo: unable to resolve host ubuntu-xenial" above.

[Bob Tanner (tanner)]

Is there a HOWTO or link for how to build the xenial image?

Might be easier for us to help troubleshoot the problem if we could build the xenial image, fix what's wrong, and submit the patches back?

[Robert Hafner (tedivm)]

There is a really amazingly simple work around to this problem that works without needing a custom box.

In your VagrantFile use the config.vm.hostname option to specify a hostname-

config.vm.hostname = "vagrant"

That will change the hostname before the networking and provisioning steps occur (I'm not sure how, but I did confirm this was true) and allow you to set the custom options you'd like.

[Bob Tanner (tanner)]

> On Jun 19, 2016, at 7:51 PM, Robert Hafner <email address hidden> wrote:
>
> In your VagrantFile use the config.vm.hostname option to specify a
> hostname-
>
> config.vm.hostname = "vagrant"

Still get the error.

  config.vm.define "testing_xenial64" do |testing_xenial64|
    testing_xenial64.vm.box = "ubuntu/xenial64"
    config.vm.network "public_network", bridge: "en0: Wi-Fi (AirPort)", auto_config: true
    config.vm.hostname = “ubuntu-xenial"

$ vagrant up --provision testing_xenial64
<snip>

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: Name or service not known

--
Bob Tanner <email address hidden> | Phone : [phone]
http://www.real-time.com, Linux, OSX, VMware, Windows | Fax : [phone]
Key fingerprint = 9906 320A 8BB6 64AD 96A7 7785 CBFB 10BF 568B F98C

[j bennett (jkbe)]

Based on #13 and related comments, I noticed that on my AWS account I wasn't getting a Public DNS assigned each time I launched ami-08490c68.

Found this link to resolve that by adding a Virtual Private Cloud (VPC) per this link:

http://stackoverflow.com/questions/20941704/ec2-instance-has-no-public-dns

Adding the VPC seemed to have fixed the Public DNS issue and the "unable to resolve host" issue on my running instance and a new one as the Public DNS is showing up now.

Not a fix, but seems like it is a work around for my AWS based stuff and clarified a bit some of the other comments on this thread above for me.

[Bob Tanner (tanner)]

Any status update?

'ubuntu/xenial64' (v20160627.0.0) for 'virtualbox' still has the problem.

Repeating my 06/19 post:

Is there a HOWTO or link for how to build the xenial image?

Might be easier for us to help troubleshoot the problem if we could build the xenial image, fix what's wrong, and submit the patches back?

[Robert Hafner (tedivm)]

This bug- which literally just required a line in the hosts file- is still not resolved months later. Does the cloud team just not want people to upgrade to the latest LTS version? I can't imagine any other reason to ignore this issue, especially considering it's easy fix.

[Dan Watkins (oddbloke)]

Hello all,

The Vagrant boxes are important to us, and we do want them to be a high-quality Ubuntu experience. That said, our limited resources have been focussed on improving that experience in the images which people use in production. We would like to have the time to work on everything that needs attention but, regrettably, that isn't the situation we're in.

Louis Zuckerman has very kindly taken the time to work out how the images are built, and contributed a patch which may address this; I've built a (yakkety) box from his changes at http://people.canonical.com/~dwatkins/livecd.ubuntu-cpc.vagrant.box; please test it and let me know if it resolves this issue.

Thanks,

Dan

[LoOoD (gman)]

Dan, will you be building an updated xenial image from the contributed patch or will only releases greater then 16.04 only have the fix?

[Robert Hafner (tedivm)]

Presumably they'll stick to the "S" in LTS and backport this change, but I can understand their desire to test it quickly before diving in.

I also understand limited resources. However, I think a reprioritization is in order here. This bug was not a difficult or time consuming one to solve. Further, in order for people to use Ubuntu in production environments they have to use them in test environments. Vagrant allows us to do this easily, and for people developing software or looking at upgrading infrastructure and looking to test compatibility it's really nice to have a quick to use (and free) server that we can test on. This bug has actually stopped my company from upgrading our main infrastructure to the latest LTS because of our use of vagrant for testing and development.

[GGeorg (georg-ubuntu-com)]

Hi,

in case you are stuck, here is my workaround that should bring back most of the default features.

To be fair, this could also be fixed very easy by a way simpler approach using cloud-inits user-data feature within vagrant. All it would need is this line in the box user-data image in ubuntu-xenial-16.04-cloudimg-configdrive.vmdk so in case you want to repackage the box, go that way and add:

manage_etc_hosts: localhost

In the ubuntu-xenial-16.04-cloudimg-configdrive.vmdk user-data File
I cloud not find the code that creates ubuntu-xenial-16.04-cloudimg-configdrive.vmdk on cloud-images.ubuntu.com, anyone that could help so we can submit a patch to that tool ?

[Dan Watkins (oddbloke)]

This change will be backported to xenial, but only once we've heard that we've actually fixed it.

Robert, GGeorg, LoOoD, does the box I provided fix the issue?

(Also, Robert, I really do understand the frustration but this wasn't actually as simple a fix as you seem to think; Vagrant boxes should have their hostname set dynamically at boot, which means you can't simply write out the hostname to /etc/hosts during the image build process. And when you add in to this the fact that a lot of behaviour that is clearly expected of Vagrant boxes isn't actually documented anywhere[0], any fix becomes time-consuming as you have to try and work out what the expected behaviour is by looking at other Vagrant boxes.)

[0] Search for "host" in https://www.vagrantup.com/docs/boxes/base.html

[GGeorg (georg-ubuntu-com)]

Hi Dan,

could you provide the patch so we could review it ? The box file you provided is in no way compareable to cloud-images.

The box file is about twice the size - so it was built in another way.

I think the only proper way to fix this (no change in filesystem or installed packets) is changing the config drive user-data .. which should be not hard to implement and is isolated to vagrant only cloud-image ..

Could you relay us the process Louis Zuckerman layed out - so we could provide a patch ? I was unable to find the script that creates the cloud-images on cloud-images.ubuntu.com

regards
Georg

[Dan Watkins (oddbloke)]

Hi Georg,

On 06/07/16 09:55, GGeorg wrote:
> could you provide the patch so we could review it ? The box file you
> provided is in no way compareable to cloud-images.

The box file I provided is what we expect to become the cloud image; it
is directly comparable. :)

> The box file is about twice the size - so it was built in another way.

It wasn't built another way, but it was built to contain more useful
packages.

> I think the only proper way to fix this (no change in filesystem or
> installed packets) is changing the config drive user-data .. which
> should be not hard to implement and is isolated to vagrant only cloud-
> image ..

We're happy to make Vagrant-specific changes to the Vagrant image, so we
can change this in the filesystem.

> Could you relay us the process Louis Zuckerman layed out - so we could
> provide a patch ? I was unable to find the script that creates the
> cloud-images on cloud-images.ubuntu.com

You can find the changes Louis has proposed at [0], which also includes
how he tested his changes. (The images on cloud-images.ubuntu.com are
produced using Launchpad's buildds; all of the software that is used is
open-source, but for security reasons access to the build farm is
restricted to Canonical employees; the image provided above was built
using the buildds.)

[0]
https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305

[GGeorg (georg-ubuntu-com)]

@Dan: Thx for your feedback i checked the diff at: https://i267500511.restricted.launchpadlibrarian.net/267500511/3d1e0c04-3a0e-11e6-bd2f-002481e91f22.txt?token=4gc9PKPGwls2N9trTB0D26bj1nLqDrbv

Absolutly see your point in the buildds infrastructure :)

Here is my feedback:

* libnss-myhostname will fix _this_ problem but might break things for other users, i would not recommend going this route as it changes an already released package list and image. Bad for LTS i would suggest to use the existing and already proven cloud-init way to handle /etc/hosts like mentioned above - this has been proven to work for aws and other cloud providers.

* If the future image has 557 MB vs 282 MB at the current - than please dont fix it :) seriously if a box update takes twice the time it took before the change, the change is broken. Changeing all this for a LTS breaks the idea of having lts.

cloud-images - in my point of view - should contain only the bare minimum, if the user wants additional software there are multiple ways to do so in vagrant or to provide meta-data with cloud-init. Lets yust see what hashicorp tells us todo:

https://www.vagrantup.com/docs/boxes/base.html

There are a special category of boxes known as "base boxes." These boxes contain the bare minimum required for Vagrant to function, are generally not made by repackaging an existing Vagrant environment (hence the "base" in the "base box").

adding: virtualbox-guest-dkms and virtualbox-guest-utils
       makes sense even so its not needed (user can install it with provisioner and add the mount point)
adding:
       linux-headers-generic
       nfs-common
       python-apport
       puppet
       chef
       byobu
       juju
       ruby

will break stuff and is not needed - because were to stop ? next person will request cfengine to be included ?! IMHO not a good idea - but yust my 2 cents ..

[Dan Watkins (oddbloke)]

On 06/07/16 11:32, GGeorg wrote:
> * libnss-myhostname will fix _this_ problem but might break things for
> other users, i would not recommend going this route as it changes an
> already released package list and image. Bad for LTS i would suggest to
> use the existing and already proven cloud-init way to handle /etc/hosts
> like mentioned above - this has been proven to work for aws and other
> cloud providers.

Ah, this is a good point, I'll comment on the MP as such.

> * If the future image has 557 MB vs 282 MB at the current - than please
> dont fix it :) seriously if a box update takes twice the time it took
> before the change, the change is broken. Changeing all this for a LTS
> breaks the idea of having lts.

So I don't disagree in general with this sentiment about LTS releases.
That said, this could all be considered regression from pre-xenial
Vagrant boxes, so we are fixing bugs in the released version.

> adding: virtualbox-guest-dkms and virtualbox-guest-utils
> makes sense even so its not needed (user can install it with provisioner and add the mount point)
> adding:
> linux-headers-generic
> nfs-common
> python-apport
> puppet
> chef
> byobu
> juju
> ruby
>
> will break stuff and is not needed - because were to stop ? next person
> will request cfengine to be included ?! IMHO not a good idea - but yust
> my 2 cents ..

This list is what's in the trusty Vagrant box; have you ever noticed it
being a problem there? ;) That said, I was on the fence about this, so
we should probably consider the packages that should be added separately
to addressing the more fundamental issue.

[GGeorg (georg-ubuntu-com)]

@dan: agree with trusty release .. but i think that discussion should be on another changerequest :)

[Louis Zuckerman (semiosis)]

Here's the bug for discussing whether or not to include config management packages in the vagrant box:

https://bugs.launchpad.net/cloud-images/+bug/1599531

Please add your thoughts there if you have an opinion.

Thanks!

[Launchpad Janitor (janitor)]

This bug was fixed in the package livecd-rootfs - 2.421

---------------
livecd-rootfs (2.421) yakkety; urgency=medium

  [ Louis Zuckerman ]
  * Fixes for vagrant box builder in ubuntu-cpc LP: #1565985
    - Install virtualbox-guest-utils
    - Don't disable default synced folder
    - Don't set vm name
    - Add cloud-init config to manage /etc/hosts LP: #1561250

 -- Steve Langasek <email address hidden> Thu, 21 Jul 2016 09:14:50 -0700

[Keilo (keilo)]

Does not appear to be resolved in ubuntu/xenial64 20160721.0.0

[Louis Zuckerman (semiosis)]

This bug and LP: #1565985 are fixed in yakkety. I've opened an SRU to get the fixes into xenial (LP: #1605795). I hope to make progress on the SRU this week.

Thanks!

[christophe (christophe-bornet)]

About libnss-myhostname. This was how it was done in the trusty box. Not saying it should be done that way in xenial though...

[Devis (devis)]

FWIW this code in bootstrap.sh should help mitigating the issue:

if ! grep -q $(cat /etc/hostname) /etc/hosts; then
    echo >> /etc/hosts
    echo 127.0.0.1 $(cat /etc/hostname) >> /etc/hosts
fi

[Chris J Arges (arges)]

Hello LoOoD, or anyone else affected,

Accepted livecd-rootfs into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/livecd-rootfs/2.408.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Louis Zuckerman (semiosis)]

Fix confirmed.

Here's how I tested:

- Downloaded current xenial vagrant box and started a VM from it
- Enabled xenial-proposed repository
- Installed livecd-rootfs from -proposed, version 2.408.3
- ran the following commands...

sudo -i
mkdir /build
cd /build
cp -a /usr/share/livecd-rootfs/live-build/auto .
export SUITE=xenial
export ARCH=amd64
export PROJECT=ubuntu-cpc
export MIRROR=http://archive.ubuntu.com/ubuntu/
lb config
cd config/hooks
rm 031-root-xz.binary 033-disk-image-uefi.binary 034-disk-image-ppc64el.binary 040-qcow2-image.binary 040-vmdk-image.binary 041-vmdk-ova-image.binary 032-root-squashfs.binary
lb build

- Copied the created vagrant box from /build/livecd.ubuntu-cpc.vagrant.box to my host and launched a new VM from it
- Checked that new VM had randomized name and that default synced folder was mounted. Also checked that sudo did not complain about hostname resolution.

Looks good to me!

[Matt Willsher (mawi)]

The original message was received at 2016-08-31 19:11:25 +0000
                          from postoffice.local [10.0.0.1]

                          ----- The following addresses had permanent
fatal errors ----
                          <email address hidden>

                          -----Transcript of session follows -----
                          ... while talking to postoffice.local.:
                          >>> RCPT To:<email address hidden>
                          <<< 550 5.1.1 unknown or illegal alias:
<email address hidden>
                          550 <email address hidden>... User unknown

UmVwb3J0aW5nLU1UQTogZG5zOyBwb3N0b2ZmaWNlLmxvY2FsCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgUmVjZWl2ZWQtRnJvbS1NVEE6IEROUzsgcG9zdG9mZmljZS5sb2NhbAogICAgICAgICAg
ICAgICAgICAgICAgICAgIEFycml2YWwtRGF0ZTogMjAxNi0wOC0zMSAxOToxMToyNSArMDAwMAoK
ICAgICAgICAgICAgICAgICAgICAgICAgICBGaW5hbC1SZWNpcGllbnQ6IFJGQzgyMjsgMTU2MTI1
MEBidWdzLmxhdW5jaHBhZC5uZXQKICAgICAgICAgICAgICAgICAgICAgICAgICBBY3Rpb246IGZh
aWxlZAogICAgICAgICAgICAgICAgICAgICAgICAgIFN0YXR1czogNS4xLjEKICAgICAgICAgICAg
ICAgICAgICAgICAgICBSZW1vdGUtTVRBOiBETlM7IHBvc3RvZmZpY2UubG9jYWwKICAgICAgICAg
ICAgICAgICAgICAgICAgICBEaWFnbm9zdGljLUNvZGU6IFNNVFA7NTUwIDUuMS4xIHVua25vd24g
b3IgaWxsZWdhbCBhbGlhczogMTU2MTI1MEBidWdzLmxhdW5jaHBhZC5uZXQKICAgICAgICAgICAg
ICAgICAgICAgICAgICBMYXN0LUF0dGVtcHQtRGF0ZTogMjAxNi0wOC0zMSAxOToxMToyNSArMDAw
MAo=

[Launchpad Janitor (janitor)]

This bug was fixed in the package livecd-rootfs - 2.408.3

---------------
livecd-rootfs (2.408.3) xenial-proposed; urgency=medium

  [ Louis Zuckerman ]
  * Fixes for vagrant box builder in ubuntu-cpc LP: #1565985
    - Install virtualbox-guest-utils
    - Don't disable default synced folder
    - Don't set vm name
    - Add cloud-init config to manage /etc/hosts LP: #1561250

 -- Brian Murray <email address hidden> Tue, 30 Aug 2016 13:17:55 -0700

[Martin Pitt (pitti)]

The verification of the Stable Release Update for livecd-rootfs has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Louis Zuckerman (semiosis)]

The new daily xenial build for 20160907 includes the fix.

https://cloud-images.ubuntu.com/xenial/20160907/