Bug 201904 - vagrant image fails to specify mac address
Summary: vagrant image fails to specify mac address
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-virtualization (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-26 22:44 UTC by Steve Wills
Modified: 2024-01-05 03:44 UTC (History)
15 users (show)

See Also:


Attachments
patch to fix vagrant issue (1.56 KB, patch)
2016-09-22 17:51 UTC, Steve Wills
no flags Details | Diff
second patch to fix vagrant issue (1.59 KB, patch)
2016-09-22 18:11 UTC, Steve Wills
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Wills freebsd_committer freebsd_triage 2015-07-26 22:44:13 UTC
Using the vagrant image produces an error and vagrant up has to be run again:

% mkdir freebsdvagrant
% cd freebsdvagrant 
% vagrant init freebsd/FreeBSD-10.2-RC1
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.
% ls
Vagrantfile
% vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'freebsd/FreeBSD-10.2-RC1' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'freebsd/FreeBSD-10.2-RC1'
    default: URL: https://atlas.hashicorp.com/freebsd/FreeBSD-10.2-RC1
==> default: Adding box 'freebsd/FreeBSD-10.2-RC1' (v2015.07.24) for provider: virtualbox
    default: Downloading: https://atlas.hashicorp.com/freebsd/boxes/FreeBSD-10.2-RC1/versions/2015.07.24/providers/virtualbox.box
==> default: Successfully added box 'freebsd/FreeBSD-10.2-RC1' (v2015.07.24) for 'virtualbox'!
==> default: Importing base box 'freebsd/FreeBSD-10.2-RC1'...
No base MAC address was specified. This is required for the NAT networking
to work properly (and hence port forwarding, SSH, etc.). Specifying this
MAC address is typically up to the box and box maintainer. Please contact
the relevant person to solve this issue.

I initially thought this was a fatal error, but simply running vagrant up again produced a working VM that I could ssh to.
Comment 1 Steve Wills freebsd_committer freebsd_triage 2015-07-26 22:50:07 UTC
Later, vagrant up reports:

The configured shell (config.ssh.shell) is invalid and unable
to properly execute commands. The most common cause for this is
using a shell that is unavailable on the system. Please verify
you're using the full path to the shell and that the shell is
executable by the SSH user.

but I'm able to vagrant ssh fine.
Comment 2 Glen Barber freebsd_committer freebsd_triage 2015-07-26 22:50:48 UTC
This is not a blocker for 10.2, regardless, but a subsequent invocation of 'vagrant up' will allow the VM to start.
Comment 3 Christian Brueffer freebsd_committer freebsd_triage 2015-10-29 09:58:40 UTC
This is still a problem which may cause people to think the image is broken, without even trying a subsequent vagrant up and vagrant ssh.  I certainly didn't try it before reading this PR :-)
Comment 4 Toni Viemerö 2016-04-04 10:33:47 UTC
Still a problem with 10.3-RELEASE
Comment 5 Andres Montalban 2016-06-03 20:31:21 UTC
+1

Andres-MacBook-Pro:freebsd-10.1 andres$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'freebsd/FreeBSD-10.2-RELEASE'...
No base MAC address was specified. This is required for the NAT networking
to work properly (and hence port forwarding, SSH, etc.). Specifying this
MAC address is typically up to the box and box maintainer. Please contact
the relevant person to solve this issue.
Comment 6 Lionel Félicité 2016-08-10 23:29:27 UTC
still non working with https://atlas.hashicorp.com/freebsd/boxes/FreeBSD-10.3-STABLE

* Is someone working on this issue?
* How is the vagrant box generated: manually? via packer? etc. If it's via packer, is the receipe available? maybe we can help.

Thanks for your works!
Comment 7 Pierre Tardy 2016-09-07 11:23:56 UTC
a google thread shows this which explain how to use those boxes:

https://forums.freebsd.org/threads/52717/


  config.vm.base_mac = "080027D14C66"

seems to be mandatory for those boxes


Vagrant.configure("2") do |config|
  config.vm.guest = :freebsd
  config.vm.synced_folder ".", "/vagrant", id: "vagrant-root", disabled: true
  config.vm.box = "freebsd/FreeBSD-11.0-CURRENT"
  config.ssh.shell = "sh"
  config.vm.base_mac = "080027D14C66"

  config.vm.provider :virtualbox do |vb|
    vb.customize ["modifyvm", :id, "--memory", "1024"]
    vb.customize ["modifyvm", :id, "--cpus", "1"]
    vb.customize ["modifyvm", :id, "--hwvirtex", "on"]
    vb.customize ["modifyvm", :id, "--audio", "none"]
    vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
    vb.customize ["modifyvm", :id, "--nictype2", "virtio"]
  end
end

Another box is available here which is working better than the official ones:
https://github.com/wunki/vagrant-freebsd
Comment 8 Steve Wills freebsd_committer freebsd_triage 2016-09-22 17:51:57 UTC
Created attachment 175071 [details]
patch to fix vagrant issue

Attached patch fixes the issue and an additional one with the shell config. There's still an additional issue with shared folders that requires this:

    config.vm.synced_folder ".", "/vagrant", disabled: true

or this:

    config.vm.synced_folder ".", "/vagrant", type: "rsync"

but so far I haven't had luck testing that in the Vagrantfile with the box, only in the users Vagrantfile.
Comment 9 Steve Wills freebsd_committer freebsd_triage 2016-09-22 18:11:07 UTC
Created attachment 175072 [details]
second patch to fix vagrant issue

Oops, missed a line in the Vagrantfile.
Comment 10 Luca Lesinigo 2016-12-04 12:41:44 UTC
I can confirm that these images do not work out of the box with Vagrant 1.9.0 and VirtualBox 5.0.30 on macOS 10.12.1:
freebsd/FreeBSD-11.0-RELEASE-p1 (virtualbox, 2016.09.29)
freebsd/FreeBSD-11.0-STABLE     (virtualbox, 2016.11.30)

I can also confirm that adding these lines to the Vagrantfile is sufficient to make them run:
  config.vm.base_mac = "080027D14C66"
  config.vm.guest = :freebsd
  config.vm.synced_folder ".", "/vagrant", disabled: true
  config.ssh.shell = "sh"
Comment 11 n4jm4 2017-09-30 17:15:52 UTC
As Menchaca points out in the Vagrant Google Group, the FreeBSD Vagrant box currently requires several elements to be explicitly configured before it can successfully boot.

https://groups.google.com/d/msg/vagrant-up/dNnloUOVCI4/YEeCc7UbAwAJ

Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.box = "freebsd/FreeBSD-11.1-STABLE"

  config.vm.guest = :freebsd
  config.vm.synced_folder ".", "/vagrant", id: "vagrant-root", disabled: true
  config.ssh.shell = "sh"
  config.vm.base_mac = "080027D14C66"

  config.vm.provider :virtualbox do |vb|
   vb.customize ["modifyvm", :id, "--memory", "1024"]
   vb.customize ["modifyvm", :id, "--cpus", "1"]
   vb.customize ["modifyvm", :id, "--hwvirtex", "on"]
   vb.customize ["modifyvm", :id, "--audio", "none"]
   vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
   vb.customize ["modifyvm", :id, "--nictype2", "virtio"]
  end
end

Could the base image be modified to set these values, so that FreeBSD works "out of the box" with no custom configuration, for ease of access?
Comment 12 Jose Luis Duran freebsd_committer freebsd_triage 2018-02-09 14:20:08 UTC
The image is missing a `Vagrantfile` file in the `virtualbox` directory with the following contents:

    Vagrant::Config.run do |config|
      # This Vagrantfile is auto-generated by `vagrant package` to contain
      # the MAC address of the box. Custom configuration should be placed in
      # the actual `Vagrantfile` in this box.
      config.vm.base_mac = "080027D14C66"
    end

    # Load include vagrant file if it exists after the auto-generated
    # so it can override any of the settings
    include_vagrantfile = File.expand_path("../include/_Vagrantfile", __FILE__)
    load include_vagrantfile if File.exist?(include_vagrantfile)

This file specifies the "missing" MAC address.

Regarding the invalid `config.ssh.shell`, the image is missing the `shells/bash` package.  Vagrant's documentation states: "By default this is `bash -l`."
Comment 13 Joshua Kugler 2018-07-31 01:02:53 UTC
This is an issue for me as well, with no suitable work around. It seems there are certain Vagrant parameters which Chef's Kitchen does not pass through. So, even if I do this:

driver:
  base_mac: '020027D14C66'

It is not added to the Vagrantfile generated by Kitchen.

And running `kitchen create <my_freebsd_box> three times isn't really a usable solution for my users.

The FreeBSD box from Bento (bento/freebsd-11.2) works fine. Their Vagrantfile looks like this:

```
# The contents below were provided by the Packer Vagrant post-processor

Vagrant.configure("2") do |config|
  config.vm.base_mac = "080027B056FB"
end


# The contents below (if any) are custom contents provided by the
# Packer template during image build.
Vagrant.require_version ">= 1.1.0"

Vagrant.configure(2) do |config|
  config.ssh.shell = "sh"

  # Disable the base shared folder, Guest Tools supporting this feature are
  # unavailable for all providers.
  config.vm.synced_folder ".", "/vagrant", disabled: true

  config.vm.provider :parallels do |prl, override|
    # Guest Tools are unavailable.
    prl.check_guest_tools = false
    prl.functional_psf    = false
  end
end
```
Comment 14 John-Mark Gurney freebsd_committer freebsd_triage 2018-08-02 04:09:01 UTC
Hard coding the mac address is not at all portable.  Either that mac address should be assigned by Vagrant, or there is a fixed MAC address that vagrant always uses, but using some random company's mac address that might cause problems in the world is not a good idea.

Someone from Vagrant should be able to solve this.

There looks like there might be a mac address of auto that might work:
https://github.com/Parallels/vagrant-parallels/commit/2922ea4fe44e19b97bedc2f8ef2b3f2ec15834dd

Also, https://www.vagrantup.com/docs/boxes/base.html doesn't provide guidance on this topic.
Comment 15 Jose Luis Duran freebsd_committer freebsd_triage 2018-08-03 04:01:03 UTC
(In reply to John-Mark Gurney from comment #14)

Also, for reference, this issue:

https://github.com/hashicorp/vagrant/issues/10080
Comment 16 Glen Barber freebsd_committer freebsd_triage 2018-08-03 05:33:48 UTC
(In reply to Jose Luis Duran from comment #15)
> (In reply to John-Mark Gurney from comment #14)
> 
> Also, for reference, this issue:
> 
> https://github.com/hashicorp/vagrant/issues/10080

Finally, maybe Vagrant will fix their bug.
Comment 17 Glen Barber freebsd_committer freebsd_triage 2018-08-03 05:34:46 UTC
(In reply to Jose Luis Duran from comment #15)
> (In reply to John-Mark Gurney from comment #14)
> 
> Also, for reference, this issue:
> 
> https://github.com/hashicorp/vagrant/issues/10080

Finally, maybe Vagrant will fix their bug.
Comment 18 Jose Luis Duran freebsd_committer freebsd_triage 2018-10-22 16:21:11 UTC
(In reply to Glen Barber from comment #16)

This issue has been fixed in Vagrant 2.2:

https://github.com/hashicorp/vagrant/pull/10255
Comment 19 Glen Barber freebsd_committer freebsd_triage 2018-10-22 16:26:16 UTC
(In reply to Jose Luis Duran from comment #18)
> (In reply to Glen Barber from comment #16)
> 
> This issue has been fixed in Vagrant 2.2:
> 
> https://github.com/hashicorp/vagrant/pull/10255

Adding the sysutils/vagrant maintainer to the CC list.  I presume this PR can be closed after the port is updated to 2.2.
Comment 20 Christoph Moench-Tegeder freebsd_committer freebsd_triage 2018-11-01 20:42:26 UTC
(In reply to Glen Barber from comment #19)

Working on the vagrant update bug #232511

Actually, we have two issues here:
1. not having a MAC address: this is fixed in https://github.com/hashicorp/vagrant/pull/10255 and vagrant 2.2 (to land in the next few minutes)

2. vagrant expects bash and sudo to be installed inside the box and tries to execute e.g. the "provision" commands via bash/sudo.
   -> https://www.vagrantup.com/docs/vagrantfile/ssh_settings.html
   Example: I add a simple provision command to the Vagrant file, e.g.
     config.vm.provision "shell", inline: "echo WAT"
   and this fails:
   $ vagrant provision
   ==> default: Running provisioner: shell...
       default: Running: inline script
   The SSH command responded with a non-zero exit status. Vagrant
   assumes that this means the command failed. The output for this command
   should be in the log above. Please read the output to determine what
   went wrong.

   Only when being creative like
     config.ssh.shell = "/bin/sh"
     config.ssh.sudo_command = "%c"
     config.vm.provision "shell", inline: "echo WAT"
   I get some output:
   $ vagrant provision
   ==> default: Running provisioner: shell...
       default: Running: inline script
       default: WAT

   But obviously, that way I cannot easily execute commands as root.
Comment 21 Steve Wills freebsd_committer freebsd_triage 2018-11-02 16:23:17 UTC
(In reply to Christoph Moench-Tegeder from comment #20)
That's why the Vagrantfile I supplied in a patch (attached to this bug) over two years ago has these lines:

  config.ssh.shell = "sh"
  config.vm.guest = :freebsd
Comment 22 Mark Linimon freebsd_committer freebsd_triage 2024-01-05 03:44:49 UTC
^Triage: commit bit was taken in for safekeeping.