VirtualBox does not work anymore

LouBen3010 · 26. April 2018

Hey there,

recently I did some basic updates and since then my VirtualBox does not work anymore.
I can't activate the plug-in properly.

This message is driving me nuts, because I already tried everythin. I removed everything regarding VirtualBox. I also switched to Kernel 4.14 (now I'm working with 4.15 again).
Unfortunately I'm working with VirtualBox everyday since I host my Nextcloud etc. in it.
Currently I'm thinking about switching to Docker, but since this is a new and different technique I need to figure out how it works.

But for now I need to get this fixed.
Do you have ideads?

Here the full error:

Code

Fehler #0:
OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; systemctl start 'virtualbox-web' 2>&1' with exit code '5': Failed to start virtualbox-web.service: Unit vboxdrv.service not found. in /usr/share/php/openmediavault/system/process.inc:175
Stack trace:
#0 /usr/share/php/openmediavault/system/systemctl.inc(86): OMV\System\Process->execute(Array, 5)
#1 /usr/share/php/openmediavault/system/systemctl.inc(104): OMV\System\SystemCtl->exec('start', NULL, false)
#2 /usr/share/openmediavault/engined/module/virtualbox.inc(107): OMV\System\SystemCtl->enable(true)
#3 /usr/share/openmediavault/engined/rpc/config.inc(194): OMV\Engined\Module\VirtualBox->startService()
#4 [internal function]: OMVRpcServiceConfig->applyChanges(Array, Array)
#5 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
#6 /usr/share/php/openmediavault/rpc/serviceabstract.inc(149): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array)
#7 /usr/share/php/openmediavault/rpc/serviceabstract.inc(536): OMV\Rpc\ServiceAbstract->OMV\Rpc\{closure}('/tmp/bgstatus4b...', '/tmp/bgoutput8z...')
#8 /usr/share/php/openmediavault/rpc/serviceabstract.inc(159): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
#9 /usr/share/openmediavault/engined/rpc/config.inc(213): OMV\Rpc\ServiceAbstract->callMethodBg('applyChanges', Array, Array)
#10 [internal function]: OMVRpcServiceConfig->applyChangesBg(Array, Array)
#11 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
#12 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('applyChangesBg', Array, Array)
#13 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('Config', 'applyChangesBg', Array, Array, 1)
#14 {main}

Alles anzeigen

With best regards
LouBen3010

ryecoaaron · 26. April 2018

virtualbox 5.2.8+ doesn't use vboxdrv which the old version of phpvirtualbox and the plugin had code for. It will compile with the 4.15 kernel though. Since Debian put 5.2.10 in the backports repo, I will have to push the new plugin version the regular omv-extras repo. If you had the testing repo enabled, you wouldn't have had this problem.

LouBen3010 · 26. April 2018

That was a great advice. Thank you very much!

Edit: Is it safe to update to VirtualBoix 4.1 and then turn off the testing repo?

Mr Smile · 26. April 2018

I like OMV very much but I have to say that enabling backports was not a good idea! Debian has good reasons to make this optional and you should stay with it. Broken VirtualBox is just one symptom. Nobody knows what other problems are under the hood. The Debian people tell everyone not to enable backports if stability is important. I know you want to support bleeding edge hardware but don't sacrifice the stability of all legacy systems! I strongly opt for making backports optional again. Or does OMV4 base system itself need backports? I run OMV4 on a HP Proliant Gen8 so I think I don't have any real benefits of backports. But they break my VirtualBox installation. This is a real show stopper. How can I safely disable backports? (But I really think it sould be the other way around! ... maybe a nice little switch "Enable backports?" in the installer itself?)

edit: Extra question: What happens if I install OMV4 on top of an existing Debian without backports?

ryecoaaron · 27. April 2018

Zitat von LouBen3010

Is it safe to update to VirtualBoix 4.1 and then turn off the testing repo?

I pushed 4.1 to the regular repo.

ryecoaaron · 27. April 2018

Zitat von Mr Smile

but I have to say that enabling backports was not a good idea! Debian has good reasons to make this optional and you should stay with it.

I've never had any issues with backports because I install all updates on a test VM first.

Zitat von Mr Smile

Broken VirtualBox is just one symptom. Nobody knows what other problems are under the hood. The Debian people tell everyone not to enable backports if stability is important.

I disagree with this for the most part. Backports are stable packages from the current stable release rebuilt for the previous release. While there may be issues with using a new version of one package and an old version of another, I haven't seen this very often.

Zitat von Mr Smile

But they break my VirtualBox installation. This is a real show stopper.

Your example of virtualbox isn't a good example because there is no virtualbox package in the regular stretch repos (link). If you didn't have the backports repo enabled -or- I didn't compile the buster package on stretch and put it in the omv-extras repo, you wouldn't be using virtualbox at all.

Zitat von Mr Smile

I know you want to support bleeding edge hardware but don't sacrifice the stability of all legacy systems!

It isn't just bleeding edge hardware. Sometimes newer kernels have power consumption improvements, bug fixes for filesystems (ie btrfs), better network drivers, and other features that aren't backported to the regular kernel.

Zitat von Mr Smile

I strongly opt for making backports optional again.

Zitat von Mr Smile

How can I safely disable backports?

It may be enabled by default but is still optional... Add the line OMV_APT_USE_KERNEL_BACKPORTS="no" to /etc/default/openmediavault and omv-mkconf aptif you don't want backports. And just remember that only a few packages are pinned. So, an OMV 4.x install from the OMV 4.x iso ONLY uses the backports kernel. It is very easy to disable backports and install the regular kernel. There are no other backports packages installed. omv-extras does pin a few more though but not if you have backports disabled.

Zitat von Mr Smile

Or does OMV4 base system itself need backports?

No, it isn't "needed".

Zitat von Mr Smile

But I really think it sould be the other way around!

Then people couldn't install on newer hardware.

Zitat von Mr Smile

maybe a nice little switch "Enable backports?" in the installer itself?)

