lavabit/robox

The tools needed to robotically create/configure/provision a large number of operating systems, for a variety of hypervisors, using packer.

Roboxes

Generic base boxes, providing a variety of operating systems, and available across a number of different virtualized platforms.

Website

https://roboxes.org

Vagrant Boxes

https://app.vagrantup.com/generic
https://app.vagrantup.com/lavabit
https://app.vagrantup.com/lineage

Podman / Docker Images

https://hub.docker.com/u/roboxes/
https://hub.docker.com/u/lavabit/
or
https://quay.io/organization/roboxes
https://quay.io/organization/lavabit

Pending Additions/Updates

Add support for the new "architecture" flag. This means adding "386" or "amd64" as appropriate. And it means we need to add "arm64" boxes to the pipeline.

Upcoming Additions

Oct 23rd, 2023 / FreeBSD 14.0

* Repo updated. ** Beta/pre-prerelease added.

Pending Tasks

^{_{We would welcome community help (as a pull request) with any of the following tasks.}}
Generate docker variants for the Ubuntu/Debian/Alpine configurations
Incorporate the upload/delete/release scripts into the robox.sh script as functions.
Add vagrant user password randomization logic to the bundled Vagrantfiles.
Improve the unit box validation/check script with SSH command tests/checks. Start building ARM variants for some virtual machines/boxes.
^-- WE NEED A HARDWARE DONATION TO MAKE ARM64 IMAGES
THIS SHOULD, WE HOPE, IN THE WORKS --^

Operating System Requests

The following variants of existing builds have been requested, and will be added at a future date, when time allows (or someone submits a pull request).

Fedora Rawhide
OpenSUSE Tumbleweed

This operating system has been requested, but at present doesn't apppear to have sufficient interest. If that changes, it could be easily added by adapting the existing Debian/Ubuntu configurations.

Pop!_OS

The following operating systems have been requested by a member of the Robox community, but require a volunteer to generate a configuration, before they can be incorporated into the workflow.

Haiku
Minix
Parrot
SmartOS

Operating System Candidates

The following operating systems are potential candidates. They may be added in the future.

Manjaro
Mint
OpenSolaris
Slackware

MacOS
Darwin

ReactOS
Windows

Tails
Kali

Adding Boxes

Submit a pull request with your favorite distro.

Building a Box

To build a Robox locally, run the following:

git clone https://github.com/lavabit/robox && cd robox
./robox.sh box generic-BOX-PROVIDER

You will to replace the BOX and PROVIDER placeholders in the example above.

Replace BOX with one of the these values: [alma8|alma9|alpine35|alpine36|alpine37|alpine38|alpine39|alpine310|alpine311|alpine312|alpine313|alpine314|alpine315|alpine316|alpine317|arch|centos6|centos7|centos8|centos8s|centos9s|debian8|debian9|debian10|debian11|devuan1|devuan2|devuan3|devuan4|dragonflybsd5|dragonflybsd6|fedora25|fedora26|fedora27|fedora28|fedora29|fedora30|fedora31|fedora32|fedora33|fedora34|fedora35|fedora36|fedora37|freebsd11|freebsd12|freebsd13|gentoo|hardenedbsd11|hardenedbsd12|hardenedbsd13|netbsd8|netbsd9|openbsd6|openbsd7|opensuse15|opensuse42|oracle7|oracle8|oracle8|rhel6|rhel7|rhel8|rocky8|rocky9|ubuntu1604|ubuntu1610|ubuntu1704|ubuntu1710|ubuntu1804|ubuntu1810|ubuntu1904|ubuntu1910|ubuntu2004|ubuntu2010|ubuntu2104|ubuntu2110|ubuntu2204|ubuntu2210|ubuntu2304]

And replace PROVIDER with one of these values: [docker|hyperv|libvirt|parallels|virtualbox|vmware].

A configuration for all of the distros is available for every provider, EXCEPT Docker. At present we have only adapted a subset of the configurations to build Docker/Podman images.

The above presumes you already have packer and the hypervisor for the targeted provider installed. The res/providers/providers.sh script may provide guidance on the steps required to setup a Linux build host for VMWare/Virtualbox/Docker/libvirt. Please note that this scripts was written for RHEL/CentOS 7. You will then need to adapt the package names and CLI commands to your environment.

VirtualBox Disks

Enabling the discard/nonrotational options with our VirtualBox configs, appears to improve performance, but only on build robots equipped with SSDs or NVMe drives, and then only if the virtual machine is configured with VDI virtual disks. This combination allows guests to utilize discard/unmap/trim. However, if a virtual machine is deployed onto traditional magnetic hard disks with discard/nonrotational enabled, performance will drop significantly ( 1/50th of normal in some cases ).

Furthermore, while Packer appears to use VDI disk image files, when the virtual machine is exported and converted into a Vagrant box, the disk gets converted into the VMDK format. The discard/nonrotational options are preserved, and the result is that when the base box is deployed, it results in a virtual machine with the discard/nonrotational options enabled with an unsupported VMDK virtual disk.

As a result, we are currently not using the following options in our Packer config files.

"hard_drive_discard": true,
"hard_drive_nonrotational" : true,

A handful of relevant messages from VirtualBox when a Vagrant box is deployed with this issue.

