VirtualBox does not work anymore

    • OMV 4.x
    • Resolved

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • VirtualBox does not work anymore

      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:

      Source Code

      1. Fehler #0:
      2. 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
      3. Stack trace:
      4. #0 /usr/share/php/openmediavault/system/systemctl.inc(86): OMV\System\Process->execute(Array, 5)
      5. #1 /usr/share/php/openmediavault/system/systemctl.inc(104): OMV\System\SystemCtl->exec('start', NULL, false)
      6. #2 /usr/share/openmediavault/engined/module/virtualbox.inc(107): OMV\System\SystemCtl->enable(true)
      7. #3 /usr/share/openmediavault/engined/rpc/config.inc(194): OMV\Engined\Module\VirtualBox->startService()
      8. #4 [internal function]: OMVRpcServiceConfig->applyChanges(Array, Array)
      9. #5 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
      10. #6 /usr/share/php/openmediavault/rpc/serviceabstract.inc(149): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array)
      11. #7 /usr/share/php/openmediavault/rpc/serviceabstract.inc(536): OMV\Rpc\ServiceAbstract->OMV\Rpc\{closure}('/tmp/bgstatus4b...', '/tmp/bgoutput8z...')
      12. #8 /usr/share/php/openmediavault/rpc/serviceabstract.inc(159): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
      13. #9 /usr/share/openmediavault/engined/rpc/config.inc(213): OMV\Rpc\ServiceAbstract->callMethodBg('applyChanges', Array, Array)
      14. #10 [internal function]: OMVRpcServiceConfig->applyChangesBg(Array, Array)
      15. #11 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
      16. #12 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('applyChangesBg', Array, Array)
      17. #13 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('Config', 'applyChangesBg', Array, Array, 1)
      18. #14 {main}
      Display All
      With best regards
      LouBen3010
    • 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.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • 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?
    • LouBen3010 wrote:

      Is it safe to update to VirtualBoix 4.1 and then turn off the testing repo?
      I pushed 4.1 to the regular repo.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • Mr Smile wrote:

      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.

      Mr Smile wrote:

      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.

      Mr Smile wrote:

      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.

      Mr Smile wrote:

      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.

      Mr Smile wrote:

      I strongly opt for making backports optional again.

      Mr Smile wrote:

      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.

      Mr Smile wrote:

      Or does OMV4 base system itself need backports?
      No, it isn't "needed".

      Mr Smile wrote:

      But I really think it sould be the other way around!
      Then people couldn't install on newer hardware.

      Mr Smile wrote:

      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.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • First of all thanks for this detailed answer and the instructions. :) I don't want to start a quote hell. :whistling: 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:

      https://backports.debian.org/ wrote:

      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. :thumbup:

      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.
    • @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.
      OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 4x3TB WD Red's Snapraid w/ mergerfs, 2x DVB-S2 card DVBSky s952v3,

      OMV-Server-SW: Debian Stretch with 4.15.x-Backports-Kernel (always up-to-date), OMV 4.1.x (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Virtualbox (with DSM 6.1.x), PlexMediaServer, SMB-Shares, TVHeadendServer (unstable release)

      BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2
    • Mr Smile wrote:

      You said that backports are stable packages from the current stable release for the previous release. According to 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.

      Mr Smile wrote:

      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.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      Mr Smile wrote:

      You said that backports are stable packages from the current stable release for the previous release. According to 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.

      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 8| )

      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.

      The post was edited 2 times, last by Mr Smile ().

    • Mr Smile wrote:

      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.

      Mr Smile wrote:

      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.

      Mr Smile wrote:

      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

      Mr Smile wrote:

      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.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • 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 :thumbdown: ) I'm just out of hospital. So my current priority is not omv. :S

      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. :saint:

      Keep up the good work!

      The post was edited 1 time, last by Mr Smile ().

    • ryecoaaron wrote:

      Mr Smile wrote:

      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
      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:

      Source Code

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

      Should I be worried on this?


      Here the complete output:

      Source Code

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

      Source Code

      1. Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7f5711906598>
      2. Traceback (most recent call last):
      3. File "/usr/lib/python3.5/weakref.py", line 117, in remove
      4. TypeError: 'NoneType' object is not callable
      5. Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7f5711906598>
      6. Traceback (most recent call last):
      7. File "/usr/lib/python3.5/weakref.py", line 117, in remove
      8. TypeError: 'NoneType' object is not callable
    • Ok, I'm giving up for today.
      I tried to install Virtualbox from OMVExtras stable and ended up like that:

      Source Code

      1. >>> *************** Error ***************
      2. 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...
      3. Building dependency tree...
      4. Reading state information...
      5. Some packages could not be installed. This may mean that you have
      6. requested an impossible situation or if you are using the unstable
      7. distribution that some required packages have not yet been created
      8. or been moved out of Incoming.
      9. The following information may help to resolve the situation:
      10. The following packages have unmet dependencies:
      11. openmediavault-virtualbox : Depends: virtualbox (>= 5.2.8) but 5.1.26-dfsg-2 is to be installed
      12. Depends: virtualbox-ext-pack-installer but it is not going to be installed
      13. E: Unable to correct problems, you have held broken packages.
      14. <<< *************************************
      Display All

      Whats going on here? My OMV 4.0 is completely vanilla except switching back to 4.9 and running updates once. ;(
    • Mr Smile wrote:

      Should I be worried on this?
      Upgrade Debian 9 and 4.x

      Mr Smile wrote:

      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.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • The 4.1.7 version of omv-extras has buttons to disable and enable the backports repo.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • Thanks for this info. Didn't find that thread.

      ryecoaaron wrote:


      Mr Smile wrote:

      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.
      Ok, this is sad news. I (mis)understood that backports are not required for any plugin to work.

      ryecoaaron wrote:

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

      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!
    • Mr Smile wrote:

      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.

      Mr Smile wrote:

      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.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • 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 ^^ )

      The post was edited 1 time, last by Mr Smile ().