edit: Extra question: What happens if I install OMV4 on top of an existing Debian without backports?

That would be a lot of work to implement. Installing on existing Debian works fine but you still need to disable backports in the default file listed above.

Mr Smile · 28. April 2018

First of all thanks for this detailed answer and the instructions. I don't want to start a quote hell. So I'll try without quoting you.

You said that backports are stable packages from the current stable release for the previous release. According to https://backports.debian.org/ this is not right:

Zitat von https://backports.debian.org/

Backports are packages taken from the next Debian release (called"testing"), adjusted and recompiled for usage on Debian stable.
[...]
Backports cannot be tested as extensively as Debian stable, and backportsare provided on an as-is basis, with risk of incompatibilities with othercomponents in Debian stable. Use with care!

But apart from that it is indeed funny that there is no Virtualbox at all in the normal stretch repos. Didn't recognize this. Point for you.

Years ago I had to use Virtualbox + phpvirtualbox on an Ubuntu server for a university project and I remember that I had to deal with a broken vbox installation more than one time. vbox seems to be very sensitive to kernel updates in general (understandably). So I was very happy to see that there is an OMV plugin for vbox. (Thanks for that!)

My situation is as follows: I use OMV3 as backup and sync server and I need the vbox plugin to run some vms I need. At this moment I try OMV4 on an old pc but I plan to migrate my live system to OMV4 when it gets final. I don't need any other plugins but ubackup, syncthing and vbox. And vbox has to be as reliable as possible because I really need those VMs.

So I ask you as the maintainer of this nice plugin: What (in detail) would you recommend to do (on a fresh installed omv4) to get a max. stable vbox config? (Would deactivating backports help at all to avoid those update problems?)

My horror scenario is that my live vbox is broken for days/weeks after a kernel update or so. Energy consumption, btrfs improvements and so on are not important to me but I need a real stable vbox environment.

Huberer · 28. April 2018

@Mr Smile