File system of 'generic-debian8-virtualbox/generic-debian8-virtualbox_default_1649216430418_60259/generic-debian8-virtualbox-disk001.vmdk' is xfs
  Format              <string>  = "VMDK" (cb=5)
  Path                <string>  = "generic-debian8-virtualbox/generic-debian8-virtualbox_default_1649216430418_60259/generic-debian8-virtualbox-disk001.vmdk" (cb=154)
VMSetError: /home/vbox/vbox-5.2.44/src/VBox/Storage/VD.cpp(5662) int VDOpen(PVDISK, const char*, const char*, unsigned int, PVDINTERFACE); rc=VERR_VD_DISCARD_NOT_SUPPORTED
MSetError: VD: Backend 'VMDK' does not support discard
AIOMgr: Endpoint for file 'generic-debian8-virtualbox/generic-debian8-virtualbox_default_1649216430418_60259/generic-debian8-virtualbox-disk001.vmdk' (flags 000c0723) created successfully
AIOMgr: generic-debian8-virtualbox/generic-debian8-virtualbox_default_1649216430418_60259/generic-debian8-virtualbox-disk001.vmdk

The performance degradation leads to write timeouts, and the logs become filled with messages like the following.

VD#0: Write request was active for 36 seconds
VD#0: Aborted write (524288 bytes left) returned rc=VERR_PDM_MEDIAEX_IOREQ_CANCELED
AHCI#0P0: Canceled write at offset 82372182016 (524288 bytes left) returned rc=VERR_PDM_MEDIAEX_IOREQ_CANCELED

Donate

The roboxes are maintained by volunteers, and provided for free. As such we rely on donations to cover the cost of the hardware, and bandwidth. If you find this project useful, and would like to see it grow, please help by making a Bitcoin, Bitcoin Cash, Monero or monetary donation. If you represent a public cloud, and would like to provide infrastructure support, please contact us directly, or open a ticket.

Monero 8B3BsNGvpT3SAkMCa672FaCjRfouqnwtxMKiZrMx27ry1KA7aNy5J4kWuJBBRfwzsKZrTvud2wrLH2uvaDBdBw9cSrVRzxC

Bitcoin 3NKSTPEeTGmuA95CGGqnyi3zPASSApLZbE

Bitcoin Cash qqxyedtn68jg84w4mkd3vsw2nu6pgkydnudza0ed0m

Roboxes is maintained by Ladar Levison, with infrastructure provided by Lavabit LLC.

robox's Issues

Hardcoded external DNS breaks internal DNS resolver

We use a non public subdomain inside our internal DNS infrastructure. Hard coding public DNS servers breaks this (common) setup.
This renders all your Ubuntu 18.04 and 18.10 images unusable for many companies.

root@default-u1804:~# dig proxy.internal.ourdomain.com     
; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> proxy.internal.ourdomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34613
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;proxy.internal.ourdomain.com.  IN      A

;; Query time: 31 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Nov 19 09:16:11 PST 2018
;; MSG SIZE  rcvd: 57

Even more providers!

Thank you for maintaining so many operating system base boxes, for so many providers already. Honestly, this is a massive feature matrix to have completed, kudos!

What if we took the boxes and offered them on even more providers, like Amazon/Google Cloud/Azure/Oracle images, as well as Docker and Triton images (where possible)? This could grow the userbase and possibly funding sources a bit further, plugging gaps where no compatible images currently exist. For Docker and Triton builders, we would get a bonus effect of many GNU/Linux guests available as lightweight containers, as opposed to more heavyweight virtual machines.

http://packer.io/docs/builders/index.html

Missing guest additions in generic/ubuntu1804 box for virtualbox provider

Bringing up a box with a Vagrantfile that shares my home folder with the guest generates the following error:

MacBook-Pro:ubuntu-18.04(master)$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'generic/ubuntu1804' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'generic/ubuntu1804'
    default: URL: https://vagrantcloud.com/generic/ubuntu1804
==> default: Adding box 'generic/ubuntu1804' (v1.8.38) for provider: virtualbox
    default: Downloading: https://vagrantcloud.com/generic/boxes/ubuntu1804/versions/1.8.38/providers/virtualbox.box
    default: Download redirected to host: vagrantcloud-files-production.s3.amazonaws.com
==> default: Successfully added box 'generic/ubuntu1804' (v1.8.38) for 'virtualbox'!
==> default: Importing base box 'generic/ubuntu1804'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'generic/ubuntu1804' is up to date...
==> default: Setting the name of the VM: ubuntu-1804_default_1541001124673_44044
==> 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: 80 (guest) => 8081 (host) (adapter 1)
    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: vagrant
    default: SSH auth method: private key
    default: 
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    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...
==> default: Mounting shared folders...
    default: /home/vohi => /Users/vohi
Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attempted was:

mount -t vboxsf -o uid=1000,gid=1000 home_vohi /home/vohi

The error output from the command was:

mount: /home/vohi: wrong fs type, bad option, bad superblock on home_vohi, missing codepage or helper program, or other error.

The Vagrantfile is:

# -*- mode: ruby -*-
# vi: set ft=ruby :

$user = ENV['USER']

