Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vagrant-vbguest doesn't work with vagrant-reload #333

Closed
ethanmdavidson opened this issue Apr 18, 2019 · 31 comments
Closed

vagrant-vbguest doesn't work with vagrant-reload #333

ethanmdavidson opened this issue Apr 18, 2019 · 31 comments

Comments

@ethanmdavidson
Copy link

@ethanmdavidson ethanmdavidson commented Apr 18, 2019

Recently upgraded virtualbox from 6.0.4 to 6.0.6. The box I'm using was built with 6.0.4 guest additions, so when I next upped the box, vbguest attempted to install the new guest addition. However, it doesn't seem to install correctly. At the very end of vagrant up, I see the following output:

[devapp] GuestAdditions seems to be installed (6.0.6) correctly, but not running.
Redirecting to /bin/systemctl start vboxadd.service
Redirecting to /bin/systemctl start vboxadd-service.service
bash: line 4: setup: command not found
==> devapp: 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

and vagrant vbguest --status reports:

[devapp] GuestAdditions seems to be installed (6.0.6) correctly, but not running.

However, when I comment out devapp.vm.provision :reload the vagrant up performs perfectly, although it seems that virtualbox is not reporting its version correctly:

PS> vagrant vbguest --status
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims:   6.0.4
VBoxService inside the vm claims: 6.0.6
Going on, assuming VBoxService is correct...
[devapp] GuestAdditions 6.0.6 running --- OK.

but VirtualBox is reporting 6.0.6 when I open the program and check its "about" section:

VirtualBox Graphical User Interface
Version 6.0.6 r130049 (Qt5.6.2)
Copyright © 2019 Oracle Corporation and/or its affiliates. All rights reserved.

It is installing from the local .iso file, rather than downloading anything. The vagrantfile having this issue is fairly large and logs a lot of stuff while upping, so I won't post it here. I'll try to put together a simple example that demonstrates this issue.

Host details:

  • Windows 10
  • VirtualBox 6.0.6
  • Vagrant 2.2.4

Guest details:

@byronclark

This comment has been minimized.

Copy link

@byronclark byronclark commented Apr 19, 2019

I'm seeing the same issue using an Ubuntu 16.04 guest. My guess is that something is broken in the VirtualBox 6.0.6 guest additions installer.

@alvaro-canepa

This comment has been minimized.

Copy link

@alvaro-canepa alvaro-canepa commented Apr 20, 2019

I have the same issue with Homestead and Virtualbox 6.0.6.

Adding this to Vagrantfile solve the problem:

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

This comment has been minimized.

Copy link

@brianmowens brianmowens commented Apr 20, 2019

Confirming that I am also seeing this same issue. Same error message as posted by @ethanmdavidson

Host OS: Windows 10
Vagrant: 2.2.4
VirtualBox: 6.0.6 r130049 (Qt5.6.2)
Box: ubuntu/xenial64 - 20190419.0.0

@carlosefr

This comment has been minimized.

Copy link
Contributor

@carlosefr carlosefr commented Apr 22, 2019

I'm seeing the same thing with CentOS as guest.

@carlosefr

This comment has been minimized.

Copy link
Contributor

@carlosefr carlosefr commented Apr 22, 2019

At a first glance, it seems like find_tool isn't finding vboxadd here:

communicate.sudo("#{find_tool('vboxadd')} setup", opts, &block)

The search directories indeed don't include any path where vboxadd may be found. Compare the paths in the code:

candidates = [
"/usr/lib/i386-linux-gnu/VBoxGuestAdditions/#{tool}",
"/usr/lib/x86_64-linux-gnu/VBoxGuestAdditions/#{tool}",
"/usr/lib64/VBoxGuestAdditions/#{tool}",
"/usr/lib/VBoxGuestAdditions/#{tool}",
"/lib64/VBoxGuestAdditions/#{tool}",
"/lib/VBoxGuestAdditions/#{tool}",
"/etc/init.d/#{tool}",
]

