After update to VirtualBox 5.2.22, Windows 8.1 VM fails to start

English Virtualization
#1

I updated my Tumbleweed “physical” installation (sudo zypper ref, sudo zypper dup) this morning to its latest state 20181203, using the standard repos only (OSS, Non-OSS, Update, packman, libdvdcss). This update brought the long-awaited VirtualBox 5.2.22, and I updated the extension pack to 5.2.22 as well.

Fortunately, I am running another Linux “physical” installation, Manjaro, which has VirtualBox 5.2.22 since almost day one of its release. My Windows 8.1-64 virtual machine has been running on this OS without any problems, with guest additions updated hereunder to 5.2.22, of course. So my VM was ready for Tumbleweed’s VirtualBox 5.2.22 … but:

After updating the Tumbleweed VirtualBox to 5.2.22, my Windows 8.1-64 virtual machine fails to start hereunder. It briefly shows the Microsoft logo and the circle-of-dots wait-spinner, then goes to a black screen forever. Moving the mouse a little bit makes the mouse cursor appear, with the little blue circular wait-spinner flashing about once or twice per second. It doesn’t get any further, and I have to switch the virtual machine off via the VirtualBox menu bar. This failure to boot the Windows VM happens every time now under Tumbleweed.

Going to Manjaro, its VirtualBox and trying to launch the Win 8.1 VM causes Windows to produce a blue screen first - “Looks like Windows couldn’t be started properly - Enter advanced repair options or Restart my PC now” (not the original messages, translated from German). Doing the “Restart my PC” luckily lets Windows boot correctly. This behavior can be reproduced - Manjaro okay, Tumbleeed fail, Manjaro with blue screen and okay only after said Restart.

Seems to me there is something wrong with VirtualBox 5.2.22 in Tumbleweed. Any ideas? Please let me know if I should give further help.

My machine is:

myself@susytmblwdke:~> inxi -Fxzd
System:    Host: susytmblwdke Kernel: 4.19.5-1-default x86_64 bits: 64 compiler: gcc v: 8.2.1 
           Desktop: KDE Plasma 5.14.3 Distro: openSUSE Tumbleweed 20181203 
Machine:   Type: Laptop System: Hewlett-Packard product: HP EliteBook 8560w v: A0001C02 serial: <filter> 
           Mobo: Hewlett-Packard model: 1631 v: KBC Version 01.3F serial: <filter> UEFI: Hewlett-Packard 
           v: 68SVD Ver. F.63 date: 10/27/2016 
Battery:   ID-1: BAT0 charge: 52.6 Wh condition: 52.6/52.6 Wh (100%) model: Hewlett-Packard Primary status: Full 
           Device-1: hidpp_battery_0 model: Logitech M705 charge: 80% status: Discharging 
CPU:       Topology: Dual Core model: Intel Core i5-2540M bits: 64 type: MT MCP arch: Sandy Bridge rev: 7 
           L2 cache: 3072 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 20752 
           Speed: 798 MHz min/max: 800/3300 MHz Core speeds (MHz): 1: 848 2: 799 3: 798 4: 810 
Graphics:  Device-1: NVIDIA GF108GLM [Quadro 1000M] vendor: Hewlett-Packard driver: nouveau v: kernel 
           bus ID: 01:00.0 
           Display: x11 server: X.Org 1.20.3 driver: nouveau unloaded: fbdev,modesetting,vesa 
           resolution: 1600x900~60Hz 
           OpenGL: renderer: llvmpipe (LLVM 6.0 256 bits) v: 3.3 Mesa 18.1.7 direct render: Yes 
Audio:     Device-1: Intel 6 Series/C200 Series Family High Definition Audio vendor: Hewlett-Packard 
           driver: snd_hda_intel v: kernel bus ID: 00:1b.0 
           Device-2: NVIDIA GF108 High Definition Audio vendor: Hewlett-Packard driver: snd_hda_intel v: kernel 
           bus ID: 01:00.1 
           Sound Server: ALSA v: k4.19.5-1-default 
Network:   Device-1: Intel 82579LM Gigabit Network vendor: Hewlett-Packard driver: e1000e v: 3.2.6-k port: 5020 
           bus ID: 00:19.0 
           IF: enp0s25 state: down mac: <filter> 
           Device-2: Intel Centrino Ultimate-N 6300 driver: iwlwifi v: kernel port: 4000 bus ID: 25:00.0 
           IF: wlo1 state: up mac: <filter> 
