VirtualBox causing omv-engined[10089]: segfault

  • Hi!


    Performed a succesful upgrade of OMV from OMV3 to OMV4. As part of this, VirtualBox was uninstalled.


    After upgrade, and a reboot, I re-installed the VirtualBox plugin (openmediavault-virtualbox 4.1).
    The virtual machine was in state "saved", so I tried restarting it, which was unsuccesful.


    The VM-directory is showing as "OMV-Media [on OMV, OMV-Media/]", but should be "Vbox [on OMV, OMV-Media/Virtualbox/]", but the GUI will not let me save the change. So I checked "/etc/openmediavault/config.xml", and it is showing the correct path as far as I can see:

    It will show this even after a reboot.


    If I try to start it, it will throw an error:


  • So, I checked the service status:

  • So, I checked the service status:

  • As you can see, it does not look good!


    I am seeing segfaults for the start of the VM!




    So, I checked /var/log/messages to see if it would give any hints, and this is what I found there:


    Saw some warnings, and the segfaults again!


    To me it feels like VirtualBox cannot find the image to boot from, but the path is correct!


    Any ideas on what to do?

  • Ok seems no one have a good answer for this one, so I went ahead and played around a bit, and it is now working.


    What I did:

    • Copied the VDI file from the VM-folder to a backup location (in my case: /media/f7e3bc30-c184-4f4d-aa81-b87ffeb6d844/OMV-Media/Virtualbox), and deleted the whole VM guest machine from the phpGUI, including all files (make notes of config if any custom settings before deleting VM).
    • Re-created the VM from scratch, and pointed to the old VDI. It would now complain about existing machine with same UUID and same name. Solved this by rebooting, and then re-doing the create. This time it worked! The vdi is now in the "wrong" directory!
    • To fix this, I stopped the VirtualBox service (systemctl stop virtualbox), and moved the vdi file inside the machine folder. Then I updated the config file for the machine (machine.vbox) adding the additional machine folder name to the HardDisk path string, and re-started the VirtualBox service (systemctl start virtualbox). I then saw that this did not update the path under the machine settings as expected, so I rebooted.
    • After reboot, I checked the path, and it is now showing correctly, so I re-started the VM, and set it to Startup-Mode Automatic.


    What I learned from this is to always set VM guests to Startup-Mode Manual, and power them down during an upgrade, as the VM that was off during upgrade worked just fine!

    • Offizieller Beitrag

    What I learned from this is to always set VM guests to Startup-Mode Manual, and power them down during an upgrade, as the VM that was off during upgrade worked just fine!

    I also found in the past that VMs being powered down was essential during upgrades. Sorry, not sure what was causing your other issues.

    omv 7.0.5-1 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.11 | compose 7.1.3 | k8s 7.1.0-3 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Maybe add this to the FAQ/description threads for upgrades? That VMs needs to be powered down during upgrade.

    I had no idea that upgrades would cause these kind of problems to VM's. I was searching in the wrong places, and found many threads with this problem but in other words, none had a solution for it.
    Is it possible to incorporate a live warning when ?kernel? upgrades can cause these effects?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!