With the paths in my VM:

$ locate vboxadd | grep 'vboxadd$'
/etc/kernel/postinst.d/vboxadd
/etc/kernel/prerm.d/vboxadd
/opt/VBoxGuestAdditions-6.0.6/init/vboxadd
/usr/sbin/rcvboxadd
@carlosefr

This comment has been minimized.

Copy link
Contributor

@carlosefr carlosefr commented Apr 22, 2019

Adding this to the Vagrantfile works somewhat, as the error doesn't appear in the first boot:

    config.vm.provision "shell", inline: 'test -x /usr/bin/VBoxControl -a ! -d /lib/VBoxGuestAdditions && ' \
                                         'ln -s /opt/VBoxGuestAdditions-$(VBoxControl version | ' \
                                         'perl -ne \'print $1 if /Version\s+([^\s]+)$/i\')/init /lib/VBoxGuestAdditions'

However, it always builds the modules. Seems like the proper option to vboxadd is now quicksetup instead of setup.

@cvquesty

This comment has been minimized.

Copy link

@cvquesty cvquesty commented Apr 22, 2019

Interesting. In ssh'ing to the child, I manually look for and run the command, and vboxadd complains it doesn't have that option. Trying to nail down the specifics on this one. I had to remove the vagrant-vaguest plugin for the time being so I can work but help certainly appreciated on this one.

@haxorof

This comment has been minimized.

Copy link

@haxorof haxorof commented Apr 22, 2019

I bumped into the same issue in centos/7 and it seems that the first installation works as expected. However, if you reload then vagrant-vbguest prints that the guest additions is in fact install but not running:

[default] GuestAdditions seems to be installed (6.0.6) correctly, but not running.

Debug output:

DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: VBoxService --version (sudo=true)
DEBUG ssh: stderr: 41e57d38-b4f7-4e46-9c38-13873d338b86-vagrant-ssh
DEBUG ssh: Exit status: 0
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: lsmod | grep vboxsf (sudo=true)
DEBUG ssh: stderr: 41e57d38-b4f7-4e46-9c38-13873d338b86-vagrant-ssh
DEBUG ssh: Exit status: 1
DEBUG vbguest-machine: Current states for VM 'default' are : guest_version=6.0.6 : host_version=6.0.6 : running=false
DEBUG vbguest-machine: Running command rebuild from runlist
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute:         for c in /usr/lib/i386-linux-gnu/VBoxGuestAdditions/vboxadd /usr/lib/x86_64-linux-gnu/VBoxGuestAdditions/vboxadd /usr/lib64/VBoxGuestAdditions/vb
oxadd /usr/lib/VBoxGuestAdditions/vboxadd /lib64/VBoxGuestAdditions/vboxadd /lib/VBoxGuestAdditions/vboxadd /etc/init.d/vboxadd; do
          if test -x "$c"; then
            echo $c
            break
          fi
        done
 (sudo=true)
DEBUG ssh: stderr: 41e57d38-b4f7-4e46-9c38-13873d338b86-vagrant-ssh
DEBUG ssh: Exit status: 0
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute:  setup (sudo=true)
DEBUG ssh: stderr: 41e57d38-b4f7-4e46-9c38-13873d338b86-vagrant-ssh
DEBUG ssh: stderr: bash: line 4: setup: command not found

In the above log it is visible that lsmod is used to determine if it is running or not. Looking at that lsmod at the time it failed it look like this:

[vagrant@localhost ~]$ lsmod | grep vbox
vboxvideo              35874  1
ttm                   114635  1 vboxvideo
drm_kms_helper        179394  1 vboxvideo
drm                   429744  4 ttm,drm_kms_helper,vboxvideo
vboxguest             347610  1

So I did a small change in how running state is determined for linux into this:

communicate.test('lsmod | egrep "vboxsf|vboxguest"', opts, &block)