As you can see in my signature I'm running OMV v4 with latest backports kernel (4.15) and I've installed Virtualbox via OMV-testing repo. Right now it runs quite stable but can't tell about long time experience. I send my server into suspend mode and after wake up the VM (Synology DSM) is back again and runs without any hick-ups.
What I suggest is that you test Virtualbox with backports kernel and when it runs like you want make a backup. When a new update of the backup kernel shows up don't update and wait till someone confirm that's safe to update. And if you really want to update, make a new backup before and if something is broken you can install the backup again and you're on the safe side again.

ryecoaaron · 28. April 2018

Zitat von Mr Smile

You said that backports are stable packages from the current stable release for the previous release. According to https://backports.debian.org/ this is not right:

I guess that is true. I was thinking about using backports on jessie/OMV 3.x. Because jessie is old stable and stretch is stable, jessie backports are stable packages. I will still keep using them because I have never had any real stability issues.

Zitat von Mr Smile

So I ask you as the maintainer of this nice plugin: What (in detail) would you recommend to do (on a fresh installed omv4) to get a max. stable vbox config? (Would deactivating backports help at all to avoid those update problems?)

Major kernel updates that potentially break vbox don't happen very often. If it is that big of an issue, use OMV 3.x if you don't care if virtualbox gets updated or use OMV 4.x with backports disabled. Like huberer wrote, testing is the key with any update not just virtualbox.

Personally, I used virtualbox for years with backports with no major issues but it is nowhere as good as VMware. Have you ever thought about using ESXi instead? Then you would virtualize OMV as well as your other systems. This is what I do. It is faster and much more stable.

Mr Smile · 30. April 2018

Zitat von ryecoaaron

I guess that is true. I was thinking about using backports on jessie/OMV 3.x. Because jessie is old stable and stretch is stable, jessie backports are stable packages. I will still keep using them because I have never had any real stability issues.

Don't want to be rude because I really respect your work but let me explain my viewpoint.

I think using backported kernels by default is the wrong approach for a distro that claims to be a "safe vault" for their users data. Stability (in default configuration) should be more important than bleeding edge features. So you recklessly throw away the "old but extremely good testet" argument that stands for debian as a server os. Again with all respect I have to say that "works for me" and "the people should test every update before applying" is not a good justification for enabling backport kernels by default for people who don't even have any benefits from it. Testing every update for regressions is nearly impossible (because too effortful) for normal omv users but I think you agree with me that frequent (security) updates are very important. So the debian stable way (old but good tested with large user base) is very convenient for most of us. So why increasing the risks without benefits? (Again, there MAY be good reasons for using backport kernels but if you think you need it you should be able to balance the risks and benefits for your application on your own.)

So you said that OMV4 base system itself doesn't rely on backport kernel features. Is there a list that says what plugins need backport kernels to function properly? What about Docker for example? Are there any fundamental restrictions regarding plugin usage when I disable backport kernels?

Just to be clear because I don't have any experience in uninstalling backport kernels properly and don't want to break everything:
What do I have to do to remove backport kernels after adding OMV_APT_USE_KERNEL_BACKPORTS="no" to /etc/default/openmediavault and omv-mkconf apt?

(funfact: Google search for "debian remove backport kernel" leads me to omv forum where someone reports problems with virturalbox )

You mentioned ESXi. Unfortunately my specific hardware seems to be problematic with ESXi. At least people reported various problems and I was discouraged from trying ESXi.

ryecoaaron · 30. April 2018

Zitat von Mr Smile

I think using backported kernels by default is the wrong approach for a distro that claims to be a "safe vault" for their users data. Stability (in default configuration) should be more important than bleeding edge features. So you recklessly throw away the "old but extremely good testet" argument that stands for debian as a server os. Again with all respect I have to say that "works for me" and "the people should test every update before applying" is not a good justification for enabling backport kernels by default for people who don't even have any benefits from it. Testing every update for regressions is nearly impossible (because too effortful) for normal omv users but I think you agree with me that frequent (security) updates are very important. So the debian stable way (old but good tested with large user base) is very convenient for most of us. So why increasing the risks without benefits? (Again, there MAY be good reasons for using backport kernels but if you think you need it you should be able to balance the risks and benefits for your application on your own.)

