on mga6-64  plasma

packages installed cleanly:
- dkms-virtualbox-5.2.24-1.mga6.noarch
- virtualbox-5.2.24-1.mga6.x86_64
- virtualbox-doc-5.2.24-1.mga6.noarch
- virtualbox-kernel-4.14.89-desktop-1.mga6-5.2.24-1.mga6.x86_64
- virtualbox-kernel-desktop-latest-5.2.24-1.mga6.x86_64

# dkms status
virtualbox, 5.2.24-1.mga6, 4.14.89-desktop-1.mga6, x86_64: installed 
virtualbox, 5.2.24-1.mga6, 4.14.89-desktop-1.mga6, x86_64: installed-binary from 4.14.89-desktop-1.mga6

vbox launched normally

extension pack updated cleanly

mga6-32 (plasma) and mga6-64 (plasma) clients launched normally,

updated vboxadditions and vboxvideo on mga6-32 and mga6-64 clients
both re-launched normally

win7 and winxp clients launched and updated normally

no regressions noted

OK for mga6-64 on this system:

Machine:   Device: desktop System: Dell product: Precision Tower 3620
           Mobo: Dell model: 09WH54 v: A00 UEFI [Legacy]: Dell v: 2.11.0 
CPU:       Quad core Intel Core i7-6700 (-HT-MCP-)
Graphics:  Card: Intel HD Graphics 530

CC: (none) => jim

OK mga6 64bit plasma
Using all updates from updates_testing including today's kernel 4.14.95-desktop-1.mga6.

Hardware: Intel i7, 8GB RAM, SSD, Nvidia GPU and driver, 4k screen.

Launched VB and in it i launched my old MSWindows7 which found updates and installed them successfully including reboots, seem to just work.

Mageia also had BOINC running topping up on all cores while testing this, and i was doing bookkeeping work. I did not notice any hickup.

The usual Bug 18962 : manual install of extpack ; I let VB GUI check for updates and download the extpack and fail, then i manually:
# VBoxManage extpack install --replace  /home/morgan/.config/VirtualBox/Oracle_VM_VirtualBox_Extension_Pack-5.2.24.vbox-extpack

CC: (none) => fri

Host system: Intel Core2Duo, 8GB RAM, Intel graphics, wired Internet.

The following 4 packages are going to be installed:

- virtualbox-5.2.24-1.mga6.x86_64
- virtualbox-doc-5.2.24-1.mga6.noarch
- virtualbox-kernel-4.14.89-desktop-1.mga6-5.2.24-1.mga6.x86_64
- virtualbox-kernel-desktop-latest-5.2.24-1.mga6.x86_64

All packages installed cleanly. Vbox launched normally. I used "Check for Updates" from within the program to update the extension pack. Ran a Windows XP guest and updated the guest additions. Ran a Mageia 6 Plasma guest, updated it, then updated to the 5.2.24 guest additions.

Everything worked normally. Confirming OK on this hardware.

