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

[ladar]

@attila123 have you tried the obvious? Removing the vbguest plugin and/or confirming you have VirtualBox 6.0.8?

[attila123]

@ladar I am sure removing the vagrant-vbguest would solve this, because the workaround is vagrant-vbguest specific. But I would not do that because some VMs may require that plugin.
Note that some "official" vagrant boxes do support vagrant-vbguest, e.g. 'centos/7' is one of those. So it may be a nice feature to support vagrant-vbguest so users do not run into trouble when they happen to have that plugin installed. Hopefully it would not add too much bloat to the box. Of course you can't prepare for all the vagrant plugins out there, but I did not have problem with any other one.
(Just thinking loud: maybe vagrant-vbguest should not enable itself by default, so its auto_update should be false by default. But it would break compatibility with existing Vagrantfile-s, so I can imagine that vagrant-vbguest dev(s) would resist it...)

"VirtualBox Graphical User Interface Version 6.0.8 r130347"

[ladar]

@attila123 I just wanted you to try provisioning the box without the plugin, so that we can confirm it's plugin specific.

I don't want to ship boxes that require a plugin, but I have no issue fixing minor compatibility issues, if it doesn't break anything. I just don't have the resources to test every box (up to 40 now), on all 6 hypervisors... it gets even tougher if you include different host OSes (Win/Mac/endless Linux distros).

As for this issue... this config module/script is what sets up the VirtualBox version of the Fedora 30 images... so if we can identify what's needed, that's where it will go.

https://github.com/lavabit/robox/blob/master/scripts/fedora30/virtualbox.sh

[attila123]

@ladar Your box would not require but rather support vagrant-vbguest if you would add the support. But currently it is unclear how to support vagrant-vbguest so I opened an issue for them (see above). Maybe the solution should come from their side by making it clear in their logs that those messages are coming from their plugin (virtualbox users may not remember what plugins they installed and they should not be considered vb guest additions experts). So let me create one more issue for them. Update: actually virtualbox should have this improvement and show which plugin is logging...

[attila123]

I cannot uninstall vagrant plugins for some reason:

$ vagrant plugin uninstall vagrant-vbguest
Uninstalling the 'vagrant-vbguest' plugin...
Traceback (most recent call last):
	27: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/bin/vagrant:182:in `<main>'
	26: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/environment.rb:292:in `cli'
	25: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/cli.rb:66:in `execute'
	24: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/plugins/commands/plugin/command/root.rb:66:in `execute'
	23: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/plugins/commands/plugin/command/uninstall.rb:25:in `execute'
	22: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/plugins/commands/plugin/command/uninstall.rb:25:in `each'
	21: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/plugins/commands/plugin/command/uninstall.rb:26:in `block in execute'
	20: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/plugins/commands/plugin/command/base.rb:14:in `action'
	19: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/action/runner.rb:102:in `run'
	18: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/util/busy.rb:19:in `busy'
	17: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/action/runner.rb:102:in `block in run'
	16: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/action/builder.rb:116:in `call'
	15: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
	14: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
	13: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
	12: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/plugins/commands/plugin/action/plugin_exists_check.rb:20:in `call'
	11: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
	10: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/action/builtin/after_trigger.rb:26:in `call'
	 9: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
	 8: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/action/builtin/before_trigger.rb:23:in `call'
	 7: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/action/warden.rb:50:in `call'
	 6: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/plugins/commands/plugin/action/uninstall_plugin.rb:18:in `call'
	 5: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/plugin/manager.rb:200:in `uninstall_plugin'
	 4: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/bundler.rb:232:in `clean'
	 3: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/bundler.rb:232:in `each'
	 2: from /opt/vagrant/embedded/gems/gems/vagrant-2.2.4/lib/vagrant/bundler.rb:241:in `block in clean'
	 1: from /usr/lib/ruby/2.6.0/rubygems/uninstaller.rb:162:in `uninstall_gem'