You are really blowing this way out of proportion. If someone wants an ultra stable server OS, they should be running on stable server hardware. The majority of OMV users are using desktop grade hardware (or lower - think RPi). This hardware is much newer than most server hardware and benefits from using the backports kernel. There is a lot of history of reason to use the backports kernel.

The biggest pain of using the standard kernel lasted for months when the newer version of the e1000 network adapter was released and plenty of motherboards used it. People (especially noobs) were helpless to fix the system without a network connection. We had to recommend using a temporary supported NIC just to compile drivers for the e1000.

To say the backports kernel isn't well tested is a bit extreme. It starts in sid (unstable) then goes to testing (buster) and eventually goes to stretch-backports. The 4.15 kernel has 18 releases and the 4.14 is the LTS kernel with 38 releases. Please tell me these are unstable. It has very little to do with what userland packages are being used.

Zitat von Mr Smile

So you said that OMV4 base system itself doesn't rely on backport kernel features. Is there a list that says what plugins need backport kernels to function properly? What about Docker for example? Are there any fundamental restrictions regarding plugin usage when I disable backport kernels?

No plugin "needs" the backports kernel especially in OMV 4.x. There are plugins that need packages from the backports repo though. virtualbox, zfs, and remotedesktop (xrdp) are three that packages pinned for the backports repo if backports is enabled. docker just needs a new enough kernel. The standard kernel is new enough. And as I said before, the backports kernel shouldn't restrict any of the plugins in OMV 4.x. In OMV 3.x, it would affect btrfs, docker, zfs, and potentially others that relied on kernel modules or features.

Zitat von Mr Smile

Just to be clear because I don't have any experience in uninstalling backport kernels properly and don't want to break everything:
What do I have to do to remove backport kernels after adding OMV_APT_USE_KERNEL_BACKPORTS="no" to /etc/default/openmediavault and omv-mkconf apt?

The kernel is just a package. So, after that, you would (as root):
apt-get update
apt-get install install linux-image-amd64=4.9+80+deb9u4
If you have omv-extras installed, you can select the 4.9 kernel for the next boot. Otherwise, you will have local access to the machine to select the 4.9 kernel from the advanced options grub menu.
Once booted to the 4.9 kernel, you can remove the backports kernel with:
apt-get purge linux-image-4.15.0-0.bpo.2-amd64

Zitat von Mr Smile

You mentioned ESXi. Unfortunately my specific hardware seems to be problematic with ESXi. At least people reported various problems and I was discouraged from trying ESXi.