Vagrant.configure("2") do |config|
  config.vm.box = "generic/ubuntu1804"
  config.vm.network "forwarded_port", guest: 80, host: 8081, host_ip: "127.0.0.1"
  config.vm.synced_folder "~", "/home/#{$user}"
  config.vm.provision "shell", path: "provision.sh", args: "/home/#{$user}"
end

roboxes.org website broken link

In the list of operating systems on https://roboxes.org, the link to RedHat has been incorrectly entered as https://https//www.redhat.com/en/technologies/linux-platforms/enterprise-linux

Should be https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux

Buster broken

Now that Debian v10 Buster has graduated from testing to stable, the repository URLs have changed. This means the generic/debian10 VM is in a corrupt apt state, unable to install packages. Let's point the buster VM's at the sharp teeth, unleashed, ultra-beast stable release!

Parallels Box Error

I tried to run this box seems to be getting the error

There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
a syntax error.

Path: <provider config: parallels>
Line number: 42
Message: ArgumentError: wrong number of arguments (given 4, expected 1..2)

vagrant upload fails on ubuntu1804 box when uploading a directory

Hi,

I'm managing jobs that I want to execute on a vagrant-managed VM in subdirectories which contain the necessary script files. The ideas is that given a directory jobs/test with files main.sh and other stuff, I can basically just do

$ vagrant upload jobs/test test ubuntu1804

and then run

$ vagrant ssh -c test/main.sh ubuntu1804

This worked nicely for all sorts of images until recently. It works with version 1.8.54, but with the latest version 1.9.2 I get an error from vagrant:

/opt/vagrant/embedded/gems/2.2.3/gems/net-scp-1.2.1/lib/net/scp.rb:398:in `await_response_state': scp: error: unexpected filename: . (RuntimeError)
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-scp-1.2.1/lib/net/scp.rb:365:in `block (3 levels) in start_command'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/channel.rb:610:in `do_close'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/session.rb:573:in `channel_closed'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/session.rb:682:in `channel_close'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/session.rb:549:in `dispatch_incoming_packets'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/session.rb:249:in `ev_preprocess'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/event_loop.rb:101:in `each'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/event_loop.rb:101:in `ev_preprocess'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/event_loop.rb:29:in `process'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/session.rb:228:in `process'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/session.rb:181:in `block in loop'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/session.rb:181:in `loop'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/session.rb:181:in `loop'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-ssh-5.1.0/lib/net/ssh/connection/channel.rb:272:in `wait'
	from /opt/vagrant/embedded/gems/2.2.3/gems/net-scp-1.2.1/lib/net/scp.rb:284:in `upload!'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/communicators/ssh/communicator.rb:296:in `block in upload'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/communicators/ssh/communicator.rb:709:in `block in scp_connect'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/communicators/ssh/communicator.rb:489:in `connect'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/communicators/ssh/communicator.rb:707:in `scp_connect'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/communicators/ssh/communicator.rb:293:in `upload'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/commands/upload/command.rb:104:in `block in execute'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/plugin/v2/command.rb:238:in `block in with_target_vms'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/plugin/v2/command.rb:232:in `each'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/plugin/v2/command.rb:232:in `with_target_vms'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/plugins/commands/upload/command.rb:69:in `execute'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/cli.rb:58:in `execute'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/environment.rb:291:in `cli'
	from /opt/vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/bin/vagrant:182:in `<main>'

Given that the only change is the version of the box, I suspect something in the configuration to have broken things.
I can still upload individual files, but that's not what I need :)

Perhaps you are aware of some changes here that could have broken this?

Cheers,
Volker

MirBSD box

Hi, I made a prototype base box for MirBSD, also known as MirOS. It's similar to OpenBSD but with a few quirks. Here are the packer tweaks and tests I implemented to support this VM:

https://github.com/mcandre/packer-templates/tree/master/miros

Basic functionality seems to work, including rsync-based shared folders and provisioning files and scripts. Some notes:

• ACPI support is missing. packer build is able to (just barely) succeed with the provided boot_command, but only because no complex applications are running at the same time that halt -p executes. The MirBSD devs are not interested in adding ACPI support, the VirtualBox developers are not interested in improving APM support. Applications will generally work, and file system can be generally safe, as long as sensitive user applications are safely terminated prior to vagrant halt. Not an ideal situation, but one we can document for the corner case of people wishing to deploy MirBSD VM's while avoiding accidental file system corruption! If you find that VMware or qemu provides better APM support, please let me know. Then it would actually make sense to offer VMware/libvirt providers but not VirtualBox, to safeguard against this issue.
• Related to ACPI lack of support, is the fact that much of the provisioning for the base box is done directly in boot_command, that would ordinarily be done at a later phase over SSH (much faster). This is because of how Packer doesn't understand that the last SSH provisioning script might trigger a final powerdown that is not recognized by ACPI. And so in practice Packer stalls the build waiting for an SSH connection that never happens. Fortunately, MirBSD is a fairly lean install (~100MiB) and so the boot_command provisioning is minimal in time and complexity.
• MirBSD's repository for install media including the base .NGZ files, is quite slow, taking around half an hour to download a basic set of install files. As a workaround, I have setup my packer build process with a make wrapper that mirrors these files locally with wget. It's up to you whether to do this; for debugging this really speeds up the build cycle. When everything is running smoothly, there's no particular reason to locally mirror these files.
• MirPorts appears to be broken. pkg_add still works, and I plan to look into pkgsrc later, in order to get more edgy packages like cmake and pip installed in some of my personal downstream boxes.