Drives:    Local Storage: total: 7.32 TiB used: 2.76 TiB (37.7%) 
           ID-1: /dev/sda vendor: Samsung model: SSD 850 PRO 2TB size: 1.86 TiB 
           ID-2: /dev/sdb vendor: Samsung model: SSD 860 EVO 4TB size: 3.64 TiB 
           ID-3: /dev/sdc vendor: Samsung model: SSD 850 EVO 2TB size: 1.82 TiB 
           Message: No Optical or Floppy data was found. 
Partition: ID-1: / size: 93.99 GiB used: 11.28 GiB (12.0%) fs: ext4 dev: /dev/sda4 
           ID-2: /home size: 47.00 GiB used: 569.9 MiB (1.2%) fs: ext4 dev: /dev/sda5 
           ID-3: swap-1 size: 18.76 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda9 
Sensors:   System Temperatures: cpu: 47.0 C mobo: N/A gpu: nouveau temp: 43 C 
           Fan Speeds (RPM): N/A 
Info:      Processes: 203 Uptime: N/A Memory: 15.61 GiB used: 1.37 GiB (8.8%) Init: systemd runlevel: 5 Compilers: 
           gcc: N/A Shell: bash v: 4.4.23 inxi: 3.0.27
#2

I have no issues and/or problems related to Oracle’s VirtualBox version 5.2.22 running on Leap 15.0 with “Microsoft Windows 10 Home” installed in the virtual machine.

#3

AFAIK, Tumbleweed had been holding back VirtualBox versions 5.2.20 and 5.2.22 for an unusual long time (several weeks, almost a month for 5.2.22). For versions before these two, Tumbleweed and Manjaro had been nicely in sync, i.e. each distro was releasing a new VirtualBox version quite shortly (a few days) after Oracle released them. Plus, I had been checking for VB on the other openSUSE distros, and - funny enough - Leap 15.0 had 5.2.22 long before Tumbleweed got it now.

To me, all this indicates that the Tumbleweed devs were aware of problems with these VB versions. And I dare to guess there are issues left with Tumbleweed’s VB 5.2.22, especially since my Win 8.1-64 VM (unchanged since mid-November patch day) keeps running fine under Manjaro’s VB 5.2.22.

PS: Nobody please tell me to run Windows 10 - I had it both physically and virtually until one or two of those big upgrades by Microsoft borked them to death (unrecoverable blue screens…). Now I am so glad I was no longer with Windows 10 when 1809 got dumped onto its users…

#4

I indicated that, VirtualBox version 5.2.22 running on an earlier Kernel version, seems to be OK running a different Redmond product in a VM …

  • The issue seems to be, a specific Redmond product running in a VM hosted on the Tumbleweed kernel …

[HR][/HR]@111MilesToGo:
For the Tumbleweed case, you may have to revert to an earlier VirtualBox version …

#5

Thanks for your comments.

Regarding the kernels: Manjaro has been going through all the 4.19.x kernels, no problem. Manjaro is one “.x” more advanced than Tumbleweed by now.

My workaround for the time being of course is to run VB under Manjaro only. That’s the nice aspect of having two physical Linux installations in multi-boot, both rolling releases, both in sync up to the latest software most of the time. Doing certain things on one Linux only comes into play when the other distro falls behind or somehow gets screwy - like with Tumbleweed’s VB for the past weeks. Running different versions of VB for the two Linux distros is not nice because of the guest additions, so one VB under one distro only for the time being.

Nevertheless: I would hope that the Tumbleweed devs get this VB 5.2.22 issue sorted out, please, if in fact it is such an issue. Otherwise, VB version 6 now is in its beta stages, which means a stable and reliable version 6 might be a long way down the road.

#6

I would hope that the Tumbleweed devs get this VB 5.2.22 issue sorted out, please, if in fact it is such an issue.

If nobody writes an bugreport…

#7

Hi
And your sure all the corresponding packages/kernel modules etc were updated to the 4.19.5 kernel?

In the other system if you ensure windows does a full shutdown (shutdown /s /t 5) does it still have issues booting in openSUSE?

If so, sounds more like a bug report is in order, the openSUSE Maintainer does peruse the forums from time to time, however bug reports would get his attention.

