Closed thokari closed 6 years ago
jrgriffiniii
commented
6 years ago I too am encountering this error when using the following:
The environment I'm trying to provision uses Ubuntu 16.04.4 LTS (Xenial Xerus) as a base image.
ostaszewskik
commented
6 years ago Same, but Vagrnt 2.1.2:
GuestAdditions versions on your host (5.2.14) and guest (5.1.34) do not match.
alexandregv
commented
6 years ago Got it fixed by giving the VBoxGuestAdditions file to use.
You can do this by adding this to your Vagrantfile:
config.vbguest.iso_path = "./VBoxGuestAdditions_5.2.14.iso"(assuming you downloaded the file and placed it in same folder than Vagrantfile)
You can also use an url, like this:
config.vbguest.iso_path = "https://download.virtualbox.org/virtualbox/5.2.14/VBoxGuestAdditions_5.2.14.iso"All versions can be found here: https://download.virtualbox.org/virtualbox/
mskonovalov
commented
6 years ago Seems like a bug: it worked well (almost) for VBox 5.1.x but doesn't for 5.2.x.
I have VDGuestAdditions 5.1.34 inside the box. With first run:
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 5.1.34
VBoxService inside the vm claims: 5.2.14
Going on, assuming VBoxService is correct...
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 5.1.34
VBoxService inside the vm claims: 5.2.14
Going on, assuming VBoxService is correct...then it seems like installing something but then after vagrant box reload I see
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 5.0.18
VBoxService inside the vm claims: 5.2.14
Going on, assuming VBoxService is correct...
[default] GuestAdditions 5.2.14 running --- OK.
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 5.0.18
VBoxService inside the vm claims: 5.2.14
Going on, assuming VBoxService is correct...So... It uninstalled 5.1.34 and was not able to install 5.2.14 so it stayed on even older 5.0.18 for some reason
P.s. Vagrant 2.1.1, Ubuntu xenial
fnordfish
commented
6 years ago Hi all, I try to shed some light into what's going on...
Vbguest uses two ways of detecting the running version of GuestAdditions inside the box:
One note about the "Got different reports about installed GuestAdditions version": This might be a bug in Virtualbox or in the Virtualbox GuestAdditions, which fail to update the virtual machines config files. Yes, this is annoying, but there's is nothing (to my knowledge) vbguest can do about it. That's why vbguest just logs what it sees and carries on without doing something. If you believe, that there's still an incorrect GuestAddition running inside your box, try to find out if there are additional installations and get rid of them (see last paragraph).
Vbguest has no direct effect of which version of the GuestAdditions will be installed, because it trusts that the available "iso" will contain the correct version. If for whatever reason, your local "iso" file contains an incorrect version, this is going to be installed. Last time I've checked, there has been no way of asking the GuestAdditions installer about it's version (which would be great so that vbguest could detect this situation). One way of making sure, that an up-to-date version is used is, to delete the local "iso" file and let vbguest download the versioned file from the web. Of course, you can also manually download the GuestAdditions iso file and replace your local copy with it.
Base boxes often come with pre-installed GuestAdditions, usually some form of distribution packages. The GuestAdditions installer should warn you about this, if it can detect it. However, it might just continue installing, leaving the other version installed and/or active. Try to purge all pre-installed GuestAdditions using whatever your guest systems way of managing packages is.
mskonovalov
commented
6 years ago I think the problem is vbguest unintalled old version of Additions but then failed to install newer one. So with next run it has lower version than before
mskonovalov
commented
6 years ago Verifying archive integrity... All good.
Uncompressing VirtualBox 5.2.14 Guest Additions for Linux........
VirtualBox Guest Additions installer
Copying additional installer modules ...
Installing additional modules ...
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel modules. This may take a while.
This system is currently not set up to build kernel modules.
Please install the Linux kernel "header" files matching the current kernel
for adding new hardware support to the system.
The distribution packages containing the headers are probably:
linux-headers-generic linux-headers-4.4.0-130-generic
VirtualBox Guest Additions: Starting.
Job for vboxadd-service.service failed because the control process exited with error code. See "systemctl status vboxadd-service.service" and "journalctl -xe" for detailBut when i ssh inside and check Guest Additions version it is 5.2.14
cbj4074
commented
6 years ago @fnordfish Thanks for the detailed explanation; that's very helpful.
You note the following:
Vbguest uses two ways of detecting the running version of GuestAdditions inside the box:
- Ask vagrant. Which will execute a Virtualbox command on your host. (That's the "Virtualbox on your host claims" part) Since this information is outdated some times (see @mskonovalov 's comment), we use the second step:
Are you able to elaborate as to exactly which VirtualBox command is executed on the host?
I ask because VBoxManage showvminfo vmname outputs the following, which is the correct version:
Additions version: 5.2.18 r124319But maybe this comes from the installed .iso file on the host, and not from the actual/running VM.
When booting the VM, I see this:
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 5.2.12
VBoxService inside the vm claims: 5.2.18
Going on, assuming VBoxService is correct...From where does this 5.2.12 originate, if not from VBoxManage showvminfo vmname?
Maybe it comes from VBoxManage guestproperty enumerate vmname? I do notice that this command seems to return different (and seemingly incorrect) info:
> VBoxManage guestproperty enumerate homestead-7
Name: /VirtualBox/GuestInfo/OS/Product, value: Linux, timestamp: 1534786112564171000, flags:
Name: /VirtualBox/HostInfo/GUI/LanguageID, value: en_US, timestamp: 1535472011998811400, flags: RDONLYGUEST
Name: /VirtualBox/HostInfo/VBoxVerExt, value: 5.2.18, timestamp: 1535461643758139302, flags: TRANSIENT, RDONLYGUEST
Name: /VirtualBox/GuestInfo/OS/Version, value: #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018, timestamp: 1534786112564534000, flags:
Name: /VirtualBox/GuestAdd/VersionExt, value: 5.2.12, timestamp: 1534786112568335000, flags:
Name: /VirtualBox/GuestAdd/Revision, value: 122591, timestamp: 1534786112568474000, flags:
Name: /VirtualBox/HostGuest/SysprepExec, value: , timestamp: 1535461643757639200, flags: TRANSIENT, RDONLYGUEST
Name: /VirtualBox/HostGuest/SysprepArgs, value: , timestamp: 1535461643758139300, flags: TRANSIENT, RDONLYGUEST
Name: /VirtualBox/GuestAdd/Version, value: 5.2.12, timestamp: 1534786112566371000, flags:
Name: /VirtualBox/HostInfo/VBoxRev, value: 124319, timestamp: 1535461643758139303, flags: TRANSIENT, RDONLYGUEST
Name: /VirtualBox/HostInfo/VBoxVer, value: 5.2.18, timestamp: 1535461643758139301, flags: TRANSIENT, RDONLYGUEST
Name: /VirtualBox/GuestInfo/OS/Release, value: 4.15.0-29-generic, timestamp: 1534786112564436000, flags:Executing the following command from within the VM returns the correct version (see: https://www.linuxquestions.org/questions/linux-virtualization-and-cloud-90/how-to-check-version-of-virtualbox-guest-additions-currently-installed-in-guest-syste-946053/#post4771129 ):
lsmod | grep -io vboxguest | xargs modinfo | grep -iw version
Hmm... so where might the disconnect reside?
fnordfish
commented
6 years ago @cbj4074 We basically run driver.read_guest_additions_version, which is the same thing Vagrant does in it's CheckGuestAdditions middleware.
The "driver" is a bit complicated and depends on the version. For Virtualbox >=5.0, that should be https://github.com/hashicorp/vagrant/blob/master/plugins/providers/virtualbox/driver/version_5_0.rb#L456
It seems like, it first runs VBoxManage guestproperty get <UUID> /VirtualBox/GuestAdd/Version and uses something after Value:.
If that did not work, it runs VBoxManage showvminfo <UUID> --machinereadable and looks for something after GuestAdditionsVersion=
cbj4074
commented
6 years ago @fnordfish Again, very helpful! Thank you for verifying!
Indeed, this does produce incorrect results:
VBoxManage guestproperty get homestead-7 /VirtualBox/GuestAdd/Version
Value: 5.2.12Interestingly, the second method returns the correct, installed version:
VBoxManage showvminfo homestead-7 --machinereadable
...
GuestAdditionsVersion="5.2.18 r124319"Is it possible to change vagrant-vbguest to prefer the second method instead, when it performs the comparison?
Maybe there are other side-effects of doing that, which I'm unqualified to assess... :)
fnordfish
commented
6 years ago So, I've done some digging in Vagrant's history.
Using the guestproperty seems to be to "old school" way of doing things.
The showvminfo way was added in hashicorp/vagrant#1575 for VirtualBox 4.2 as a fallback.
To answer your question, Vagrant's read_guest_additions_version doesn't allow us to pick which method to prefer. So we'd need to vendor in some code, effectively circumvent Vagrant. This is something I wanted to avoid.
However, since it's in Vagrant for around 5 years now (not sure how often it actually triggers), I'm willing to put it into vagrant-vbguest and just let's see how it plays out.
fnordfish
commented
6 years ago released in 0.16.0.beta1
cbj4074
commented
6 years ago @fnordfish Thanks so much for attempting to fix this more "permanently"! I really appreciate the effort.
I just installed 0.16.0.beta and am tickled to see this during vagrant up:
[homestead] GuestAdditions 5.2.18 running --- OK.
:+1:
It seems ideal for Vagrant to fix this more elegantly... but that's a discussion for another repo!
fnordfish
commented
6 years ago @cbj4074 Great to see that it's working :) Would you mind running it for a while and maybe checking with coworkers. If everything's fine, I'll release it as 0.16 next week
cbj4074
commented
6 years ago @fnordfish I wouldn't mind at all! And yes, I will have a few coworkers install it and "let it cook".
In the meantime, I did a bit more digging, in an effort to determine whether, at its root, this is a problem with Vagrant or VirtualBox.
In reading through https://www.virtualbox.org/manual/ch08.html#vboxmanage-guestproperty , I notice some interesting detail around how these values are set.
In short, the values handled via guestproperty are set more or less arbitrarily. Clearly, the VirtualBox Guest Additions installer does not update the value in question automatically upon running successfully.
Given this fact, there seems to be no more reliable means by which to acquire the Guest Additions info than what you're doing now (with this patch applied).
That said, it might be ideal for vagrant-vbguest to set this value accurately upon running the Guest Additions installer, provided it exits with a zero status (or however "success" is best determined).
To be clear, this doesn't benefit vagrant-vbguest at all; the idea here is simply to be more "responsible" by updating the stored value, so that other third-parties get more reliable info from guestproperty. In other words, this plugin is in a position to set the value authoritatively and accurately upon a successful run of the Guest Additions installer.
The flow would simply be:
showvminfo), as is done in 0.16.0.beta.VBoxControl guestproperty set /VirtualBox/GuestAdd/Version <version>, where <version> is the version determined in step 1 (without the revision string, of course).I just tested this, and the value does persist across VM reboots, as intended.
Of course, whether you implement this or not is up to you, but it does have a "good steward" vibe to it. :)
I'm going to ask Vagrant if it will consider swapping the order in which it makes these checks in https://github.com/hashicorp/vagrant/blob/d8ff2cb5adca25d7eba2bdd334919770316c91be/plugins/providers/virtualbox/driver/version_4_2.rb#L256 , such that it tries showvminfo before guestproperty.
If the developers oblige, then you can probably revert this fix, but it would still be worth updating /VirtualBox/GuestAdd/Version, regardless, in my humble opinion.
I'll let you know what they say!
fnordfish
commented
6 years ago No complaints, so I'm just assuming everything works ok. Released as 0.16.0
cbj4074
commented
6 years ago @fnordfish Yes, everything seems to work okay; we haven't noticed any issues with your changes.
That said, I would still encourage you to consider implementing the small, additional change I noted previously. ;)
Either way, thanks again for fixing this!
Pictor13
commented
5 years ago Just reporting the solution for my case where I wasn't able to update and get rid of the old GuestAdditions version.
I found out that VirtualBox wasn't able to mount the GuestAdditions ISO on the virtual device. Not sure why vbguest didn't download from remote.
Anyway I created a SCSI device, put a CDrom in it and loaded the GuestAdditions.iso (taken from https://download.virtualbox.org/virtualbox/ ). Others needed to leave it empty and then choose "Device" -> "Insert GuestAdditions ISO". Virtualbox wasn't able to mount it for real, so no chance to install the new version.
However I manually mounted the CDrom with sudo su && mount /dev/cdrom /media/cdrom and then I was able to manually find and run the installer with sh VBoxLinuxAdditions.run.
Now the installation started correctly and finally removed the old version of GuestAdditions, installing correctly the new one.
Not sure why that happens. In my case I updated macOS and found out I had to update Virtualbox and, consequentially, the GuestAdditions. So not uninstalling first maybe created the problem 🤷♂️
fnordfish
commented
5 years ago I found out that VirtualBox wasn't able to mount the GuestAdditions ISO on the virtual device. Not sure why vbguest didn't download from remote.
Well, that's interesting. Have there been any logs indicating why it couldn't mount the iso? The "download from remote" will just download the "same" ISO file again. vbguest assumes, that the file in your local virtual box installation is good and saves some time (and bandwidth) by using the local version.
Pictor13
commented
5 years ago I got just an insight that that could have been the problem with vbguest just when I tried to install manually and got the VERR_PDM_MEDIA_LOCKED error; the only other evidence before was that under /media there was nothing mounted.
The log (coming from running vagrant reload, in the terminal) was:
default: Warning: Connection reset. Retrying... ==> default: Machine booted and ready! [default] GuestAdditions versions on your host (5.2.26) and guest (5.1.26) do not match. Loading repository data... Reading installed packages... 'pattern:devel_C_C++' is already installed. No update candidate for 'pattern:devel_C_C++-20170518-6.1.x86_64'. The highest available version is already installed. 'pattern:devel_basis' is already installed. No update candidate for 'pattern:devel_basis-20170518-6.1.x86_64'. The highest available version is already installed. 'pattern:devel_kernel' is already installed. No update candidate for 'pattern:devel_kernel-20170518-6.1.x86_64'. The highest available version is already installed. Resolving package dependencies...
Nothing to do. ==> default: Checking for guest additions in VM... default: The guest additions on this VM do not match the installed version of default: VirtualBox! In most cases this is fine, but in rare cases it can default: prevent things such as shared folders from working properly. If you see default: shared folder errors, please make sure the guest additions within the default: virtual machine match the version of VirtualBox you have installed on default: your host and reload your VM. default: default: Guest Additions Version: 5.1.26 default: VirtualBox Version: 5.2
Just the generic info but it couldn't report to have a specific issue with mounting.
When I started to do the updating steps manually then it become clearer...
fnordfish said:
The "download from remote" will just download the "same" ISO file again. vbguest assumes, that the file in your local virtual box installation is good and saves some time (and bandwidth) by using the local version.
Yes it makes sense; also given that their file doesn't specify any version. Even if I don't understand why that local version present was not taken for the installation. I checked with "Show package content" on the Mac application and the VBoxGuestAdditions.iso is inside there. I highly doubt that the VirtualBox 5.2 installation contains an old 5.1 version of it. However I didn't use the one contained in the application package but the one downloaded from virtualbox.org.
Also, I read just now triinoxys's answer, so in my case I didn't use the config.vbguest.iso_path setting to locate the ISO, as he suggested, and I am not sure what vbguest was able to locate without that.
fnordfish
commented
5 years ago config.vbguest.iso_path is an overwrite. vbguest utilizes Vagrant internals to look for you local installation of Virtual Box, on MacOS the iso is usually at /Applications/VirtualBox.app/Contents/MacOS/VBoxGuestAdditions.iso.
Pictor13
commented
5 years ago Mmmh, then I cannot guess why that was not used..
I'm actually not so good with Python, but taking a random look at the code I can think just of 3 2 options:
media_manager_iso returns something and that's used instead (but I cannot find any cached file or alternative path that could be taken; and the only GuestAdditions I have on host and that I could have loaded is the version 5.2.26).NotImplementedError is not being raised, hence no log. Could be that vagrant or puppet are swallowing the error and it is not being shown.Not sure why, but last one feels like the most probable to me.
fnordfish
commented
5 years ago I'm actually not so good with Python
That's because it's ruby :D
Let me describe how iso detection works. It start's at the local_path method which will try 2 things.
VirtualBox usually has the guest additions iso already available as a virtual dvd, that's what the media_manager_iso is for. It tries to find that virtual dvd and read it's setting for the used file path.
If the virtual dvd cannot be found, vbguest has a list of known paths for different host operation systems which it will go through and check if it can find a file. That's in linux_path, darwin_path and windows_path
So, if there was no file found you should get at least an info log like Copy iso file into the box /tmp/VBoxGuestAdditions.iso (where it should include the source file used, like Copy iso file /Applications/VirtualBox.app/Contents/MacOS/VBoxGuestAdditions.iso into the box /tmp/VBoxGuestAdditions.iso)
To me it also looks like the installation got triggered, since you see those Loading repository data... and pattern:devel_C_C++ log lines which indicate some Suse dependencies getting installed by vbguest.
Still a bit of a mystery
Pictor13
commented
5 years ago fnordfish says
That's because it's ruby :D
Damn.. 😑 Today I woke up and the same realisation randomly popped up in my mind while having breakfast ☕️ Actually I am even worse there, never touched ruby before 😅
So, if there was no file found you should get at least an info log like
Copy iso file into the box /tmp/VBoxGuestAdditions.iso(where it should include the source file used, likeCopy iso file /Applications/VirtualBox.app/Contents/MacOS/VBoxGuestAdditions.iso into the box /tmp/VBoxGuestAdditions.iso)
I just extracted it manually from the .app and tried to install it; can confirm it is the correct v5.2.26. Given that the CD wasn't mounted, I suppose that vbguest found it.
To me it also looks like the installation got triggered, since you see those
Loading repository data...andpattern:devel_C_C++log lines which indicate some Suse dependencies getting installed by vbguest. Still a bit of a mystery
That's right... 🤔
Doubt: looking at the code (and just-guessing on the fly how polymorphism works in ruby) in my case opensuse.rb's install function calls the super, so from there I would expect the log from the first instruction
that in my log doesn't appear. Did I misinterpret something? If that log doesn't show then could it be that the following commands don't run as well?
fnordfish
commented
5 years ago
- "The guest's platform ("%{distro}") is currently not supported, will try generic Linux method..."
that in my log doesn't appear.
That's totally fine and intended.
There's a conditional hidden at the very end of that log line if self.class == Linux (in ruby you can put conditionals for single expressions at the end of the line).
This condition will evaluate to false if it's called from a inherited class, in your specific case Suseand only to true if we'd use the Linux class directly (basically for every other Linux we don't have a matching overwrite/specialization for).
If you want to really see which commands have been run, you'd need to run vagrant in debug mode - which will output a lot of information but in particular each and every ssh command vbguest runs on the guest. vbguest itself will also give some additional debug output in some cases.
qkdreyer
commented
5 years ago I'm still having the same issue.
debian/stretch64vagrant -v)VBoxManage -version)vagrant plugin list)vagrant vbguest
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 5.2.8
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: 5.2.8
VBoxService inside the vm claims: 6.0.8
Going on, assuming VBoxService is correct...
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 5.2.8
VBoxService inside the vm claims: 6.0.8
Going on, assuming VBoxService is correct...
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: Kernel headers not found for target kernel
4.15.18-16-pve. Please install them and execute
/sbin/rcvboxadd setup
VirtualBox Guest Additions: Running kernel modules will not be replaced until
the system is restarted
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 5.2.8
VBoxService inside the vm claims: 6.0.8
Going on, assuming VBoxService is correct...
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 5.2.8
VBoxService inside the vm claims: 6.0.8
Going on, assuming VBoxService is correct...
Guest Additions got installed. However, they seem not be loaded correctly. Please restart the box running `vagrant reload default`VBoxManage guestproperty get debian-stretch64_default_1561124161933_73383 /VirtualBox/GuestAdd/Version
No value set!VBoxManage showvminfo debian-stretch64_default_1561124161933_73383 --machinereadable | grep Version
GuestAdditionsVersion="5.2.8_KernelUbuntu r120774"Even by forcing iso with config.vbguest.iso_path = "https://download.virtualbox.org/virtualbox/6.0.8/virtualbox-6.0_6.0.8-130520~Debian~stretch_amd64.deb" I'm having the same issue
qkdreyer
commented
5 years ago Nevermind, I forgot the read the output from /sbin/rcvboxadd setup which was pretty straighforward :
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: Kernel headers not found for target kernel
4.15.18-16-pve. Please install them and execute
/sbin/rcvboxadd setup
VirtualBox Guest Additions: Running kernel modules will not be replaced until
the system is restartedFixed it by running the following in the guest :
apt install pve-headers
/sbin/rcvboxadd setupAnd a quick vagrant reload from the host !
vagrant vbguest
[default] GuestAdditions 6.0.8 running --- OK.
Anutrix
commented
1 year ago I'm still having the same issue but on Windows 11.
This is the output I am getting on a Debian9 Box using VirtualBox 5.2.6 and latest Vagrant:
And then I am getting an error message about the
vagrantshared folder not being able to be configured. Its funny because it saysRemoving installed version 5.1.28 of VirtualBox Guest Additions...first. But then in the end it says:Guest Additions Version: 5.1.28. I could guess this is becauseAn error occurred during installation of VirtualBox Guest Additions 5.2.6really impliesso I will now *restore* the old 5.1.28 that *was there before*. Is that maybe the case?