Do not include /etc/machine-id in the boxes

Otherwise, multiple instances of the same image will be leased the same IP via dhcp and hell breaks loose.

Offer Version of Boxes without Hardcoded DNS?

Hi,

As mentioned in issue #11 having a hard-coded external dns breaks our internal dns resolver. In the mean time, I've taken a bit of time to modify your robox.sh script for our use, without the hard-coded dns.

Would this be something you'd be open to merge via PR? Now that the robox namespace seems to be preferred, maybe we could utilise the 'generic' namespace for the boxes without dns changes, and the 'robox' namespace for boxes with hard-coded dns?

Thoughts? Perhaps we could even add this as a robox.sh build-time option?

generic/debian10 VirtualBox Vagrant use SATA instead of IDE controller

For better performance please use the VirtualBox SATA controller.

From https://docs.oracle.com/cd/E97728_01/E97727/html/harddiskcontrollers.html

Like a real SATA controller, Oracle VM VirtualBox's virtual SATA controller operates faster and also consumes fewer CPU resources than the virtual IDE controller.

And I found a number of anecdotes in online discussions confirming this.

Contributing Documentation

Hey, I stumbled on this project when on the Vagrant store looking for boxes and noticed the generic boxes were all done quite well, but was unable to find some boxes offered by you that I'd like to see. So first off, thank you for this project! Appreciate the work you've put in here.

I made a comment on the other issue where you were asking for the next distros that people would like to see added. But, I would also like to see documentation on how to contribute to the repository if that's not too hard. That way, it wouldn't only be upon you to make boxes, but others could follow your steps so that they can add in the Operating Systems that they'd like to see. Looking at the repo now, it's a little unclear what all needs to happen in order to get another OS added for automated box building.

Cannot ssh into generic/ubuntu1604 (virtualbox, 1.8.24)

I cannot ssh into generic/ubuntu1604, provider virtualbox, version 1.8.24.

If I log into the console sshd is running and listening on port 22, however there is an error in the logs

error: Could not load host key: /etc/ssh/ssh_host_rsa_key
error: Could not load host key: /etc/ssh/ssh_host_dsa_key
error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
error: Could not load host key: /etc/ssh/ssh_host_ed25519_key

> vagrant up --provider virtualbox
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'generic/ubuntu1604'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'generic/ubuntu1604' is up to date...
==> default: Setting the name of the VM: generic_ubuntu1604_default_1534863324235_72684
==> 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: vagrant
    default: SSH auth method: private key
    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: Remote connection disconnect. Retrying...
    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: Remote connection disconnect. Retrying...
The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'starting, running'. The machine is in the
'unknown' state. Please verify everything is configured
properly and try again.

If the provider you're using has a GUI that comes with it,
it is often helpful to open that and watch the machine, since the
GUI often has more helpful error messages than Vagrant can retrieve.
For example, if you're using VirtualBox, run `vagrant up` while the
VirtualBox GUI is open.

The primary issue for this error is that the provider you're using
is not properly configured. This is very rarely a Vagrant issue.

> ssh [email protected] -p 2460
Connection closed by 127.0.0.1 port 2460

Haiku Beta 1

Now that Haiku has released a more stable beta, could we get a base box for Haiku?

https://www.haiku-os.org/get-haiku/

Here's an example packer template for Haiku alpha:

https://github.com/mcandre/packer-templates/tree/master/haiku

Debian 10 for Hyper-V: Why on the last build sometimes just 3 providers instead of the 5 ?

Hello,

First thanks a lot for the work on building vagrant box and provide them to us !

I noticed that the last debian 10, don't provide Hyper-V sometimes. Is it a bug in the build system ?
Please see v1.9.19 and v1.9.14, no hyper-v, nor parralels:
https://app.vagrantup.com/generic/boxes/debian10
https://app.vagrantup.com/roboxes/boxes/debian10

The last Debian 10 (buster), v1.9.19, is the stable debian (all previous version are based on debian 10 testing). I would have very like to find Hyper-V as provider for this first one Debian 10 stable box.

Is it a bug or is a new build planned very soon for Hyper-V ?

Thanks !

freebsd vagrant does not connect

On arch I run:

$ vagrant init generic/freebsd12
$ vagrant up              
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'freebsd/FreeBSD-11.0-STABLE' version '2017.05.11.2' is up to date...
==> default: Clearing any previously set forwarded ports...
==> 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: 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: vagrant
    default: SSH auth method: private key
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

Which distros should be added next?

@mcandre when I'm able to get RAM/SSDs for the recently donated blades, and then get those robots up and running, I plan to add more distros. Devuan, possibly Minix are at the top of my personal wish list, but if you have 1 or 2 that you think you think are important, now would be the time to suggest them. MacOS/Windows are also near the top of my list, but they'll require the most work.

Technically speaking once I get the new blade server working I should have the capacity to add several distros. The bottleneck will be the time it takes to test/troubleshoot the new distro on the 5 different hypervisors I currently target. If your willing to tweak your templates so they fit into the Robox generic pipeline, and then submit a pull request, that would make it easier for me to accept more of the distros you keep requesting.

