VM not working after upgrade, suggests I sign kernels

5.2 VM wouldn’t run today and before it gave me and error, I received a message suggesting I update to 6.0.

So I went into YAST deleted the 5.2 version and installed the 6.0. I then installed the matching extension pack. When I went to start it, I got the usual reminder to run /sbin/vboxconfig.

Unfortunately it won’t start still. Here is the result of that command:

/sbin/vboxconfig
Created symlink /etc/systemd/system/multi-user.target.wants/vboxdrv.service → /usr/lib/systemd/system/vboxdrv.service.
Created symlink /etc/systemd/system/multi-user.target.wants/vboxballoonctrl-service.service → /usr/lib/systemd/system/vboxballoonctrl-service.service.
Created symlink /etc/systemd/system/multi-user.target.wants/vboxautostart-service.service → /usr/lib/systemd/system/vboxautostart-service.service.
Created symlink /etc/systemd/system/multi-user.target.wants/vboxweb-service.service → /usr/lib/systemd/system/vboxweb-service.service.
vboxdrv.sh: Stopping VirtualBox services.
vboxdrv.sh: Starting VirtualBox services.
vboxdrv.sh: You must sign these kernel modules before using VirtualBox:
  vboxdrv vboxnetflt vboxnetadp vboxpci
See the documenatation for your Linux distribution..


I tried searching this forum about how to sign those kernel modules and cannot find a solution posted.

Can anyone help with this?

I apologize if this doesn’t help at all but have you tried just reinstalling the packages?

sudo zypper install --force all the VirtualBox packages

I have had periodic issues with VirtualBox but this is a new one.

I am willing to try that. Can you help with the correct code for “all of the VirtualBox packages”. How do I find that list, or what code can I use there?

Agreed,
Unsigned modules usually is an error typically not something an End User has to deal with unless the End User is compiling and even so would be unexpected.

Somewhere in these Forums, I’ve described some procedures for purging Virtualbox files, and that would be similar to what you need to do.

The following should identify packages

zypper se 'virtual*'
zypper se 'Virtual*'

The second with the capital V probably will likely identify your Virtualbox packages,
Then you should be able to do the following to force re-install those packages

zypper in -f *package_1 package_2* 

TSU

Here is the output to that command. I notice there is still a 5.2 package lingering in there. I’m thinking I should use the command line to remove that. Do you agree? If so, what is the exact code?

linux-vqod:~ # zypper se 'virtual*'
Loading repository data...
Reading installed packages...

S | Name                           | Summary                                          | Type      
--+--------------------------------+--------------------------------------------------+-----------
  | virtualbox                     | VirtualBox is an Emulator                        | package   
  | virtualbox                     | VirtualBox is an Emulator                        | srcpackage
  | virtualbox-devel               | Devel files for virtualbox                       | package   
  | virtualbox-guest-desktop-icons | Icons for guest desktop files                    | package   
  | virtualbox-guest-kmp-default   | Guest kernel modules for VirtualBox              | package   
  | virtualbox-guest-source        | Source files for virtualbox guest kernel modules | package   
  | virtualbox-guest-tools         | VirtualBox guest tools                           | package   
  | virtualbox-guest-x11           | VirtualBox X11 drivers for mouse and video       | package   
  | virtualbox-host-kmp-default    | Host kernel module for VirtualBox                | package   
  | virtualbox-host-source         | Source files for virtualbox host kernel modules  | package   
  | virtualbox-qt                  | Qt GUI part for virtualbox                       | package   
  | virtualbox-vnc                 | VNC desktop sharing                              | package   
  | virtualbox-websrv              | WebService GUI part for virtualbox               | package   
linux-vqod:~ # zypper se 'Virtual*'
Loading repository data...
Reading installed packages...

S  | Name            | Summary                                                      | Type      
---+-----------------+--------------------------------------------------------------+-----------
   | VirtualBox-5.2  | Oracle VM VirtualBox                                         | package   