#8

Done, Bug 1118511](https://bugzilla.opensuse.org/show_bug.cgi?id=1118511).

#9

You should also inspect your Win8.1 system logs, focusing of course on the boot.
In Windows, that would be your Event Viewer.
Although you might find something labeled “critical,”
I’d instead advise you to locate the relevant “shutdown” and “startup” entries, the scroll forward until you see something that could be related to the boot problem.

The Event Viewer is typically sized to hold at least a couple weeks’ worth of entries, so your entries within the past few days should be there.

Be sure to add whatever you find to your bug report.

TSU

#10

[HR][/HR]Thanks, @malcolmlewis and @tsu2. Can do the Win logs only tomorrow. Yes, Win always has full shutdown because of sharing folders with Linuxes.

Let‘s see in parallel whether the VB maintainer has an idea.

#11

I looked at the Win 8.1 event logs, focusing on the date/time when I tried to boot the Windows VM under Tumbleweed’s VB. The errors come from Desktop Window Manager (fatal error 0x8898008d, showing up about twice per second), followed by a Kernel Power error (caused by shutting down the VM via the VB shutdown menu item). For reference, two detailed views:

- System 

  - Provider 

    Name]  Desktop Window Manager 
 
  - EventID 9020 

    Qualifiers]  49152 
 
   Level 2 
 
   Task 0 
 
   Keywords 0x80000000000000 
 
  - TimeCreated 

    SystemTime]  2018-12-05T07:50:13.000000000Z 
 
   EventRecordID 28655 
 
   Channel Application 
 
   Computer Win8_1-VM 
 
   Security 
 

- EventData 

   0x8898008d 



- System 

  - Provider 

    Name]  Microsoft-Windows-Kernel-Power 
    Guid]  {331C3B3A-2005-44C2-AC5E-77220C37D6B4} 
 
   EventID 41 
 
   Version 3 
 
   Level 1 
 
   Task 63 
 
   Opcode 0 
 
   Keywords 0x8000000000000002 
 
  - TimeCreated 

    SystemTime]  2018-12-05T07:52:14.082522200Z 
 
   EventRecordID 22405 
 
   Correlation 
 
  - Execution 

    ProcessID]  4 
    ThreadID]  8 
 
   Channel System 
 
   Computer Win8_1-VM 
 
  - Security 

    UserID]  S-1-5-18 
 

- EventData 

  BugcheckCode 0 
  BugcheckParameter1 0x0 
  BugcheckParameter2 0x0 
  BugcheckParameter3 0x0 
  BugcheckParameter4 0x0 
  SleepInProgress 0 
  PowerButtonTimestamp 0 
  BootAppStatus 0

Maybe this helps. I will append this also to the bugzilla report.

#12

Hmmm … I could resolve my issue on my own. Actually, it’s due to a little fault I committed a while ago. Very sorry for making public noise while taking a little circular detour on my learning curve!

What happened? I googled the Windows Desktop Window Manager fatal error message 0x8898008d, and while that remained as inconclusive as any Windows matter I got pointed towards a graphics card driver issue. Some bell started ringing faintly.

My laptop has an NVIDIA Quadro 1000M graphics card with GF108GFM GPU (“Fermi” GPU, NVIDIA support discontinued). I am using the nouveau driver with Tumbleweed, with Mesa-dri-nouveau 3D acceleration being blacklisted from the installation. It says to be experimental and in particular not recommended for KDE / Qt environments. (Well, I tested it shortly again, and in fact it caused screen freezes quite quickly.) With Manjaro, I am using the legacy video-nvidia-390xx driver. There had been reasons to use these particular set-ups for the two distros, but I forgot the full details of why (they are somewhere in my notes).

Hmmm, when VirtualBox versions fell out of sync between Manjaro and Tumbleweed (T being behind), I started using VB under Manjaro only, and at some point in time I did switch on 3D graphics acceleration. That was fine with Manjaro, but … yesterday … it was in conflict with my Tumbleweed, which doesn’t have 3D acceleration - and this had escaped from my memory until it came up again today.

Thank you so much for taking the time to offer your help. Encouraging me to look into the Windows logs was a good hint. Sorry again for the noise.

Two things left now: I have to mark this thread as Solved, and have to cancel the bugzilla report.

#13

Nicely done.

#14

Congrats.

TSU