If your interested I can setup an experimental branch you can work with while you get the new boxes integrated.

Some images fail to find a rootfs

Hello!

I have a strange issue with the some boxes under libvirt provider. For some reason the box can't find the rootfs after booting up. After spending countless hours rummaging through config files and ending up with reinstalling vagrant, libvirt, and qemu, I still haven't managed to find the root cause.

Current behavior:

$ vagrant init generic/arch
$ vagrant up --provider=libvirt
Bringing machine 'default' up with 'libvirt' provider...
==> default: Box 'generic/arch' could not be found. Attempting to find and install...
    default: Box Provider: libvirt
    default: Box Version: >= 0
==> default: Loading metadata for box 'generic/arch'
    default: URL: https://vagrantcloud.com/generic/arch
==> default: Adding box 'generic/arch' (v1.9.6) for provider: libvirt
    default: Downloading: https://vagrantcloud.com/generic/boxes/arch/versions/1.9.6/providers/libvirt.box
==> default: Successfully added box 'generic/arch' (v1.9.6) for 'libvirt'!
==> default: Uploading base box image as volume into libvirt storage...
==> default: Creating image (snapshot of base box volume).
==> default: Creating domain with the following settings...
==> default:  -- Name:              vagrant_default
==> default:  -- Domain type:       kvm
==> default:  -- Cpus:              2
==> default:  -- Feature:           acpi
==> default:  -- Feature:           apic
==> default:  -- Feature:           pae
==> default:  -- Memory:            2048M
==> default:  -- Management MAC:    
==> default:  -- Loader:            
==> default:  -- Base box:          generic/arch
==> default:  -- Storage pool:      default
==> default:  -- Image:             /var/lib/libvirt/images/vagrant_default.img (32G)
==> default:  -- Volume Cache:      default
==> default:  -- Kernel:            
==> default:  -- Initrd:            
==> default:  -- Graphics Type:     vnc
==> default:  -- Graphics Port:     5900
==> default:  -- Graphics IP:       127.0.0.1
==> default:  -- Graphics Password: Not defined
==> default:  -- Video Type:        cirrus
==> default:  -- Video VRAM:        256
==> default:  -- Sound Type:	
==> default:  -- Keymap:            en-us
==> default:  -- TPM Path:          
==> default:  -- INPUT:             type=mouse, bus=ps2
==> default: Creating shared folders metadata...
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...

This phase never finishes. However, on the serial console initramfs complains about missing rootfs:

dmesg tail:

I have this issue only on Fedora, the generic/arch box works fine on CentOS 7.

$ cat /etc/fedora-release 
Fedora release 29 (Twenty Nine)
$ rpm -q libvirt vagrant vagrant-libvirt 
libvirt-4.7.0-1.fc29.x86_64
vagrant-2.1.2-3.fc29.noarch
vagrant-libvirt-0.0.40-5.fc29.noarch

I'm under impression I keep missing something pretty obvious here, as some boxes work (like generic/debian9) and some don't (like generic/arch or generic/centos7).

generic/fedora29 (v1.8.40, libvirt) stuck on .device systemd jobs

Hello.

generic/fedora29 (v1.8.40, libvirt)

Image boot is stuck for 1.5 minutes with messages A start job is running for dev-disk...8c3382.device, Dependency failed for Resume from ...8c3382 (this is swap disk UUID, /dev/sda2), and then stuck forever with A start job is running for dev-disk...8243e.device message (this is /, /dev/sda3).

However, booting this image manually into rescue mode (from Grub menu) works. After regenerating initrd from rescue mode with dracut --verbose --force, booting to normal mode also works.

Thank you for all your boxes. Your project is probably the only one which builds boxes for parallels, hyperv, virtualbox, libvirt, and vmware_desktop - 5 platforms at the same time, allowing to use consistent environment across different virtualization engines.

Request about naming openbsd boxes

Hello,

please name the OpenBSD boxes with the release number like openbsd64 for openbsd 6.4.
OpenBSD releases are numbered with 0.1 increased from release to release.

Regards

Plan 9?

Could we get a Plan 9 box? Would be awesome to quickly build and test apps in a Plan 9 VM!

legacy `sshd-keygen` removed in fedora

robox/scripts/fedora29/sshd.sh

Line 21 in bf8b791

sed --in-place "s/\\-t rsa /\-t rsa -b 4096 /g" /usr/sbin/sshd-keygen

https://fedoraproject.org/wiki/Changes/Remove_slogin_and_sshd-keygen

Linux Integration Services for hyperv

Maybe hyperv templates should install
https://www.microsoft.com/en-us/download/details.aspx?id=55106

generic box update: Red Hat Enterprise Linux 8 now generally available

https://developers.redhat.com/blog/2019/05/07/red-hat-enterprise-linux-8-now-generally-available/

generic-hyperv.json
generic-libvirt.json
generic-parallels.json
generic-virtualbox.json
generic-vmware.json

RHEL8: does not boot with disk_bus=scsi

hi,

it appears to have been changed for vmware already, but i was unable to boot the libvirt variant of your rhel8 image with the default setting:

disk_bus=scsi

it times out searching for the root volume and fdisk in rescue mode does not show any disks.
I was able to boot the VM with vagrant-libvirt using