/usr/lib/ruby/2.6.0/rubygems/uninstaller.rb:264:in `remove': uninitialized constant Gem::RDoc (NameError)

[ladar]

@attila123 looks like your setup is corrupted. Do you have vagrant v2.2.5 installed? Or you still using v2.2.4? If you installed the plugin with v2.2.4 and updated to v2.2.5 that error makes sense.

Either way your plugin gem files should be stored in your ~/.vagrant.d/ directory (assuming *nix host, since you haven't specified). If that's the case, can you delete it? If not you could try something like:

export VAGRANT_HOME=$HOME/.new.vagrant.d/
vagrant init generic/fedora30
vagrant up --provider=virtualbox

Which will use a clean vagrant profile.

[attila123]

Yes looks like my setup was corrupted, so I decided to uninstall vagrant (distro package) and deleted /opt/vagrant and ~/.vagrant.d directories and installed vagrant again (from distro package).
I am currently in Manjaro Linux, which does not yet have 2.2.5, only 2.2.4 (it releases new packages with some testing delay compared to Arch Linux which it is based on).
In any case I executed

vagrant init generic/fedora30
vagrant up

it worked fine (with no vagrant plugins).

Now the author (or dev) of the vagrant-vbguest commented that the error may came from the fact that the VM did not have the vboxadd tool installed, but see in more detail: dotless-de/vagrant-vbguest#344 (comment)

[ladar]

@attila123 since you have an image up and run the following, and post the output:

which vboxadd
sudo updatedb
locate vboxadd
dnf whatprovides "*/vboxadd"
sudo su
which vboxadd

[attila123]

@ladar I executed the commands:

[vagrant@fedora30 ~]$ which vboxadd
/usr/bin/which: no vboxadd in (/home/vagrant/.local/bin:/home/vagrant/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)
[vagrant@fedora30 ~]$ sudo updatedb
[vagrant@fedora30 ~]$ locate vboxadd
/etc/X11/xinit/xinitrc.d/98vboxadd-xclient.sh
[vagrant@fedora30 ~]$ dnf whatprovides "*/vboxadd"
Fedora Modular 30 - x86_64                                                                                                                                    1.8 MB/s | 2.7 MB     00:01    
Fedora Modular 30 - x86_64 - Updates                                                                                                                          2.0 MB/s | 2.3 MB     00:01    
Fedora 30 - x86_64 - Updates                                                                                                                                  5.0 MB/s |  17 MB     00:03    
Fedora 30 - x86_64                                                                                                                                            4.9 MB/s |  70 MB     00:14    
Error: No Matches found
[vagrant@fedora30 ~]$ sudo su
[root@fedora30 vagrant]# which vboxadd
/usr/bin/which: no vboxadd in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
[root@fedora30 vagrant]# 

Also I did dnf install dnf-utils and then (based on

robox/scripts/fedora30/virtualbox.sh

Line 61 in be20ce6

retry dnf install --assumeyes virtualbox-guest-additions; error

):

[vagrant@fedora30 ~]$ repoquery -l virtualbox-guest-additions
Fedora Modular 30 - x86_64                                                                                                                                     33 kB/s |  24 kB     00:00    
/etc/X11/xinit/xinitrc.d/98vboxadd-xclient.sh
/etc/xdg/autostart/vboxclient.desktop
/usr/bin/VBoxClient
/usr/bin/VBoxClient-all
/usr/bin/VBoxControl
/usr/lib/.build-id
/usr/lib/.build-id/09
/usr/lib/.build-id/09/bc607f5da96b336371447d1164fad8a3a2bcf5
/usr/lib/.build-id/18
/usr/lib/.build-id/18/7c519dfa04d217e40872feb5bbb2f05f4c6d16
/usr/lib/.build-id/24
/usr/lib/.build-id/24/2972d17a826b946727f24ecd6c65ceedcbacd0
/usr/lib/.build-id/64
/usr/lib/.build-id/64/2a46d3c8d185f6292da3109f24a51839317c70
/usr/lib/systemd/system-preset/96-vbox.preset
/usr/lib/systemd/system/vboxservice.service
/usr/lib/udev/rules.d/60-vboxguest.rules
/usr/lib64/security/pam_vbox.so
/usr/sbin/VBoxService
/usr/share/licenses/virtualbox-guest-additions
/usr/share/licenses/virtualbox-guest-additions/COPYING
/usr/share/licenses/virtualbox-guest-additions/COPYING.CDDL
/etc/X11/xinit/xinitrc.d/98vboxadd-xclient.sh
/etc/xdg/autostart/vboxclient.desktop
/usr/bin/VBoxClient
/usr/bin/VBoxClient-all
/usr/bin/VBoxControl
/usr/lib/.build-id
/usr/lib/.build-id/41
/usr/lib/.build-id/41/0d12cc52a06ecdba643036b5252278ee01533d
/usr/lib/.build-id/43
/usr/lib/.build-id/43/96a001331a20190f9b95b319882ad70f7a4177
/usr/lib/.build-id/45
/usr/lib/.build-id/45/3fa39baf6815b1f14844c91a5382d6cb395a50
/usr/lib/.build-id/aa
/usr/lib/.build-id/aa/4f06a74fe2f05e36727ac39bc1e871e4a90b9a
/usr/lib/systemd/system-preset/96-vbox.preset
/usr/lib/systemd/system/vboxservice.service
/usr/lib/udev/rules.d/60-vboxguest.rules
/usr/lib64/security/pam_vbox.so
/usr/sbin/VBoxService
/usr/share/licenses/virtualbox-guest-additions
/usr/share/licenses/virtualbox-guest-additions/COPYING
/usr/share/licenses/virtualbox-guest-additions/COPYING.CDDL

[ladar]

@attila123 @fnordfish it appears vboxadd is nowhere to be found, so I went and looked at the other ticket. It was a bit confusing, but it seemed to say the guest agent/utils should NOT be installed already? Which doesn't make any sense. It also seemed to imply there might be a problem compiling the kernel module and/or running the service. What is the output from:

systemctl status -l VBoxService 

The service name/rules might be different. I don't have one handy to test.

[fnordfish]

So, the issue with installing guest additions via distribution packages is that, they are often out of sync with what people have on their host machines. Some distos make it impossible to install a specific version, newer versions are released with great time difference, or not released for specific versions of the guest OS release at all.
The problem is, that VirtualBox is pretty picky and weird things might happen when versions don't match exactly (semantic versioning or downwards compatibility is nothing one should count on with VirtualBox).
That's why vbguest made the decision to always install guest additions from source (using the matching version of the VirtualBox iso file). And this collides with the package installation.

So, the best way - at least from our perspective - would be to seed the box with guest additions installed from sources (using the iso file "http://download.virtualbox.org/virtualbox/%{version}/VBoxGuestAdditions_%{version}.iso"). The VirtualBox Guest Addtions installer is actually pretty good in updating/replacing old installations done by itself.

[ladar]

@fnordfish some of the roboxes do compile the guest agents from source (using the 5.2.38 I think), if no official distro package is available, or the official version is very outdated. The problem was the build/install process from the ISO was rather fragile, so I felt the repo packages would be more "reliable." It seems with the Fedora 30 (based on your error message) uses a relatively recent release. I'd say 6.0.4 based on this URL:

https://mirrors.kernel.org/fedora/releases/30/Everything/x86_64/os/Packages/v/virtualbox-guest-additions-6.0.4-2.fc30.x86_64.rpm

All of that being said, if what you've chosen to do (always compile from source), then you need to detect the OS, and check for the official package, and remove it first. Even if the VBox install script "replaces" an existing install, you're sure to have issues when the OS updates itself -- not to mention having dangling files (like a systemd config) which doesn't get removed.

On RPM based distros, you can look for the guest agent with something like

rpm -q virtualbox-guest-additions

And remove it with:

rpm -e virtualbox-guest-additions

Of course it's better to use the package manager, specifically yum or dnf but that requires even more logic.

What's seen is scripts look for the rpm command, the apk command, and/or the apt-get command by running which, and then using the appropriate syntax to search for and remove all the different package name variations...

You can look at the robox/scripts/*/virtualbox.sh scripts to get started.

P.S. Other commands to look for (off the top of my head) are zypper (OpenSUSE), pkg-static (FreeBSD), pkg_info and pkg_delete (OpenBSD), emerge (Gentoo), pacman (Arch), brew (MacOS)...

[ladar]

@attila123 @fnordfish it seems that we've confirmed the issue is with the plugin. Removing the agent doesn't seem like the right choice for a base box image. Is there some other fix/workaround that is appropriate or should I close this issue?

P.P.S. If you do write a cross platform package detect/remove/install script, let me know, I could use it for several of my projects. I'd like to check for all the build requirements so I don't get as many, "this failed to compile" issues. So far I've only written something primitive for yum systems, which looks like:

#!/bin/bash 

if [ `id -u` != 0 ]; then
  tput sgr0; tput setaf 1
  printf "\nRoot permissions are required to install this project.\n\n"
  tput sgr0
  exit 1
fi

PACKAGES=( patch httpd mod_ssl mod_wsgi mysql-devel openssl-devel libffi-devel python-pip python-ply python-devel python-pycparser python-memcached python-dateutil python-dateutil15 python-crypto2.6 MySQL-python pyOpenSSL )
for pkg in "${PACKAGES[@]}"
  do
    TEST=`rpm -q --whatprovides $pkg`
    if [ "$?" -gt 0 ]
    then
		echo "Installing $pkg missing"
		yum --assumeyes --enablerepo=epel install $pkg
    fi
done

[fnordfish]

@ladar I agree, vbguest should probably try to remove/cleaup packaged installs by itself - again not putting any requirements on the boxes since they can't be "enforced" anyways :)
Just fyi: vbguest has specific "scripts" per platform, having a single cross platform script didn't work out. So, I've double checked we do have a "cleanup" step for Ubuntu. We'd need to get that kind of stuff migrated for all other platforms.
Anyways, look around that directory for which dependencies we install on which platform

[attila123]

OK, thanks for discussing the issue, so based on the comments I am closing this issue here as there is an agreement that the issue should be solved in vagrant-vbguest plugin.