When I used YAST-Software Management to install Vbox 5.0, I noticed that Vbox 4.3 had not been removed from the system.
So I reopen YAST and removed Vbox 4.3.
Sometime later, when running Vbox 5.0, I noticed that some of my external (plug-in) USB devices were not visible for connection within the Virtual Machines.
Reloading the Vbox 5.0 package in YAST resolved the problem.
My tentative conclusion is that Vbox 4.3 and Vbox 5.0 share some files that were deleted when I removed the Vbox 4.3 package.
Alas, Vbox 5.0 did not complain on startup (from GUI). Perhaps there was messaging had I started from CLI.
A better way would likely have been to remove Vbox 4.3 then reopen YAST and install the Vbox 5.0 package.
I think one should add that this only applies to Oracle’s packages and repo, as their package has the version (at least the first two parts) in the package name, even though different versions cannot (and must not) be co-installed as they contain overlapping files (as you suspected).
If you install openSUSE’s packages, a new version will correctly replace the older one, as the package is just called “virtualbox”.
Although I think as a “fix” it would have sufficed to just recompile the kernel module (/etc/init.d/vboxdrv setup), the other files should have been completely overwritten by the new versions.
Anyway, it’s definitely nicer to remove the older version first, than to have both installed but only one set of files. If you remove it after installing the new one, you will remove the actual files as well, although the other version will still be “installed”.
A small addendum for anyone considering upgrading from VBox 4.3.x to 5.x,
I’ve been looking at these versions and reading related documentation for the past few days…
For now (I don’t know if there will be changes in the future)
VBox 5.0 has only a few unique features like paravirtualization interface options you can select in place of the VBox hypervisor (Minimal, KVM, Hyper-V) but in general almost all the “new” features are available with installed Guest Additions.
So, except for those very few new features which may or may not be important (see VBox documentation for feature capabilities in the new interfaces. Possible improved performance is possible but questionable today) it’s probably more a convenience issue (not having to install Guest Additions in each Guest).
tsu2
I have read claims of (vastly) improved USB port thruput with the USB3 driver(which presumably would trickle down to USB2)
I was rather shocked to find how bad the USB2 performance was about a year ago, when attempting to run a “PC oscilloscope” in a Windows VM, and from there reading issues regarding streaming audio and USB.
I have not experimented much with it yet to see for myself.
In reality I only decided to move from 4.3 to 5.0 because I was wandering about the discussions for Leap 14.1 Beta in VM and most folks seemed to be talking Vbox 5.0, so sort of concluded it was time to move.
On Mon, 05 Oct 2015 17:46:01 +0000, cmcgrath5035 wrote:
> tsu2 I have read claims of (vastly) improved USB port thruput with the
> USB3 driver(which presumably would trickle down to USB2)
> I was rather shocked to find how bad the USB2 performance was about a
> year ago, when attempting to run a “PC oscilloscope” in a Windows VM,
> and from there reading issues regarding streaming audio and USB.
> I have not experimented much with it yet to see for myself.
>
> In reality I only decided to move from 4.3 to 5.0 because I was
> wandering about the discussions for Leap 14.1 Beta in VM and most folks
> seemed to be talking Vbox 5.0, so sort of concluded it was time to move.
The new “disconnectable” mode is really nice - I often run headless VMs,
and it’s nice to be able to connect the frontend if I need to diagnose
something, rather than using RDP.
Once I got 13.2 up and running I noted that virtualbox , vbox-drvr, etc all showed in the startup checklist as failed. Going into software management verified virtualbox was not installed. So I Installed virtualbox-4.3… , could not find guest additions anywhere but now only had failed beside guest-additions. Tried Oracle virtualbox-5.0 and the matching extension pack but wound up having to completely remove all virtualbox completely, and go back to virtualbox-4.3. Not sure but think virtualbox-5.0 messed with libraries because after removing it got notice that firefox addon dependency error, and libre-office dependency error.
In short, agree be careful around virtualbox versions and don’t mix them … too much headache.
I have been happy with VBox 5.0 on 13.2, once I got past the issue which started this thread.
Be careful not to mix repositories, use the openSUSE ones or the Oracle one I list, but don’t try to bounce back and forth.
The more I read, the more confused I get about when you need or don’t need the host extension and/or the client additions (in the VM).
I have been following a legacy model of always installing both, but apparently they are not always required.
On Wed, 14 Oct 2015 21:36:02 +0000, techwiz03 wrote:
> Once I got 13.2 up and running I noted that virtualbox , vbox-drvr, etc
> all showed in the startup checklist as failed. Going into software
> management verified virtualbox was not installed. So I Installed
> virtualbox-4.3… , could not find guest additions anywhere but now
> only had failed beside guest-additions. Tried Oracle virtualbox-5.0 and
> the matching extension pack but wound up having to completely remove all
> virtualbox completely, and go back to virtualbox-4.3. Not sure but
> think virtualbox-5.0 messed with libraries because after removing it got
> notice that firefox addon dependency error, and libre-office dependency
> error.
>
> In short, agree be careful around virtualbox versions and don’t mix them
> … too much headache.
I use the builds in the Virtulization: repository - they generally have
worked really well for me.
You need the “host extensions”, i.e. Oracle’s extension pack, for additional features like USB2/3 support. Right at the download page it says:
Support for USB 2.0 devices, VirtualBox RDP and PXE boot for Intel cards.
just below “VirtualBox 5.0.6 Oracle VM VirtualBox Extension Pack”.
There’s also a link to the user manual there, where it mentions this:
Additional extension packs can be downloaded which extend the functionality of the VirtualBox base package. Currently, Oracle provides the one extension pack, which can be found at http://www.virtualbox.org and provides the following added functionality:
The virtual USB 2.0 (EHCI) device; see Section 3.10.1, “USB settings”.
The virtual USB 3.0 (xHCI) device; see Section 3.10.1, “USB settings”.
I left out the descriptions here, see the user manual for details.
openSUSE does contain the guest additions and automatically installs them, so if you use an openSUSE guest, you don’t have to install them manually. But in general it’s probably advisable to install them in the guest (if only because of the video driver), but not necessary if you have no need for those features.
Thanks , Wolfi, for the detailed summary.
I have always taken the “easy route” and installed both Host extensions and Guest Additions.
A week or so I dabbled with moving back to the openSUSE Virtualization repo - and got several “repo not found” type errors for some of the dependency repos that came along with the primary (I believe I was trying the home/wolfi one to pick up Vbox 5.x)
I need to go back and resolve, or may wait until I “Leap” forward.
Well, I never even bothered to download the host extensions, as I was not missing anything.
A week or so I dabbled with moving back to the openSUSE Virtualization repo - and got several “repo not found” type errors for some of the dependency repos that came along with the primary (I believe I was trying the home/wolfi one to pick up Vbox 5.x)
The “Virtualization” repo does not have any dependencies on other repos. Btw, you can find it in YaST’s “Community Repositories” list too. Just go to “Software Repositories”, click on “add”, choose “Community Repositories”, and activate it in the upcoming list.
And you shouldn’t use my branch of virtualbox or the Virtualization repo.
That was just for testing, as I wanted to fix some issues.
I just “forgot” to remove it yet…
That’s true in general btw: better use the “official” repos like “Virtualization” than some random home: repo, unless you really know what you (or the person maintaining that home: repo) are doing.
I need to go back and resolve, or may wait until I “Leap” forward.
Leap will come with 5.0.6, so not really necessary to add a repo to get 5.0 then.
I’ll expand in case this is a “bad” idea.
I used Package Search for Virtual box for 13.2.
Vbox 4.3 is available in the standard repos, but I wanted 5.x so clicked on the Unstable list.
The Virtualization Repo option displayed for a version of 5.x, I tried 1 click install as an easy way to get the repo added and the package installed.
1 Click install wanted to add the Virtualization repo and 2 or 3 others.
A couple of the ‘2 or 3 others’ would not add - could not be found.
Perhaps 1 Click install was having a bad day.
1 Click install wanted to add the Virtualization repo and 2 or 3 others.
A couple of the ‘2 or 3 others’ would not add - could not be found.
Perhaps 1 Click install was having a bad day.
Then just deselect those “2 or 3 others”, you don’t need them.
The 1-click install tries to add all repos that the to be added one builds against.
In the case of “Virtualization” this seems to be (these are mentioned as “recommended” in the .ymp file):
[noparse]devel:languages:ocaml[/noparse] - needed for some other stuff in there I suppose (it contains more than just VirtualBox), for VB it is definitely not needed
openSUSE:13.2 - obvious, the standard repo that you should already have
openSUSE:13.2:Update - obvious, you should already have that anyway too
[noparse]openSUSE:13.2:Ports[/noparse] (and the corresponding update repo) - you should never add this to an ix86/x86_64 system, it contains openSUSE for other CPU architectures like ARM and PPC. As it doesn’t contain any packages (nor doesn’t actually exist) for your system, you get error messages when YaST or zypper tries to access it. That it is going to be added is either a bug in the repo setup or in OBS itself.
It should not try to add my test repo though, which you mentioned.
If you actually tried to add my repo, then yes. It inherits the above because it is just a branch.
On Thu, 15 Oct 2015 08:36:01 +0000, wolfi323 wrote:
> hendersj;2732313 Wrote:
>> I use the builds in the Virtulization: repository - they generally have
>> worked really well for me.
> Me too.
There are two things that I find a little odd about that repo, though:
On the host, I end up with the guest kernel modules installed - that
seems counterintuitive to me, since the host isn’t a guest.
Multiple versions of the kernel modules end up on the system, and
each time I upgrade, I have to manually clean up old versions of the
kernel modules, or I end up with zypper reporting conflicts.
But other than those things, functionally, it works great and is more
current than the standard repos.
Yes, that’s also a “problem” of the packages included in 13.2 (and 13.1 already too, IIRC).
The “problem” is that virtualbox-guest-kmp-xxx declares itself as supplementing virtualbox even on the host.
I have investigated this a while ago, but there is no mention of this in the files of virtualbox.
Seems to be a “feature” of the kmp creation script, part of the kernel.
But I haven’t found out where it does that either yet, or what could be done about it.
So far, the only “solution” I can think of is adding a conflict between virtualbox-host-kmp-xxx with virtualbox-guest-kmp-xxx (this has even been done in times when the packages were still called “virtualbox-ose-xxx” because of problems back then when having both installed, the conflict is still there in the packages although it’s of course outdated… ), but that will cause problems, i.e. a conflict dialog, on updates.
Multiple versions of the kernel modules end up on the system, and
each time I upgrade, I have to manually clean up old versions of the
kernel modules, or I end up with zypper reporting conflicts.
That’s caused by the “multiversion” feature for the kernel.
Actually it should be “fixed” meanwhile the same way as it is fixed in the nvidia driver packages, but the fix doesn’t seem to work (not even in the nvidia driver packages…) AFAICT.
But other than those things, functionally, it works great and is more
current than the standard repos.
On Thu, 15 Oct 2015 18:36:01 +0000, wolfi323 wrote:
> hendersj;2732414 Wrote:
>> 1. On the host, I end up with the guest kernel modules installed -
>> that seems counterintuitive to me, since the host isn’t a guest.
> Yes, that’s also a “problem” of the packages included in 13.2 (and 13.1
> already too, IIRC).
> The “problem” is that virtualbox-guest-kmp-xxx declares itself as
> supplementing virtualbox even on the host.
> I have investigated this a while ago, but there is no mention of this in
> the files of virtualbox.
>
> Seems to be a “feature” of the kmp creation script, part of the kernel.
> But I haven’t found out where it does that either yet, or what could be
> done about it.
>
> So far, the only “solution” I can think of is adding a conflict between
> virtualbox-host-kmp-xxx with virtualbox-guest-kmp-xxx (this has even
> been done in times when the packages were still called
> “virtualbox-ose-xxx” because of problems back then when having both
> installed, the conflict is still there in the packages although it’s of
> course outdated… ), but that will cause problems, i.e. a conflict
> dialog, on updates.
Yeah, though I get that already (as noted below). Definitely
something to see about sorting out, though - I keep thinking I should
submit a bug for it. Maybe I’ll have some time this weekend to do
that.
>> 2. Multiple versions of the kernel modules end up on the system, and
>> each time I upgrade, I have to manually clean up old versions of the
>> kernel modules, or I end up with zypper reporting conflicts.
> That’s caused by the “multiversion” feature for the kernel.
> Actually it should be “fixed” meanwhile the same way as it is fixed in
> the nvidia driver packages, but the fix doesn’t seem to work (not even
> in the nvidia driver packages…) AFAICT.
Sounds like something else I should submit a bug for.
>> But other than those things, functionally, it works great and is more
>> current than the standard repos.
> Yes, I can confirm that.