disk_bus="sata"

in the Vagrant File setting.

requesting a license

https://choosealicense.com/no-permission/

refering to a nice discussion
github/choosealicense.com#196

dns servers hardcoded in generic/ubuntu1804

The following servers are hardcoded in the generic/ubuntu1804 image:

# systemd-resolve --status
Global
         DNS Servers: 4.2.2.1
                      4.2.2.2
                      208.67.220.220

Wouldn't it be expected that the local DNS from DHCP should have priority over these servers? If running in an environment where access is blocked to external DNS servers, then this image requires further work to use, rather than working out of the box, like say, bento/ubuntu-18.04 or ubuntu/bionic64.

404 when initialize boxes in vagrant

I keep getting a 404 when I attempt to "vagrant up" after initializeing a box. I also get a 404 if I try to add a box directly. I have tried this for Fedora 28, Fedora 29, and Fedora 29 Silverblue:

C:\Users\Jonathan Calloway\vagrant>vagrant box add generic/fedora28
==> box: Loading metadata for box 'generic/fedora28'
box: URL: https://vagrantcloud.com/generic/fedora28
This box can work with multiple providers! The providers that it
can work with are listed below. Please review the list and choose
the provider you will be working with.

1. hyperv
2. libvirt
3. parallels
4. virtualbox
5. vmware_desktop

Enter your choice: 4
==> box: Adding box 'generic/fedora28' (v1.8.52) for provider: virtualbox
box: Downloading: https://vagrantcloud.com/generic/boxes/fedora28/versions/1.8.52/providers/virtualbox.box
box: Progress: 0% (Rate: 0/s, Estimated time remaining: --:--:--)
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.

The requested URL returned error: 404 Not Found

9p and NFS support for Vagrant

Would it be possible to add 9p and NFS support into Vagrant libvirt boxes by default, since VirtualBox shares aren't available there and those are (afaik) the only other options for mounts that don't have to be synced manually?

AIX v1 box?

Would love to see an AIX VM!

What is the difference between images of same OS (CentOS 7, for example) from "generic" and "roboxes"?

@ladar

Example:
https://app.vagrantup.com/roboxes/boxes/centos7
https://app.vagrantup.com/generic/boxes/centos7

Where do you build your vmware boxes ?

Hello

I'm packaging boxes via Packer and chef/bento based configuration files. VirtualBox is all fine, but I hit a wall trying to run my vmware CentOS / RHEL boxes over ESXi using vagrant + vagrant plugin vagrant-vmware-esxi : disk seems to be ignored, the VM boot is looping on PXE/TFTP lookup.

So I'm trying to understand hence this question. I tried some upstream boxes : centos/6 and centos/7 does work, generic/centos6 centos7 rhel7 doesn't, same symptoms. CentOS is building his boxes over a VMWare Workstation. Mine are built over ESXi 5.1 5.5. Where/how do you build yours ?

And any hints for investigation would be welcomed, I've been at it for days, I'm out of idea!

Debian sid

Please provide a base box for Debian sid, so that the very latest Debian packages can be directly used by VM's.

For example, sparc64-flavored g++ cross-compiler toolchains for amd64 guests, are available in sid but not buster.

https://packages.debian.org/search?suite=sid&arch=sparc64&searchon=names&keywords=g%2B%2B

https://packages.debian.org/search?suite=buster&arch=sparc64&searchon=names&keywords=g%2B%2B

UTC

When specifying timezones, please select UTC, which will result in more predictable behavior on our servers.

Stuck at Waiting for SSH to become available...

I'm unable to get generic/ubuntu1804 and generic/ubuntu1604 to work properly with libvirt.

Steps to reproduce:

1. vagrant init generic/ubuntu1804
2. vagrant up --provider=libvirt

Vagrant gets stuck at Waiting for SSH to become available... but I can see that the VM has booted successfully in virt-manager.
I have previously used the ubuntu1604 box successfully on this computer and I'm unsure what has happened.
The same problem is not present when using virtualbox as provider.

Environment
Host OS: Ubuntu 18.04
Vagrant: 2.0.1
libvirt: 4.0.0
QEMU emulator version 2.11.1

generic/fedora30 (virtualbox) VB guest update error with vagrant-vbguest

I created a Vagrantfile similar to this:

Vagrant.configure("2") do |config|
  # I have some proxy settings here

  config.vm.hostname = "foo"
  config.vm.box = "generic/fedora30"

  config.vm.box_check_update = false
end

When I run vagrant up (on Linux) it fails:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'generic/fedora30'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: client-vm_default_1563189751261_38790
==> 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: vagrant
    default: SSH auth method: private key
    default: 
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    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: Configuring proxy environment variables...
==> default: Configuring proxy for Git...
==> default: Configuring proxy for Yum...
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims:   6.0.0
VBoxService inside the vm claims: 6.0.8
Going on, assuming VBoxService is correct...
[default] GuestAdditions seems to be installed (6.0.8) correctly, but not running.
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims:   6.0.0
VBoxService inside the vm claims: 6.0.8
Going on, assuming VBoxService is correct...
bash: line 4: start: command not found
bash: line 4: start: command not found
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims:   6.0.0
VBoxService inside the vm claims: 6.0.8
Going on, assuming VBoxService is correct...
bash: line 4: setup: command not found
==> default: Checking for guest additions in VM...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

 setup