Then it determines guest additions is running and everything seems to work and after boot the lsmod looks like this:

[vagrant@localhost ~]$ lsmod | grep vbox
vboxsf                 81012  1
vboxvideo              35874  1
ttm                   114635  1 vboxvideo
drm_kms_helper        179394  1 vboxvideo
vboxguest             347610  2 vboxsf
drm                   429744  4 ttm,drm_kms_helper,vboxvideo

Hope this will give some more info to quickly resolve the issue. 😄

Cheers!

@carlosefr

This comment has been minimized.

Copy link
Contributor

@carlosefr carlosefr commented Apr 22, 2019

So there seems to be two problems here, because with @haxorof's fix, the original problem will still appear if the VM's kernel is upgraded after the initial installation (it will try to rebuild, and will fail).

@carlosefr

This comment has been minimized.

Copy link
Contributor

@carlosefr carlosefr commented Apr 22, 2019

Just a thought: I believe checking for a loaded vboxguest doesn't allow to conclude that the additions are running, because isn't that module included out-of-the-box in most distros?

@haxorof

This comment has been minimized.

Copy link

@haxorof haxorof commented Apr 22, 2019

@carlosefr : Might be that it is not safe to look for just vboxguest. I have just checked in CentOS right now.

To handle the kernel upgrade it might be necessary to also look for /sbin/rcvboxadd which is a symbolic link and it works with the setup argument