i+ | VirtualBox-6.0  | Oracle VM VirtualBox                                         | package   
   | VirtualGL       | A toolkit for displaying OpenGL applications to thin clients | package   
   | VirtualGL       | A toolkit for displaying OpenGL applications to thin clients | srcpackage
   | VirtualGL-32bit | A toolkit for displaying OpenGL applications to thin clients | package   
   | VirtualGL-devel | A toolkit for displaying OpenGL applications to thin clients | package 

The only package that is installed is the one with the I or I+ and is highlighted in red.
I’m a bit surprised that you don’t have virtualbox-host-kmp-default installed, which should be your kernel modules.

So, your command to force re-installation which would include ensuring your kernel modules should be re-installed is

zypper in -f Virtualbox-6.0

TSU

I used that command, but it says the 6.0 package is not found. That’s odd. Here is the exact output:

linux-vqod:~ # zypper in -f Virtualbox-6.0
Retrieving repository 'openSUSE-Leap-15.0-Update' metadata ...................................................................................[done]
Building repository 'openSUSE-Leap-15.0-Update' cache ........................................................................................[done]
Loading repository data...
Reading installed packages...
Package 'Virtualbox-6.0' not found.
Resolving package dependencies...

Nothing to do.


Also, now when I open the VM it says that the ext pack is out dated and wants to upgrade to 6.0.10. I think I should ignore that, because it won’t be matching the host program. True?

Well, I didn’t question your output but I don’t have “Virtualbox-6.0” on my system, either.
I also don’t know on my systems how Virtualbox 5.2 and Virtualbox 6.0 are distinguishable on the same system, I don’t have an openSUSE 15.0 set up to inspect at the mement… and that is the only version of openSUSE that it’s possible to have either. I look at openSUSE 15.1 and only Virtualbox 6.0 is available (Do you have any thoughts about upgrading soon?).

Let’s try to find out what this package is…
First, run the command again to see if you get the same result

zypper se 'Virtual*'

and if you still see Virtualbox-6.0, then run the following

zypper info Virtualbox-6.0

TSU

Loading repository data…
Reading installed packages…

Information for package VirtualBox-6.0:

Repository : VirtualBox for openSUSE 15.0 - x86_64
Name : VirtualBox-6.0
Version : 6.0.10_132072_openSUSE150-1
Arch : x86_64
Vendor : Oracle Corporation
Installed Size : 206.2 MiB
Installed : Yes
Status : up-to-date
Source package : VirtualBox-6.0-6.0.10_132072_openSUSE150-1.src
Summary : Oracle VM VirtualBox
Description :
VirtualBox is a powerful PC virtualization solution allowing
you to run a wide range of PC operating systems on your Linux
system. This includes Windows, Linux, FreeBSD, DOS, OpenBSD
and others. VirtualBox comes with a broad feature set and
excellent performance, making it the premier virtualization
software solution on the market.

OK,
It looks like you have an odd repository configured…
Looks like you don’t have Virtualbox from openSUSE,
You have an Oracle repository configured, so that means you’ve installed Oracle Virtualbox instead.

That generally explains your kernel modules error,
Oracle Virtualobx will compile on the fly using sources from Oracle,
whereas
If you had installed openSUSE Virtualbox, then your kernel modules would have been pre-compiled.

It can also mean that it’s important to know what you had installed before…
Was your Virtualbox 5.2 from Oracle also or from openSUSE?
If from openSUSE, then you would have had to manually remove Virtualbox before doing your upgrade.
If you had Oracle Virtualbox, then I would have expected your upgrade to 6.0 should have removed the 5.2 kernel modules, but maybe there was a problem…

It may also be informative to know exactly what virtualbox components are on your system.

Install the package “mlocate” if you haven’t already(locate is a much faster utility to find files on files on your system than “find”),
Then run the following to populate the locate database

updatedb

Then you can find and display files using any combination of text strings and paths you wish, do this to find anything named and related to virtualbox on your system

locate virtualbox
locate Virtualbox