Then use Proxmox. It is very good. I use it on one production system. Just to warn you though... It uses the Ubuntu HWE (ubuntu's name for backports) kernel with the Debian Stretch userland. But, it is a commercially supported and tested setup.

Mr Smile · 8. Mai 2018

Thanks for your explanation. Unfortunately I don't have time to test it at the moment. I had a car accident last week. (Some idiot crashed into my car from behind ) I'm just out of hospital. So my current priority is not omv.

I don't find the page at the moment but I remember that even Canonical recommended to install Ubuntu (Server) 16.04/16.04.1 over 16.04.2 ff. (with HWE) unless you really benefit from the HWE kernels or updated software versions. Same was for 14.04. So I'm still not completely satisfied with OMVs decision to set backport kernel as default. But if I have the choice (as you described) to switch back to non-backport without restraints I can absolutely live with it. Would still like to see some kind of GUI switch and automatism for it. (feature request? )

Before my accident I had a look at proxmox but it seems to be overblown for my needs. The main task for my server is to be network storage - then virtualization. And I need some usb devices for backup. Virtualization of OMV would add another complexity layer to it. Just want to keep it as simple as possible. And Virtualbox + phpvirtualbox has the huge plus that you can easily create and test VMs on your local machine then push them to the server and vice versa. (I fully agree with you that proxmox/ESXi is the better choice if you want/need a full-blown virtualization host.)

Now (while getting well again) I'm looking forward to the official release of OMV4 final. Hope this won't take months.

Keep up the good work!

Mr Smile · 20. Mai 2018

Zitat von ryecoaaron

The kernel is just a package. So, after that, you would (as root):apt-get update
apt-get install install linux-image-amd64=4.9+80+deb9u4
If you have omv-extras installed, you can select the 4.9 kernel for the next boot. Otherwise, you will have local access to the machine to select the 4.9 kernel from the advanced options grub menu.
Once booted to the 4.9 kernel, you can remove the backports kernel with:
apt-get purge linux-image-4.15.0-0.bpo.2-amd64

I did apt-get update and apt-get install install linux-image-amd64=4.9+80+deb9u4 as root and got this Exception from Python during installation:

Code

Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7f410cefd510>
Traceback (most recent call last):
  File "/usr/lib/python3.5/weakref.py", line 117, in remove
TypeError: 'NoneType' object is not callable
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7f410cefd510>
Traceback (most recent call last):
  File "/usr/lib/python3.5/weakref.py", line 117, in remove
TypeError: 'NoneType' object is not callable

Should I be worried on this?

Here the complete output:

Code

root@burns:~# apt-get install linux-image-amd64=4.9+80+deb9u4
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
The following additional packages will be installed:
  linux-image-4.9.0-6-amd64
Vorgeschlagene Pakete:
  linux-doc-4.9 debian-kernel-handbook
Empfohlene Pakete:
  irqbalance
Die folgenden NEUEN Pakete werden installiert:
  linux-image-4.9.0-6-amd64
Die folgenden Pakete werden durch eine ÄLTERE VERSION ERSETZT (Downgrade):
  linux-image-amd64
0 aktualisiert, 1 neu installiert, 1 durch eine ältere Version ersetzt, 0 zu entfernen und 14 nicht aktualisiert.
Es müssen 39,0 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 193 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] j
Holen:1 http://security.debian.org/debian-security stretch/updates/main amd64 linux-image-4.9.0-6-amd64 amd64 4.9.88-1+deb9u1 [39,0 MB]
Holen:2 http://ftp.de.debian.org/debian stretch/main amd64 linux-image-amd64 amd64 4.9+80+deb9u4 [7.030 B]
Es wurden 39,0 MB in 6 s geholt (5.998 kB/s).                                  
Vormals nicht ausgewähltes Paket linux-image-4.9.0-6-amd64 wird gewählt.
(Lese Datenbank ... 39479 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../linux-image-4.9.0-6-amd64_4.9.88-1+deb9u1_amd64.deb ...
Entpacken von linux-image-4.9.0-6-amd64 (4.9.88-1+deb9u1) ...
dpkg: Warnung: Version 4.14+89~bpo9+1 des Paketes linux-image-amd64 wird durch ältere Version 4.9+80+deb9u4 ersetzt
Vorbereitung zum Entpacken von .../linux-image-amd64_4.9+80+deb9u4_amd64.deb ...
Entpacken von linux-image-amd64 (4.9+80+deb9u4) über (4.14+89~bpo9+1) ...
linux-image-4.9.0-6-amd64 (4.9.88-1+deb9u1) wird eingerichtet ...
I: /vmlinuz is now a symlink to boot/vmlinuz-4.9.0-6-amd64
I: /initrd.img is now a symlink to boot/initrd.img-4.9.0-6-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-6-amd64
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
/etc/kernel/postinst.d/zz-update-grub:
GRUB-Konfigurationsdatei wird erstellt …
Linux-Abbild gefunden: /boot/vmlinuz-4.14.0-0.bpo.3-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.14.0-0.bpo.3-amd64
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-6-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-6-amd64
erledigt
linux-image-amd64 (4.9+80+deb9u4) wird eingerichtet ...
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7f410cefd510>
Traceback (most recent call last):
  File "/usr/lib/python3.5/weakref.py", line 117, in remove
TypeError: 'NoneType' object is not callable
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7f410cefd510>
Traceback (most recent call last):
  File "/usr/lib/python3.5/weakref.py", line 117, in remove
TypeError: 'NoneType' object is not callable

Alles anzeigen

Mr Smile · 20. Mai 2018

After reboot on 4.9 Kernel I did apt-get purge linux-image-4.14.0-0.bpo.3-amd64 (4.14 because of fresh omv installation) and got nearly the same Exception:

Code

Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7f5711906598>
Traceback (most recent call last):
  File "/usr/lib/python3.5/weakref.py", line 117, in remove
TypeError: 'NoneType' object is not callable
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7f5711906598>
Traceback (most recent call last):
  File "/usr/lib/python3.5/weakref.py", line 117, in remove
TypeError: 'NoneType' object is not callable

Mr Smile · 20. Mai 2018

Ok, I'm giving up for today.
I tried to install Virtualbox from OMVExtras stable and ended up like that:

Code

>>> *************** Error ***************
Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; export DEBIAN_FRONTEND=noninteractive; apt-get --yes --allow-downgrades --allow-change-held-packages --fix-missing --allow-unauthenticated --reinstall install openmediavault-virtualbox 2>&1' with exit code '100': Reading package lists...


Building dependency tree...


Reading state information...


Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:


The following packages have unmet dependencies:
 openmediavault-virtualbox : Depends: virtualbox (>= 5.2.8) but 5.1.26-dfsg-2 is to be installed
                             Depends: virtualbox-ext-pack-installer but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
<<< *************************************

Alles anzeigen

Whats going on here? My OMV 4.0 is completely vanilla except switching back to 4.9 and running updates once.

ryecoaaron · 21. Mai 2018

Zitat von Mr Smile

Should I be worried on this?

Upgrade Debian 9 and 4.x

Zitat von Mr Smile

Whats going on here? My OMV 4.0 is completely vanilla except switching back to 4.9 and running updates once

Remember that I said there is no virtualbox in the regular repo (just in backports). There is a version in the omv-extras repo but it is not new enough for the changes I made to the plugin. So, you can't install virtualbox without backports enabled.

ryecoaaron · 21. Mai 2018

The 4.1.7 version of omv-extras has buttons to disable and enable the backports repo.

Mr Smile · 25. Mai 2018

Zitat von ryecoaaron

Upgrade Debian 9 and 4.x

Thanks for this info. Didn't find that thread.

Zitat von ryecoaaron

Remember that I said there is no virtualbox in the regular repo (just in backports). There is a version in the omv-extras repo but it is not new enough for the changes I made to the plugin. So, you can't install virtualbox without backports enabled.

Ok, this is sad news. I (mis)understood that backports are not required for any plugin to work.

Zitat von ryecoaaron

The 4.1.7 version of omv-extras has buttons to disable and enable the backports repo.

Thanks again.

But if Virtualbox plugin doesn't work without backports, I have to leave it on.

In the meantime I reinstalled OMV4 without backport disable experiments but I have the same problem like described here:
OMV VirtualBox 4.1 - "Advanced configuration" switch doesn't work!

The advanced configuration toggle also has no effect for me.
Would you please have a look on it? Thank you!

ryecoaaron · 25. Mai 2018

Zitat von Mr Smile

Would you please have a look on it?

I'm about done working on the virtualbox plugin... All of these problems don't make any sense to me.

Zitat von Mr Smile

But if Virtualbox plugin doesn't work without backports, I have to leave it on.

No you don't. Enable backports and install the plugin. Then disable backports.

Mr Smile · 26. Mai 2018

But what about (security) updates if I disable backports? Enabling backports, looking for potential vbox updates, disabling backports every week is not very convenient.

By the way: Whats the reason for not using the official virtualbox.org repo for Debian? The virtualbox.org repo is on 5.2.12 at this time while debian backports give us 5.2.10. I ask this because OMV also uses the syncthing.net repo for Syncthing instead of the (existing but also slightly outdated) debian repo.

The phpvirtualbox wiki also gives advice to install virtualbox from virtualbox.org. Is there any difference apart from that small version delay? (I'm absolutely fine with 5.2.10 )

Jetzt mitmachen!