Stdout from the command:



Stderr from the command:

bash: line 4: setup: command not found

I have the vagrant-vbguest plugin installed if that matters.

$ vagrant --version
Vagrant 2.2.4
$ vagrant plugin list
vagrant-disksize (0.1.3, global)
  - Version Constraint: > 0
vagrant-docker-compose (1.3.0, global)
  - Version Constraint: > 0
vagrant-ignition (0.0.3, global)
  - Version Constraint: > 0
vagrant-libvirt (0.0.45, global)
  - Version Constraint: > 0
vagrant-openstack-provider (0.13.0, global)
  - Version Constraint: > 0
vagrant-proxyconf (2.0.1, global)
  - Version Constraint: > 0
vagrant-vbguest (0.18.0, global)
  - Version Constraint: > 0

Box version: generic/fedora30 (virtualbox, 1.9.18)

Update: indeed this problem is related to vagrant-vbguest. Could this vagrant box support vagrant-vbguest? Otherwise the following workaround in the Vagrantfile works (I found it in some other Vagrantfile):

  if Vagrant.has_plugin?("vagrant-vbguest") then
    config.vbguest.auto_update = false
  end

generic/ vs roboxes/ namespace?

Which namespace should users prefer when referencing these boxes from Vagrant Cloud, the "generic" or "roboxes" namespace? Will one become deprecated in favor of the other over time?

More architectures!

Could we get boxes for more architectures, to help test applications in different environments? I think most of these boxes are amd64, which is awesome, and i386, powerpc, arm, mips would be great as well!

Unfortunately, most hypervisors do not currently support non-x86-based guests. Though I think it is possible to run some non-x86 guest boxes with Vagrant, via the Vagrant libvirt plugin. This enables users to run non-x86 guests on x86 hosts, though the hosts must be running (GNU?) Linux natively.

Could we get some libvirt-based ppc, arm, and mips boxes published? These take longer to build and run, but they are worth it for projects that need to test on lots of different architectures.

Shrink boxes

We can strip out some components to reduce total image size, see the cleanup scripts in https://github.com/mcandre/packer-templates for examples. In general, caches should be cleaned, including /tmp mounts and any OS package manager caches.

We can shrink images even further by removing some nonessential software packages, like perl in Ubuntu, that aren't strictly needed in order to boot up and serve SSH commands. This could break some user expectations, of course, so it's up to you to decide how minimal or maximal we want the base boxes to be.

Debian v10 AKA buster AKA testing

Could we get a box for Debian Buster, which provides some newer packages for CloudABI development?

Fedora boxes do not support vboxsf

I'm trying to use roboxes/fedora29 but I'm running into issues when trying to have a synced folder.

Apparently the fedora package virtualbox-guest-additions.x86_64 does not supply the vboxsf file system. See this redhat bug and this one for discussion.

Currently the vbguest plugin also fails to properly install the guest additions with this bug.

So I'm wondering if there is a way of getting a fedora in a virtual machine with synced folders and being able to do vagrant destroy and vagrant up and have it working without having to roll one's own fedora box.

Maybe using nfs is a solution, but my networking setup is a bit complex, so I haven't gotten round to that.

I don't know if roboxes could create a box compatible with synced folders, but I thought I should at least report the current state of affairs.

generic/ubuntu1804 kernel panic on boot with virtualbox

Starting a generic/ubuntu1804 vagrant box with VirtualBox with 256M memory gives a kernel panic and an out of memory error on the console, vagrant ssh does not work, and provisioning fails (happens early in the boot process).

This issue does not occur with bento/ubuntu-18.04 or ubuntu/bionic64. Is there a different kernel or kernel options in use, or something else that might cause this?

bhyve, xhyve providers

Could robox offer bhyve, xhyve providers in addition to the other providers, in order to run guests more efficiently on FreeBSD and macOS respectively?

• https://github.com/jesa7955/vagrant-bhyve
• https://github.com/oldpatricka/vagrant-xhyve

Anyone else getting "E1000 NIC" security warnings?

I recently updated Vagrant, and now it complains that the virtual network device that many boxes use by default, E1000, is insecure. Does this happen with the generic/ boxes as well? Can we pack more secure base boxes while Vagrant works on a fix?

More boxes!

Hey, thank you for maintaining so many useful Vagrant boxes online, and supporting many backend providers as well! I'd love to see even more guest OS's available through robox! Feel free to crib a few from my packer templates:

https://github.com/mcandre/packer-templates

• Illumos: DilOS, SmartOS
• DragonflyBSD
• HardenedBSD
• macOS
• NetBSD
• Haiku OS
• MINIX
• another musl/Linux with xbps packages: Void Linux
• Windows

The `synced_folder` does not work on `generic/centos7`

I'm using generic/centos7 with the following configuration

Vagrant.configure("2") do |config|
    config.vm.define "cent7" do |cent7|
        cent7.vm.box = "generic/centos7"
        cent7.vm.network "private_network", ip: "172.20.120.10"
        cent7.vm.synced_folder "bin/", "/vagrant/bin"
    end
end

But there seems to be some issue related to synced_folder. I'm seeing the following error when I run vagrant up cent7