What we’re generally looking for, and want to try to identify any Virtualbox files which might have a name that suggest a version that’s not 6.0, or the same version.

As long as you’re doing all this,
You might as well also verify that the necessary dependencies to compile kernel modules are installed on your system. all of the following should be displayed in the result to the following command

zypper si make gcc kernel-devel kernel-default-devel

TSU

Here is what those commands turn up:

“locate virtualbox” produces a huge output which is too big to display. But somehow none of the files that it displays mention the version number.

 **linux-vqod:~ #** locate Virtualbox 
/home/Documents/Random/Back Ups/Virtualbox Install.odt 
/home/Documents/Random/Back Ups/Virtualbox Install.pdfp { margin-bottom: 0.1in; line-height: 115%; background: transparent none repeat scroll 0% 0%; }

 zypper si make gcc kernel-devel kernel-default-devel 
Reading installed packages... 
Loading repository data... 
Package 'kernel-devel' has source package 'kernel-source'. 
Package 'kernel-default-devel' has source package 'kernel-default'. 
Resolving package dependencies... 

The following NEW package is going to be installed:
 hmaccalc 

The following 4 source packages are going to be installed:
 gcc kernel-default-4.12.14-lp150.12.67.1 kernel-source-4.12.14-lp150.12.67.1 make 

1 new package to install, 4 source packages. 
Overall download size: 123.3 MiB. Already cached: 0 B. After the operation, additional 245.1 MiB will be used. 
**Continue? [y/n/...? shows all options] (y): **y 
Retrieving srcpackage gcc-7-lp150.2.3.1.noarch                                                                                                 (1/5) 
Retrieving: gcc-7-lp150.2.3.1.src.rpm ........................................................................................................[done] 
Retrieving package hmaccalc-0.9.14-lp150.2.3.1.x86_64                                                          (2/5),  23.7 KiB ( 96.1 KiB unpacked) 
Retrieving: hmaccalc-0.9.14-lp150.2.3.1.x86_64.rpm ...............................................................................[done (6.6 KiB/s)] 
Retrieving srcpackage kernel-source-4.12.14-lp150.12.67.1.noarch                                                                               (3/5) 
Retrieving: kernel-source-4.12.14-lp150.12.67.1.src.rpm ..........................................................................[done (3.7 MiB/s)] 
Retrieving srcpackage make-4.2.1-lp150.6.3.1.noarch                                                                                            (4/5) 
Retrieving: make-4.2.1-lp150.6.3.1.src.rpm .......................................................................................[done (1.7 MiB/s)] 
Retrieving srcpackage kernel-default-4.12.14-lp150.12.67.1.noarch                                                                              (5/5) 
Retrieving: kernel-default-4.12.14-lp150.12.67.1.nosrc.rpm .......................................................................[done (4.1 MiB/s)] 
Checking for file conflicts: .................................................................................................................[done] 
(1/5) Installing: gcc-7-lp150.2.3.1.src ......................................................................................................[done] 
(2/5) Installing: hmaccalc-0.9.14-lp150.2.3.1.x86_64 .........................................................................................[done] 
(3/5) Installing: kernel-source-4.12.14-lp150.12.67.1.src ....................................................................................[done] 
(4/5) Installing: make-4.2.1-lp150.6.3.1.src .................................................................................................[done] 
(5/5) Installing: kernel-default-4.12.14-lp150.12.67.1.src ...................................................................................[done]  

  

Just as a reminder, the problem with my VM not working actually started before I upgraded to the new version. I assumed it was because the current one was out dated (because it had prompted me to update at the same time), but that would be unusual. We may be searching in the wrong place.

Also, yes, my system may have both Oracle and the other versions of VM. Because recently I had a different problem and people in this forum helped me fix it by installing the VM software through the command prompts. But normally I always go through YAST, which is what I did this time.

I hope that helps.

Based on what you posted, you have a Frankenstein combination of Oracle Virtualbox and openSUSE Virtualbox on your system.
Before removing and purging your Virtualbox packages and files, you need to decide what you want when you re-install…

