Windows 10 won't run in VM on Leap 15 (upgrade from 42.3)

I recently upgraded this laptop from 42.3 to 15. All is mostly OK, however this PC will not run with the new kernel, so I have to use 4.12.4-1.g2a27bf2-default

Virtualbox was installed on 42.3, and has not been altered since the upgrade. There is only one Guest OS, Windows 10.

When I now try to open the existing Win 10 guest in virtualbox I get the following error:

Kernel driver no installed (rc=-1908)

The VirtualBox Linux Kernel driver (vboxdrv) is either not loaded
or there is a permission problem with /dev/vboxdrv. Please
reinstall the kernel module by running


as root.

where: suplibOsInit what: 3VERR_VM_DRIVER_NOT_INSTALLED
(-1908 - the support driver is not installed. ON linux, open
returned ENOENT.

this is the result:

:~ # /sbin/vboxconfig
Building kernel modules...

Build of VirtualBox host kernel modules failed.
Look at /var/log/virtualbox.log to find reasons.


=== Building ‘vboxdrv’ module ===
make[1]: Entering directory ‘/usr/src/kernel-modules/virtualbox/src/vboxdrv’
make V= CONFIG_MODULE_SIG= -C /lib/modules/4.12.4-1.g2a27bf2-default/build SUBDIRS=/usr/src/kernel-modules/virtualbox/src/vboxdrv SRCROOT=/usr/src/kernel-modules/virtualbox/src/vboxdrv -j4 modules
make[2]: Entering directory ‘/usr/src/linux-4.12.4-1.g2a27bf2-obj/x86_64/default’
make[3]: Entering directory ‘/usr/src/linux-4.12.4-1.g2a27bf2-obj/x86_64/default’
make[3]: *** …/…/…/linux-4.12.4-1.g2a27bf2: No such file or directory. Stop.
make[3]: Leaving directory ‘/usr/src/linux-4.12.4-1.g2a27bf2-obj/x86_64/default’
make[2]: *** [Makefile:24: __sub-make] Error 2
make[2]: Leaving directory ‘/usr/src/linux-4.12.4-1.g2a27bf2-obj/x86_64/default’
make[1]: *** [/usr/src/kernel-modules/virtualbox/src/vboxdrv/Makefile.include.footer:101: vboxdrv] Error 2
make[1]: Leaving directory ‘/usr/src/kernel-modules/virtualbox/src/vboxdrv’
make: *** [Makefile:49: all] Error 2

I only need to use Windows a few times a year, but unfortunately this is one of those times, so suggestions would be gratefully received.

Virtualbox from the openSUSE repos is built against the currently available kernel.
It’s not too surprising that if you switch to a substantially different kernel, the pre-built Virtualbox kernel modules won’t match.

First Q
What is preventing you from running the current LEAP 15 kernel?
Maybe fixing that should be your preferable solution.

If you’re not able to solve your kernel problem,
Then you might remove the openSUSE version of Virtualbox and instead install Virtualbox downloaded from Oracle.
The Virtualbox downloaded from Oracle will dynamically build the kernel modules so will work with any kernel.


The current default Leap 15 Kernel is Version 4.12.14 – I can’t find a Version 4.12.4 Kernel anywhere in the openSUSE Leap 15 repositories , and, also, not in any of the repositories of the other openSUSE releases …

Where did you obtain the Kernel you’re using?

Please be aware that, you’ll need to find a version of the Oracle VirtualBox which has been built against the Kernel version you’re using …

FYI, apparently there is no Oracle VBox for LEAP 15 yet, please see this
So it seems that for the time being your only option is booting the LEAP 15 “current” kernel AND the openSUSE version of VBox.

Both the Leap 15.0 Update repository and the Leap 15.0 “Virtualization” repository contain Oracle’s VirtualBox version 5.2.12:

If the version of Virtualbox is truly what you’d get by downloading from Oracle (even if from the openSUSE repos),
Then it’s likely the requisites for building the modules aren’t already installed (I haven’t seen the error thrown by VBox building modules in a long time, so don’t remember how detailed the message is).

In general, the following are required for building any kernel modules, run it in an elevated console

zypper in kernel-devel kernel-default-devel make gcc

After those are installed, you should be able to install virtualbox immediately.

I assume the default version of gcc will work fine, but since LEAP 15 is so new if you need to run an older version of gcc, I wrote an article how to set up update-alternatives to point your system to an older gcc (You’ll also have to install the older gcc separately)


I’m no expert in this, but according to the mailing list message I referenced, the problem is a library (libvpx4), not the Oracle VBox version per se.
Apparently the package maintainer for openSUSE patched the sources to allow building of kernel modules against the LEAP 15 Kernel and you are able to download those modules already built from the openSUSE repo (while you have to build them yourself when installing the package downloaded directly from

Sorry to be so slow to respond. (leaky skylight + rain = higher priority)

Clearly I should have been included more data.

  • This PC is an HP Envy x360 convertible PC, model # 13-y023cl, with a 3840x2160 touch screen and Intel i7. *
  • It would not boot reliably in 42.3 until I installed 4.12. Since that worked OTB I never pursued the issue further, as it’s been stable, fast and does what I need it to do.
  • Later I tried upgrading 42.3 to newer kernels, but no luck. Stayed with 12.4.
  • My virtualbox was installed from the openSUSE 42.3 repo many months prior to the upgrade to 15 and has been untouched ever since other than patches etc…
  • When I upgraded to 15 (by following the SDB article) I assumed it would work OK with the newer default kernel, but I found the same issues I’d had prior to installing 4.12 earlier
  • The upgrade had left the 4.12 option in grub, so I booted to that and never looked back until now.

When I could not boot Win10 I opted not to blunder around blindly and screw things up worse, so I’ve done nothing (yet) until I’d checked in with this forum.

  • (a dream machine for a 2 photographer couple that travels a lot, but overkill otherwise)

So, if I understand it correctly, you are caught between a rock and a hard place:
> your PC does not boot with the stock 4.12.14 kernel in LEAP 15;
> your PC boots with the (old) 4.12.4 kernel BUT the current VBox kernel module from virtualbox-host-kmp-default-5.2.12_k4.12.14_lp150.11-lp150.4.3.1.x86_64.rpm does not work well (or at all) with that older kernel;
> the old 4.12.4 kernel is long gone from the Kernel:stable repo so you cannot download the matching kernel-devel packages needed to build the VBox kernel modules for the “Oracle” version of VBox;
> even if you already have the (old) -devel packages installed, VBox modules might not build due to a mismatch with the libvpx / libvpx4 library.

Please note that the current 4.12.14 kernel has some features backported from later versions, so it may be substantially different from the “old” 4.12.4 that your machine likes.
If my summary really fits your situation, it might be easier to solve the boot problems with the current 4.12.14 kernel (and use the stock VBox from the openSUSE repo) than trying to tweak the “Oracle” VBox until it builds for the “old” 4.12.4.

Please consider that since the above is somewhat beyond my pay grade :wink: I might be dead wrong here.

Which video device is driving that display?

The only Leap 42.3 Kernels of version 4.12.?? are “Community Packages” – the Open Build Service (OBS) versions used by community members for private use – the recommended way to use these packages is, to first ask the community person if they’re of the opinion that, the package they’ve built can be used by you. Please note that, the “Community Packages” are **** NOT **** part of the OpenQA process …

The newest Leap 42.3 Kernel is version 4.4.132.

Meaning that, the upgrade procedure you used, left the Leap 42.3 Kernel on the machine …
[HR][/HR]When you say that, the “PC will not run with the new kernel” and “It would not boot reliably” do you mean that, the graphic display misbehaves when loading a Graphical User Interface (GUI)?

Also, you haven’t mentioned which GUI you’re using:

  • KDE Plasma 5 (and therefore Digikam)?
  • GNOME with whatever photography support application?
  • Something else?

Sounds like a very concise summary/ confirmation of the situation as I was afraid it exists. The other replies lead me to much the same conclusion too. At some point I will have to try and get the 4.12.14 kernel working, but not 'til I get a break in my schedule. I’m currently needing to finish post processing over 3000 pictures that I’ve been dragging my feet on, so it’ll likely be a week or so before I can get to it. Thanks…

On second thought. I’m probably overdue for a fresh install. Maybe I’ll try that with 15 when I get time, Then I’ll work up from there. In the mean time the little project that needs Win 10 will have to be done on a borrowed pc.

The integrated Intel 620 device. The images we work with are all static, so no need for anything more sophisticated

Meaning that, the upgrade procedure you used, left the Leap 42.3 Kernel on the machine …

Correct, on a separate line under the one for the newly installed version.

When you say that, the “PC will not run with the new kernel” and “It would not boot reliably” do you mean that, the graphic display misbehaves when loading a Graphical User Interface (GUI)?

I should have said “won’t run at all”. Blank screen after grub, but my memory is less than perfect, so I will report in more detail after the next reboot.

Also, you haven’t mentioned which GUI you’re using:

  • KDE Plasma 5 (and therefore Digikam)?
  • GNOME with whatever photography support application?
  • Something else?

Darktable, Gimp and sometimes RawTherapee
(I do love Digikam’s photo organization capabilities, but it would add another level to my workflow, so I use Darktable’s Lighttable for that as well as post processing)

Hi, this thread might help you (but I didn’t test):

If you happen to have another system disk available, one you can use for a fresh installation, what happens if you boot the Leap 15 installation DVD or USB stick and simply install Leap 15 as a new installation?

You might find one or both of the following useful

The Arch Linux Wiki article on Intel Graphics
Describes some settings to avoid (AFAICSee all are non-default, but you should double-check), plus some possible tweaks after getting your display to work

Tweaks and optimizations
Without actually running, looks like the Fedora instructions should also work on openSUSE

In both of the above there are bits that apply to when you see a black screen…

Also, you should post the following from your HostOS so others know what graphics drivers you’re using

modinfo i915

You should also create a new Win10 guest to see if the problem is unique to your Guest or if the problem is more wide spread.
In any case, in the future you should always create a backup by simply creating a copy of your VM which would be useful for troubleshooting and rollbacks.


An Intel “HD Graphics 620” or, an Intel “UHD Graphics 620”?
Which Intel Core i? CPU? A 7000 Series or an 8000 Series?
The firmware required for the Skylake and Kabylake CPUs should be in the “kernel-firmware” package – for example, on this Leap 42.3 system:

 > rpm -ql kernel-firmware | grep -i 'i915'

You may also need some firmware for the Intel Graphics but, being an avid AMD fan, I have no idea what supplies that.

May not be relevant but FYI
This week’s Win10 “Patch Tuesday” update includes a fix for Win10 1803 on some systems to start up in a black screen.


HD Graphics 620 & I7-7500 2.7GHz

As you probably gathered I was really hesitant to do a fresh install without some confidence that I would be back up and running relatively quickly, but your suggestion got me thinking. I installed 15.0 on a spare USB external hard drive and found that it booted OTB and appears to be stable etc… I now have a much greater level of confidence that a reinstall will not be a disaster, so that’s the plan for tomorrow.

BTW. Yesterday I ran into a problem upgrading another I7 & Intel graphics laptop on-line. That one booted, but would not recognize Bluetooth, WIFI, USB or HDMI. I just tried booting that PC to the USB drive also, and it too was fully functional OTB. I conclude that there is something problematic about the on-line upgrade process I used (this one). To be sure the exact issues were different, but the bottom line was that neither upgrade was successful.

Possibly due to actual/current CPUs and GPUs being possibly rather picky about which firmware is loaded with the Linux Kernel …

After upgrading,
You might try running “zypper dup” again…
I’d be curious if in doing so you might be prompted to install or re-install more than a small handful of packages if even that.

Or, use a DVD to “upgrade” again.
That was how I resolved a machine that upgraded and apparently suffered a Network Manager issue in the middle of the upgrade.