An error occurred while executing `vmrun`, a utility for controlling
VMware machines. The command and output are below:

Command: ["enableSharedFolders", "/Users/nalluri/Projects/consul-client/.vagrant/machines/cent7/vmware_desktop/f2febc17-913d-48b4-b94a-f5dc84e46f12/generic-centos7-vmware.vmx", {:notify=>[:stdout, :stderr]}]

Stdout: Error: There was an error mounting the Shared Folders file system inside the guest operating system

Stderr:

'vagrant up' fails on generic/alpine39 if the option hostname is needed

Vagrant version

2.2.4

Host operating system

Ubuntu 18.04 LTS (Bionic Beaver)

Guest operating system

Alpine Linux 3.9

Vagrantfile

Vagrant.configure("2") do |config|  
  config.vm.box = "generic/alpine39"
  config.vm.hostname = "alpine.example.org" 
end

Expected behavior

Alpine VM is up and requested hostname is set.

Actual behavior

vagrant up fails on Setting hostname....

==> default: Setting hostname...                                                                                                                                                              
The following SSH command responded with a non-zero exit status.                                                                                                                              
Vagrant assumes that this means the command failed!                                                                                                                                           
                                                                                                                                                                                              
# Save current hostname saved in /etc/hosts                                                                                                                                                   
CURRENT_HOSTNAME_FULL="$(hostname -f)"                                                                                                                                                        
CURRENT_HOSTNAME_SHORT="$(hostname -s)"                                                                                                                                                       
                                                                                                                                                                                              
# New hostname to be saved in /etc/hosts                                                                                                                                                      
NEW_HOSTNAME_FULL='alpine.exampler.org'                                                                                                                                                       
NEW_HOSTNAME_SHORT="${NEW_HOSTNAME_FULL%%.*}"                                                                                                                                                 
                                                                                                                                                                                              
# Update sysconfig                                                                                                                                                                            
sed -i 's/\(HOSTNAME=\).*/\1alpine.exampler.org/' /etc/sysconfig/network                                                                                                                      
                                                                                                                                                                                              
# Set the hostname - use hostnamectl if available
if command -v hostnamectl; then
  hostnamectl set-hostname --static 'alpine.exampler.org'
  hostnamectl set-hostname --transient 'alpine.exampler.org'
else
  hostname 'alpine.exampler.org'
fi

# Update ourselves in /etc/hosts
if grep -w "$CURRENT_HOSTNAME_FULL" /etc/hosts; then
  sed -i -e "s/( )$CURRENT_HOSTNAME_FULL( )/$NEW_HOSTNAME_FULL/g" -e "s/( )$CURRENT_HOSTNAME_FULL$/$NEW_HOSTNAME_FULL/g" /etc/hosts
fi
if grep -w "$CURRENT_HOSTNAME_SHORT" /etc/hosts; then
  sed -i -e "s/( )$CURRENT_HOSTNAME_SHORT( )/$NEW_HOSTNAME_SHORT/g" -e "s/( )$CURRENT_HOSTNAME_SHORT$/$NEW_HOSTNAME_SHORT/g" /etc/hosts
fi

# Restart network
service network restart


Stdout from the command:

127.0.0.1       localhost.lavabit.com localhost localhost.localdomain localhost
127.0.0.1       localhost.lavabit.com localhost localhost.localdomain localhost
::1             localhost localhost.localdomain


Stderr from the command:

sed: /etc/sysconfig/network: No such file or directory
 * service: service `network' does not exist

Steps to reproduce

Run vagrant up with the provided Vagrantfile

References

The same error is mentioned on
hashicorp/vagrant: #10584

generic/arch: Wrong virtualbox modules installed

https://github.com/lavabit/robox/blob/master/scripts/arch/virtualbox.sh#L10

pacman --sync --noconfirm virtualbox-guest-utils-nox

Should be

pacman --sync --noconfirm virtualbox-guest-modules-arch virtualbox-guest-utils-nox 

Without specifying the guest modules to install, it is defaulting to virtualbox-guest-dkms, which does not work with a Linux kernal.

Ideas for speeding up builds

robox is a wonderfully comprehensive collection of base boxes covering a wide variety of different operating systems. I gather that time to pack all these boxes is a constraint on further development, so I wonder if we can improve packing time somehow.

For example, is there a significant restriction on build resources, RAM, CPU cores, and so on? Perhaps we could provide a donation link specifically for funding cloud resources used to build our images.

That could help with the hardware constraints on build time, by scaling vertically. Could we also scale horizontally? Perhaps building boxes from a pool of hosts.

Finally, what steps can we take to improve the build time of each particular box? I've done some (premature) optimizations on my own box templates, such as minifying boot_command contents, and compressing provisioning media, as keyboard input delivery and FTP can be run slowly on certain virtual guests.

Honestly, the bottlenecks of OS installation tend to be the long, uncontrolled process of running the install wizards. But what other things can we shave off, even just a few minutes from each build? Reducing boot splash timeouts, selecting faster virtual hardware (when guest compatible), and ensuring that installation media (ISO's, IMG's) are sourced from fast online caches. Any other ideas for accelerating builds?

SmartOS base box

Example packer template:

https://github.com/mcandre/packer-templates/tree/master/smartos