You need to decide whether you want to install Oracle Virtualbox which will compile kernel modules on your system or openSUSE Virtualbox, which is compile by Maintainers in the Cloud and then the results are simply copied to your system. There not too much difference otherwise, of course compiling on your system involves some complexity which you would need to troubleshoot if you have any problems.

Since I don’t think your Guests have been upgraded to 6.0, you also need to decide whether you want to return to 5.2 or upgrade to 6.0, 5.x is solid and reliable and supported and 6.0 is very, very new with some possible risk associated with anything brand new. Basic features haven’t changed much between the two but if you’re chasing an extra bit of performance or an optional feature that might work better, then 6.0 should be considered.

Both 5.2 and 6.0 are available both as Oracled Virtualbox downloads and openSUSE packages for 15.0, unlike 15.1 and TW which only have 6.0 now.

As for the purging and re-installation,
They’re pretty straight forward…

  1. Do the “locate” searches I described to understand what files will need to be removed.
  2. If you have any HostOS custom configurations (not Guests), you should copy those to an alternate location, otherwise a re-install after thorough purging will return you to install defaults.
  3. Do a package uninstall, typically this simply involves substituting “rm” for any zypper “si” commands. This only removes packages but purging is more thorough.
  4. After package uninstallation, update your “locate” database by running “updatedb” and run your commands again to get an updated list of Virtualbox files that still exist on your system.
  5. Remove the files listed by “locate” in step 4 using “rm” command or use a file manager (if you can see the files). Remember, using a file manager can simply move your files into a trash so might not be removed permanently. There’s a good and a bad side to this, on one hand if you make a mistake of some sort you can undo easily but on the other hand you may need to take extra steps to remove permanently.
  6. Remove the Oracle Virtualbox repository. This can be done in YaST Repository Management or the following where repo_id can be anything unique about the repo… the repository number, the repo name, etc
zypper rr  
  1. Re-run Step 4 updating the locate database and searching for files on your system.
  2. When your system has been completely purged of Virtualbox files, you can now re-install Virtualbox, exactly what you do will depend on your pre-purge decisions what version of Virtualbox you want and from Oracle or from openSUSE.

If you have specific questions or issues,
Post again.

TSU

Thanks for the patience and detailed answer. But, I feel like I better describe exactly what I planning to do first.

Based on what you said, I would prefer to downgrade back to the 5.2 VM version. I just want something stable and have not done any custom configurations. I would prefer to use the version that I download through YAST, is that the Opensuse version?

Assuming those choices, would you still recommend the same sequence of steps? Also using the locate file command, I don’t recall many of the files declaring themselves as 5.2 vs 6.0, or Oracle vs. Opensuse. I’m not confident that I know how to identify which files to remove. Can you clarify that better for me?

Thanks again.

I can easily deinstall the 6.0 version in YAST and then install the 5.2. But I’m not sure how to identify the wrong files do delete them.

Any advice?

I outlined what you need to do to “purge” anything from a system…

  1. Use your package manager (zypper or YaST) to remove as many packages as possible. This will remove most files safely but will leave a number of configuration files and perhaps some components.
  2. Use the “locate” utility (my recommendation) or something similar like Find to identify remaining files not removed by the package manager.
  3. Remove the identified files.
  4. Usually a good idea to reboot before re-installing.

TSU

Thanks again. Maybe you didn’t see my other post in this thread. I tried to follow those steps for purging, but when I use the locate utility and look at the files, it isn’t clear to me which ones I need to purge. Almost none of them have the version number in the title (5.2 vs 6.0). So that leaves me baffled about how to know which ones. Can you give me some more guidance there?

Should I use different keywords other than virtualbox and Virtualbox?

Typically Virtualbox fifes will be within a directory with “Virtualbox” in the name.
Typically configuration files will either be within the application directory or a directory under /etc/
Library files will generally be within a lib or lib64 directory.
You can be more certain the file(s) are related to Virtualbox if the full “virtualbox” name is in the file or directory name, if the file has only “virtual” in the name, then look a bit deeper or post the file and ask about it.

If you successfully uninstalled Virtualbox packages, you shouldn’t be seeing a large number of Virtualbox related files remaining… Maybe at most a dozen or so.

If you make a mistake and damage your operating system (unlikely but mistakes can happen), you should be able to repair using your openSUSE DVD (followed by an update). But, the better option is to just post a file list of anything you’re not certain and ask.

TSU

Problem solved! It was so simple it leaves me baffled as to what the original problem was. Here is what I did in case others get in the same predicament:

In YaST I deleted the 6.0 Version and installed the 5.2 version all at the same time. Then I updated the extension pack by downloading the matching version from here: Index of http://download.virtualbox.org/virtualbox

It opened perfectly. Then I updated the guest additions from inside the Windows 10 machine. Now all is back and operating smoothly.

I wonder if the reason my old version wasn’t working is because it was a mix of 5.2.32 and 5.2.18. I am guessing that because the guest additions before I updated them were 5.2.18, while the host VM was 5.2.32.

I also noticed that I usually install the VM from the YaST, (the OpenSUSE version) but use the Oracle ext pack and guest additions. That has always seemed to work fine, but maybe that is a bad practice?

Anyways, thanks for the coaching. Got this up and running just in time, as I have some accounting I need to do for my business before the end of the month. Phew. :slight_smile:

I run into the same problem and after digging in the initialization scripts I found the cause. In fact I found a couple of mistakes. When running /sbin/vboxconfig will try to start the service instead of configuring. The other thing is that it recognizes secure boot in SUSE, but handles it only for Debian. I modified the file /usr/lib/virtualbox/vboxdrv.sh so that it runs ‘setuo’ when appropriate and also to ignore the ‘SecBoot enabled’ in SUSE as modules are not signed. This should be allowed or restricted by the allow_unsupported_modules in /etc/nodprobe.d

This is the patch:

*** vboxdrv.sh Mon Jul 29 15:49:27 2019
— vboxdrv.sh.orig Mon Jul 29 16:14:47 2019


*** 94,100 ****
“SecureBoot enabled”) HAVE_SEC_BOOT=true;;
*) unset HAVE_SEC_BOOT;;
esac
! # So far we can only sign modules on Ubuntu and on Debian 10 and later.
DEB_PUB_KEY=/var/lib/shim-signed/mok/MOK.der
DEB_PRIV_KEY=/var/lib/shim-signed/mok/MOK.priv
unset HAVE_DEB_KEY
— 94,105 ----
“SecureBoot enabled”) HAVE_SEC_BOOT=true;;
*) unset HAVE_SEC_BOOT;;
esac
! # In SUSE and OpenSUSE HAVE_SEC_BOOT would not allow loading the modules even
! # if ‘allow_unsupported_modules’ is set to 1. So we unset it.
! if egrep -q ‘^NAME=“(openSUSE Leap|SLES)”’ /etc/os-release 2>/dev/null; then
! unset HAVE_SEC_BOOT
! fi
!
DEB_PUB_KEY=/var/lib/shim-signed/mok/MOK.der
DEB_PRIV_KEY=/var/lib/shim-signed/mok/MOK.priv
unset HAVE_DEB_KEY


*** 568,574 ****
## than the fall-back. Unnecessary duplication?
stop && cleanup
setup_usb “$GROUP” “$DEVICE_MODE” “$INSTALL_DIR”
! start
;;
cleanup)
stop && cleanup
— 573,579 ----
## than the fall-back. Unnecessary duplication?
stop && cleanup
setup_usb “$GROUP” “$DEVICE_MODE” “$INSTALL_DIR”
! setup
;;
cleanup)
stop && cleanup

I understand that patching a file from a package is not the best solution, but it is the only way I managed to make it work.

Interesting. Thanks for sharing.

I noticed that it was having a problem with the secure boot. That makes sense.