[vagrant@localhost ~]$ file /sbin/rcvboxadd
/sbin/rcvboxadd: symbolic link to `/opt/VBoxGuestAdditions-6.0.6/init/vboxadd'

[vagrant@localhost ~]$ sudo /sbin/rcvboxadd setup
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel
modules.  This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Building the modules for kernel
3.10.0-957.5.1.el7.x86_64.
VirtualBox Guest Additions: Running kernel modules will not be replaced until
the system is restarted
@carlosefr

This comment has been minimized.

Copy link
Contributor

@carlosefr carlosefr commented Apr 22, 2019

Perhaps it would be better to look for the vboxsf.ko file on disk, for the running kernel. If not present, then rebuild and restart, otherwise try to restart the service (or wait, because what might be happening is that the service is still starting when the check is performed).

Or check both for a loaded vboxguest and the presence of vboxsf.ko on disk for the running kernel. This might make it safe to assume that the loaded vboxguest indeed comes from the guest additions (except on the first boot right after installing them).

i.e.

communicate.test('lsmod | egrep "vboxsf|vboxguest" && test -f /lib/modules/$(uname -r)/misc/vboxsf.ko', opts, &block)
@haxorof

This comment has been minimized.

Copy link

@haxorof haxorof commented Apr 22, 2019

Might be safe enougth yes.

I looked into the /sbin/rcvboxadd file to see how it determines running state add it is a bit odd that function running_vboxsf is defined but never used in the script. 😄 Only running_vboxguestand running_vboxadd is used what I can see.

running_vboxguest()
{
    lsmod | grep -q "vboxguest[^_-]"
}

running_vboxadd()
{
    lsmod | grep -q "vboxadd[^_-]"
}

running_vboxsf()
{
    lsmod | grep -q "vboxsf[^_-]"
}

running_vboxvideo()
{
    lsmod | grep -q "vboxvideo[^_-]"
}
@haxorof

This comment has been minimized.

Copy link

@haxorof haxorof commented Apr 22, 2019

FYI, just checked some Ubuntu and Debian version what it looks when running lsmod:

vagrant@ubuntu-xenial:~$ lsmod | grep vbox
vboxsf                 77824  2
vboxguest             331776  2 vboxsf
vboxvideo              40960  1
drm_kms_helper        155648  1 vboxvideo
ttm                    98304  1 vboxvideo
drm                   364544  4 ttm,drm_kms_helper,vboxvideo
vagrant@stretch:~$ lsmod | grep vbox
vboxsf                 77824  1
vboxvideo              36864  1
ttm                    98304  1 vboxvideo
drm_kms_helper        155648  1 vboxvideo
vboxguest             327680  2 vboxsf
drm                   360448  4 vboxvideo,ttm,drm_kms_helper
@carlosefr

This comment has been minimized.

Copy link
Contributor

@carlosefr carlosefr commented Apr 22, 2019

Opened PR #334, which seems to work for CentOS 7 and Debian 9.

@danepowell

This comment has been minimized.

Copy link

@danepowell danepowell commented Apr 25, 2019

@mowens3

This comment has been minimized.

Copy link

@mowens3 mowens3 commented Apr 26, 2019

I'm using the following steps to resolve this error on Ubuntu 18.04:

  1. navigate to problematic vagrant directory and uninstall vbguest:

vagrant plugin uninstall vagrant-vbguest

  1. Add the following code to the respective Vagrantfile (credit to @alvaro-canepa)
if Vagrant.has_plugin?("vagrant-vbguest")
    config.vbguest.auto_update = false
end
  1. run the following:
    vagrant halt
    vagrant up

everything should work at this point.

@LukaszFormela

This comment has been minimized.

Copy link

@LukaszFormela LukaszFormela commented Apr 29, 2019

If none of the above worked for you, try downgrading vbguest to lower version, that worked for me on VB 6.0.6, Vagrant 2.2.4 and debian/jessie64:

vagrant up (if it doesn't start, follow it by vagrant reload)
vagrant ssh
sudo su
cd /tmp
wget http://download.virtualbox.org/virtualbox/5.2.30/VBoxGuestAdditions_5.2.30.iso
mkdir /media/VBoxGuestAdditions
mount -o loop,ro VBoxGuestAdditions_5.2.29-130064.iso /media/VBoxGuestAdditions
sh /media/VBoxGuestAdditions/VBoxLinuxAdditions.run
rm VBoxGuestAdditions_5.2.29-130064.iso
umount /media/VBoxGuestAdditions
rmdir /media/VBoxGuestAdditions
exit
exit

In your Vagrantfile add the following:

config.vbguest.auto_update = false

Then do another vagrant reload.

@carlosefr

This comment has been minimized.

Copy link
Contributor

@carlosefr carlosefr commented Apr 29, 2019

The 6.0.6 guest additions don't seem to support that kernel (either a regression, or a drop in support). That's an issue for the virtualbox bug tracker, I guess.

@xurizaemon

This comment has been minimized.

Copy link

@xurizaemon xurizaemon commented May 2, 2019

Ran into this also with VirtualBox 6.0.6. For the time being, removing vagrant-vbguest seems to have resolved the issue.

Before doing so, booting gave the "setup: command not found" error and the VM would run but be missing any synced_folders.

After vagrant plugin uninstall vagrant-vbguest, the VM booted and had synced folders once more.

EDIT: Unclear if this has provided a complete fix, as I'm now getting "insufficient permission" errors from git in a synced folder within the VM, despite apparently correct permissions.

@StoyanIvanovI

This comment has been minimized.

Copy link

@StoyanIvanovI StoyanIvanovI commented May 6, 2019

I ended up having to downgrade to VirtualBox 5.2.28 due to issues with shared folder permissions with any of the solutions above. This is definitely a bug with Guest Additions and potentially VirtualBox 6.0.6.

@xkrt

This comment has been minimized.

Copy link

@xkrt xkrt commented May 15, 2019

Same problem with fresh VBox/GuestAdds v6.0.8

@DonTermi

This comment has been minimized.

Copy link

@DonTermi DonTermi commented May 16, 2019

@LukaszFormela

wget https://www.virtualbox.org/download/testcase/VBoxGuestAdditions_5.2.29-130064.iso

The requested URL /download/testcase/VBoxGuestAdditions_5.2.29-130064.iso was not found.

@LukaszFormela

This comment has been minimized.

Copy link

@LukaszFormela LukaszFormela commented May 16, 2019

@LukaszFormela

wget https://www.virtualbox.org/download/testcase/VBoxGuestAdditions_5.2.29-130064.iso

The requested URL /download/testcase/VBoxGuestAdditions_5.2.29-130064.iso was not found.

Try this one instead:
http://download.virtualbox.org/virtualbox/5.2.30/VBoxGuestAdditions_5.2.30.iso

@robnagler

This comment has been minimized.

Copy link
Contributor

@robnagler robnagler commented May 16, 2019

One of the problems is the name of the kernel module has changed to vboxguest. Another problem is that vboxadd is now rcvboxadd. The patch below works for us, because we only run CentOS 7 and Fedora. It's not a general fix.

*** .vagrant.d/gems/2.4.4/gems/vagrant-vbguest-0.17.2/lib/vagrant-vbguest/installers/linux.rb~  2019-05-09 12:26:46.000000000 -0600
--- .vagrant.d/gems/2.4.4/gems/vagrant-vbguest-0.17.2/lib/vagrant-vbguest/installers/linux.rb   2019-05-16 15:54:59.000000000 -0600
***************
*** 78,84 ****
          opts = {
            :sudo => true
          }.merge(opts || {})
!         communicate.test('lsmod | grep vboxsf', opts, &block)
        end

        # This overrides {VagrantVbguest::Installers::Base#guest_version}
--- 78,84 ----
          opts = {
            :sudo => true
          }.merge(opts || {})
!         communicate.test('systemctl is-active vboxadd-service.service', opts, &block)
        end

	# This overrides {VagrantVbguest::Installers::Base#guest_version}
***************
*** 111,117 ****
	# @yieldparam [String] type Type of the output, `:stdout`, `:stderr`, etc.
	# @yieldparam [String] data Data for the given output.
	def rebuild(opts=nil, &block)
!         communicate.sudo("#{find_tool('vboxadd')} setup", opts, &block)
	end

	# @param opts [Hash] Optional options Hash wich meight get passed to {Vagrant::Communication::SSH#execute} and firends
--- 111,117 ----
	# @yieldparam [String] type Type of the output, `:stdout`, `:stderr`, etc.
	# @yieldparam [String] data Data for the given output.
	def rebuild(opts=nil, &block)
!         communicate.sudo("/sbin/rcvboxadd setup", opts, &block)
	end

	# @param opts [Hash] Optional options Hash wich meight get passed to {Vagrant::Communication::SSH#execute} and firends
@carlosefr

This comment has been minimized.

Copy link
Contributor

@carlosefr carlosefr commented May 17, 2019

@robnagler The vboxguest module has always existed (vboxsf depends on it), but what I think may have happened (I haven't checked) is that vboxadd stopped loading vboxsfwhen starting, instead deferring it to the moment when shared folders are mounted.

I didn't check for vboxadd being started on PR #334 because, as you mentioned, that would make it distribution specific.

@robnagler

This comment has been minimized.

Copy link
Contributor

@robnagler robnagler commented May 17, 2019

@carlosefr got it, thanks. In #334 I wonder why you wouldn't also try systemctl is-active vboxadd-service.service, too. If the structure of the kernel modules changes, the higher level tests will probably still work.

@fnordfish

This comment has been minimized.

Copy link
Member

@fnordfish fnordfish commented May 20, 2019

released #334 as v0.18.0

I'm closing this issue. If there's anything new, please feel free to reopen this one or create a new issue.

@artlung

This comment has been minimized.

Copy link

@artlung artlung commented Jun 20, 2019

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

...made this work for me. Vagrant version 2.2.4, MacOS 10.14.5

@nskgit

This comment has been minimized.

Copy link

@nskgit nskgit commented Jun 25, 2019

'vagrant plugin update' needs an update

@longyue0521

This comment has been minimized.

Copy link

@longyue0521 longyue0521 commented Oct 16, 2019

vagrant plugin update worked for me! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.