(In reply to Morgan Leijström from comment #2)
 
> The usual Bug 18962 : manual install of extpack ; I let VB GUI check for
> updates and download the extpack and fail, then i manually:
> # VBoxManage extpack install --replace 
> /home/morgan/.config/VirtualBox/Oracle_VM_VirtualBox_Extension_Pack-5.2.24.
> vbox-extpack

Morgan, when you get to the point where you are asked for the root password, have you noticed a popup indicating the extpack is being installed appear before you get that password entered? I do, and have through several versions of vbox over the years.

When that popup appears, it becomes the active window. You have to click on the password window to make it the active one again, or the password you type will never get to it. Not getting the password is what causes the failure.

CC: (none) => andrewsfarm

(In reply to Thomas Andrews from comment #4)

Thanks, Iĺl try that next time :)
Also good you noted it on bug 18962

With all the updated components installed virtualbox can no longer launch any VMs on the test machine.  There is a problem with the host networking interface which has never shown up here before.

Shall try a few experiments.

CC: (none) => tarazed25

The suggestion about trying '/sbin/vboxconfig' did not work because the command could not be found.

Managed to roll back and launch a 32-bit client.  Then updated evrything and tried again.  Working to some extent.  Launched three VMs, one at a time using the nomodeset kernel parameter.  Those worked fine.  A fourth VM failed to get to a desktop - without nomodeset it simply hung with a blinking text cursor and block mouse pointer.  With nomodeset it showed the Plymouth cauldron for a couple of seconds then hung at "Started command scheduler.
Starting hold until boot process finishes up...".

Check for updates does not say anything about extension packs.  It runs  a check and comes back with "You are already running the latest version of virtualbox".  How do you get it to check for ext pack updates?

Used help to get to the virtualbox website and as usual failed to install the ext pack using virtualbox.  Re comment 4: the installation popup appears before there is time to click on the password window.

Tried download and manual install and saw exactly the same error after entering the root password and agreeing to T&C:

Failed to run /usr/lib64/virtualbox/VBoxExtPackHelperApp --stdout /tmp/VBoxExtPackHelper-cccww1/stdout --stderr /tmp/VBoxExtPackHelper-cccww1/stderr --elevated install --base-dir /usr/lib64/virtualbox/ExtensionPacks --cert-dir /usr/lib64/virtualbox/ExtPackCertificates --name 'Oracle VM VirtualBox Extension Pack' --tarball /home/lcl/.config/VirtualBox/Oracle_VM_VirtualBox_Extension_Pack-5.2.24.vbox-extpack --sha-256 5a3ee585e1c0f5006c563665af9f476d32539f73ee7728bee7b145bb659abb7d.

Failed to execute child process “/usr/lib64/virtualbox/VBoxExtPackHelperApp --stdout /tmp/VBoxExtPackHelper-cccww1/stdout --stderr /tmp/VBoxExtPackHelper-cccww1/stderr --elevated install --base-dir /usr/lib64/virtualbox/ExtensionPacks --cert-dir /usr/lib64/virtualbox/ExtPackCertificates --name 'Oracle VM VirtualBox Extension Pack' --tarball /home/lcl/.config/VirtualBox/Oracle_VM_VirtualBox_Extension_Pack-5.2.24.vbox-extpack --sha-256 5a3ee585e1c0f5006c563665af9f476d32539f73ee7728bee7b145bb659abb7d” (No such file or directory)

However, it works as su.  ??

Back to the fourth VM.  Restarted that with noquiet and nomodeset.
It faltered at the 8.55 second mark:
IFWLOG: register target
After a moment a popup window appears on the host with the message:
Creating process for virtual machine "keid" (GUI/Qt) ... (1/2)
0%

and there it hangs.

A successful launch of another VM on the same host was also accompanied by the "Starting VM" popup but appeared to freeze because it stayed at 0% and had to be killed via the window manager after the login on the VM.  The popup must be a new feature because I cannot remember seeing it before.

(In reply to Len Lawrence from comment #9)
> Check for updates does not say anything about extension packs.  It runs  a
> check and comes back with "You are already running the latest version of
> virtualbox".  How do you get it to check for ext pack updates?
> 
It checks for the extpack after it checks for the VB version. If nothing comes up, that's an indication that no extpack is installed, or at least none that it will recognize. A very old one might trigger the same activity. 

If nothing comes up, you have to go to the VB website and download it manually. Make sure you get the correct version, not the one for 6.0.x. All I've ever had to do then was click on the extpack file in the file manager window. Vbox comes up, as long as your user is part of the vboxusers group, looking to install it. Alternatively, it can be installed from the Vbox gui's File/Preferences/Extensions.

(In reply to Len Lawrence from comment #9)
> 
> Used help to get to the virtualbox website and as usual failed to install
> the ext pack using virtualbox.  Re comment 4: the installation popup appears
> before there is time to click on the password window.
> 
If the popup window happens to completely cover the password window, click on the title bar and move the popup out of the way. But you still have to click on the password window to make it the active one before it can accept the password.

@TJ; Thanks for the responses.
Re comment 12: Of course! why should ext pack updates be any different from our testing updates.  I should have thought of that.  
Yes, I went looking for 5.2.24.
I had completely forgotten File/Preferences/Extensions.  Need to get out more.

Re comment 13:
The password window is not obscured.  As far as I can remember you read the T&C, click on yes, the password window appears and almost immediately the installation popup appears at 0% and takes focus.  Clicking on the password window does no good at all after that.  The password is accepted and the error box appears.

On real hardware, M6.1, Plasma, 64-bit

Package(s) under test:
virtualbox

default install of packages:
kernel-desktop-latest
virtualbox vboxadditions-kernel-desktop-latest
virtualbox-guest-additions virtualbox-kernel-desktop-latest x11-driver-video-vboxvideo
kernel-desktop-devel-latest cpupower

The following 9 packages are going to be installed:

- virtualbox-5.2.22-1.1.mga6.x86_64
- virtualbox-doc-5.2.22-1.1.mga6.noarch
- vboxadditions-kernel-4.14.89-desktop-1.mga6-5.2.22-5.mga6.x86_64
- vboxadditions-kernel-desktop-latest-5.2.22-5.mga6.x86_64
- virtualbox-guest-additions-5.2.22-1.1.mga6.x86_64
- virtualbox-kernel-4.14.89-desktop-1.mga6-5.2.22-5.mga6.x86_64
- virtualbox-kernel-desktop-latest-5.2.22-5.mga6.x86_64
- x11-driver-video-vboxvideo-5.2.22-1.1.mga6.x86_64
- xrandr-1.5.0-1.mga6.x86_64

[root@localhost wilcal]# uname -a
Linux localhost 4.14.89-desktop-1.mga6 #1 SMP Mon Dec 17 13:14:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi virtualbox
Package virtualbox-5.2.24-1.mga6.x86_64 is already installed
[root@localhost wilcal]# urpmi virtualbox-guest-additions
Package virtualbox-guest-additions-5.2.24-1.mga6.x86_64 is already installed
[root@localhost wilcal]# urpmi virtualbox-kernel-desktop-latest
Package virtualbox-kernel-desktop-latest-5.2.24-1.mga6.x86_64 is already installed
[root@localhost wilcal]# urpmi x11-driver-video-vboxvideo
Package x11-driver-video-vboxvideo-5.2.24-1.mga6.x86_64 is already installed
[root@localhost wilcal]# urpmi x11-driver-video-vboxvideo
Package x11-driver-video-vboxvideo-5.2.24-1.mga6.x86_64 is already installed
[root@localhost wilcal]# urpmi dkms-nvidia-current
Package dkms-nvidia-current-390.87-1.mga6.nonfree.x86_64 is already installed
[root@localhost wilcal]# urpmi cpupower
Package cpupower-4.14.95-1.mga6.x86_64 is already installed
[root@localhost wilcal]# lspci -k
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 440] (rev a1)
        Subsystem: Gigabyte Technology Co., Ltd Device 3518
        Kernel driver in use: nvidia
        Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia_current

Mageia-6.1-LiveDVD-Xfce-i586-DVD.iso
Runs as a Vbox client.
Boots to a working desktop. Common apps work.
Screen sizes are correct.


install from updates testing:
virtualbox vboxadditions-kernel-desktop-latest dkms-virtualbox
virtualbox-guest-additions virtualbox-kernel-desktop-latest x11-driver-video-vboxvideo
kernel-desktop-devel-latest

The following 7 packages are going to be installed:

- cpupower-4.14.95-1.mga6.x86_64
- dkms-virtualbox-5.2.24-1.mga6.noarch
- virtualbox-5.2.24-1.mga6.x86_64
- virtualbox-guest-additions-5.2.24-1.mga6.x86_64
- virtualbox-kernel-4.14.89-desktop-1.mga6-5.2.24-1.mga6.x86_64
- virtualbox-kernel-desktop-latest-5.2.24-1.mga6.x86_64
- x11-driver-video-vboxvideo-5.2.24-1.mga6.x86_64

[root@localhost wilcal]# uname -a
Linux localhost 4.14.78-desktop-1.mga6 #1 SMP Sun Oct 21 20:31:12 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi kernel-desktop-latest
Package kernel-desktop-latest-4.14.78-1.mga6.x86_64 is already installed
[root@localhost wilcal]# urpmi virtualbox
Package virtualbox-5.2.22-1.1.mga6.x86_64 is already installed
[root@localhost wilcal]# urpmi vboxadditions-kernel-desktop-latest
Package vboxadditions-kernel-desktop-latest-5.2.22-2.mga6.x86_64 is already installed
[root@localhost wilcal]# urpmi dkms-virtualbox
Package dkms-virtualbox-5.2.22-1.1.mga6.noarch is already installed
[root@localhost wilcal]# urpmi virtualbox-guest-additions
Package virtualbox-guest-additions-5.2.22-1.1.mga6.x86_64 is already installed
[root@localhost wilcal]# urpmi virtualbox-kernel-desktop-latest
Package virtualbox-kernel-desktop-latest-5.2.22-2.mga6.x86_64 is already installed
[root@localhost wilcal]# urpmi x11-driver-video-vboxvideo
Package x11-driver-video-vboxvideo-5.2.22-1.1.mga6.x86_64 is already installed
[root@localhost wilcal]# urpmi kernel-desktop-devel-latest
Package kernel-desktop-devel-latest-4.14.78-1.mga6.x86_64 is already installed
[root@localhost wilcal]# urpmi dkms-nvidia-current
Package dkms-nvidia-current-390.87-1.mga6.nonfree.x86_64 is already installed
[root@localhost wilcal]# urpmi cpupower
Package cpupower-4.14.78-1.mga6.x86_64 is already installe
[wilcal@localhost ~]$ lspci -k
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 440] (rev a1)
        Subsystem: Gigabyte Technology Co., Ltd Device 3518
        Kernel driver in use: nvidia
        Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia_current

Mageia-6.1-LiveDVD-Xfce-i586-DVD.iso
Runs as a Vbox client.
Boots to a working desktop. Common apps work.
Screen sizes are correct.

Mageia-6.1-LiveDVD-GNOME-x86_64-DVD.iso
Runs as a Vbox client.
Boots to a working desktop. Common apps work.
Screen sizes are correct.

Mageia-Cauldron-netinstall-x86_64.iso
Runs as a Vbox client.
Installs from boot menu, updates then boots back to a working desktop.
Screen sizes are correct.

Hardware used:
Intel Core i5-4460 Haswell Quad-Core 3.2GHz LGA 115
Gigabyte GA-B85M-D3H LGA 1150 Intel B85 chipset
Integrated Graphics Processor - Intel HD Graphics support
Audito chipset - Realtek ALC892, 7.1 channels
Corsair Vengeance 8GB ( 2 x 4GB ) 240-pin DDR3 SDRAM 1600

CC: (none) => wilcal.int

This problem of the installation of the ext pack failing has been around a long time.  I have seen it dozens of times and always assumed the fault was at my end, like some software missing or being out of sync.  In any case, since the manual installation works fine maybe we can simply gloss over this fault.  It does not happen to everyone.

Yes, extpack install failing should not block this update and it has its own bug#.

(In reply to Len Lawrence from comment #14)
> 
> Re comment 13:
> The password window is not obscured.  As far as I can remember you read the
> T&C, click on yes, the password window appears and almost immediately the
> installation popup appears at 0% and takes focus.  Clicking on the password
> window does no good at all after that.  The password is accepted and the
> error box appears.

You also have to make sure that you click on the password entry field within the box. If you don't see "dots" appear within that field as you type in that password, it still isn't getting where it needs to go.

Since those who manage to install the extension pack are indicating that the update is working for them, and since those who had trouble getting the extension pack installed are indicating that is insufficient reason to hold this update back, I am validating it.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Re comment 18.  Yes I see the dots and the window disappears on Return - that is what I meant by "the password is accepted".
I continue to suspect that there is some subtle misconfiguration error somewhere.
Thanks.

I only mentioned it because I had it fail that way once with me. 

Even the most experienced of us can get tripped up by the simplest of things.

(In reply to Thomas Backlund from comment #0)
> Security fixes, advisory will follow.
When you can, please, Thomas.

CC: (none) => lewyssmith

type: security
subject: Updated virtualbox packages fix security vulnerabilities
CVE:
 - CVE-2019-2446
 - CVE-2019-2448
 - CVE-2019-2450
 - CVE-2019-2451
 - CVE-2019-2500
 - CVE-2019-2501
 - CVE-2019-2504
 - CVE-2019-2505
 - CVE-2019-2506
 - CVE-2019-2508
 - CVE-2019-2509
 - CVE-2019-2511
 - CVE-2019-2520
 - CVE-2019-2521
 - CVE-2019-2522
 - CVE-2019-2523
 - CVE-2019-2524
 - CVE-2019-2525
 - CVE-2019-2526
 - CVE-2019-2527
 - CVE-2019-2548
 - CVE-2019-2552
 - CVE-2019-2553
 - CVE-2019-2554
 - CVE-2019-2555
 - CVE-2019-2556
src:
  6:
   core:
     - virtualbox-5.2.24-1.mga6
     - kmod-virtualbox-5.2.24-1.mga6
     - kmod-vboxadditions-5.2.24-1.mga6
description: |
  Easily exploitable vulnerability allows low privileged attacker with logon
  to the infrastructure where Oracle VM VirtualBox executes to compromise
  Oracle VM VirtualBox. Successful attacks of this vulnerability can result
  in unauthorized access to critical data or complete access to all Oracle
  VM VirtualBox accessible data (CVE-2019-2446, CVE-2019-2448, CVE-2019-2450,
  CVE-2019-2451, CVE-2019-2554, CVE-2019-2555, CVE-2019-2556).

  Easily exploitable vulnerability allows low privileged attacker with logon
  to the infrastructure where Oracle VM VirtualBox executes to compromise
  Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox,
  attacks may significantly impact additional products. Successful attacks of
  this vulnerability can result in takeover of Oracle VM VirtualBox
  (CVE-2019-2500, CVE-2019-2524, CVE-2019-2548, CVE-2019-2552).

  Easily exploitable vulnerability allows low privileged attacker with logon
  to the infrastructure where Oracle VM VirtualBox executes to compromise
  Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox,
  attacks may significantly impact additional products. Successful attacks of
  this vulnerability can result in unauthorized read access to a subset of
  Oracle VM VirtualBox accessible data (CVE-2019-2501, CVE-2019-2504,
  CVE-2019-2505, CVE-2019-2506, CVE-2019-2553).

  Easily exploitable vulnerability allows low privileged attacker with logon
  to the infrastructure where Oracle VM VirtualBox executes to compromise
  Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox,
  attacks may significantly impact additional products. Successful attacks of
  this vulnerability can result in unauthorized ability to cause a hang or
  frequently repeatable crash (complete DOS) of Oracle VM VirtualBox
  (CVE-2019-2508, CVE-2019-2509, CVE-2019-2527).

  Easily exploitable vulnerability allows unauthenticated attacker with
  network access via SOAP to compromise Oracle VM VirtualBox. Successful
  attacks of this vulnerability can result in unauthorized ability to cause a
  hang or frequently repeatable crash (complete DOS) of Oracle VM VirtualBox
  (CVE-2019-2511).

  Difficult to exploit vulnerability allows low privileged attacker with
  logon to the infrastructure where Oracle VM VirtualBox executes to
  compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM
  VirtualBox, attacks may significantly impact additional products.
  Successful attacks of this vulnerability can result in takeover of Oracle
  VM VirtualBox (CVE-2019-2520, CVE-2019-2521, CVE-2019-2522, CVE-2019-2523,
  CVE-2019-2526).

  Difficult to exploit vulnerability allows low privileged attacker with
  logon to the infrastructure where Oracle VM VirtualBox executes to
  compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM
  VirtualBox, attacks may significantly impact additional products.
  Successful attacks of this vulnerability can result in unauthorized access
  to critical data or complete access to all Oracle VM VirtualBox accessible
  data (CVE-2019-2525).

  For other fixes in this update, see the referenced changelog.
references:
 - https://bugs.mageia.org/show_bug.cgi?id=24213
 - https://www.virtualbox.org/wiki/Changelog-5.2#v24
 - https://www.oracle.com/technetwork/security-advisory/cpujan2019-5072801.html#AppendixOVIR

openSUSE has issued an advisory for this on January 25:
https://lists.opensuse.org/opensuse-updates/2019-01/msg00087.html

Thanks David for the carefully formatted advisory, which almost fell into place. I added the reference above.

Keywords: (none) => advisory

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2019-0055.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED