Advisory, added to svn:

type: bugfix
subject: Updated virtualbox packages fix regression with recent kernels
src:
  8:
   core:
     - virtualbox-6.1.34-1.8.mga8
     - kmod-virtualbox-6.1.34-1.16.mga8
description: |
  The security fixes/hardenings in the random subsystem in upstream kernel
  5.15.44 series exposed an latent bug how virtualbox interacts with the
  kernel. The result showed up as virtual machines being unstable or even
  crashing on some systems with Intel CPUs. This update fixes those issues.
references:
 - https://bugs.mageia.org/show_bug.cgi?id=30567

Keywords: (none) => advisory

Ok on my AMD system with both i586 and x86_64 guests.

Uninstalled the unsigned test packages, installed the above from the repos
and rebooted before testing.
Uninstalled the unsigned guest additions and installled the signed guest additions
in both guests and rebooted them.

Played youtube videdos in both guests, to stress things a bit. Other then being
rather noisy having three different sound tracks at the same time, played ok. :-)

CC: (none) => davidwhodgins

mga8, x64
5.15.48-server-1.mga8
Installed the updates and launched a 32-bit Mageia guest running kernel 5.15.43-desktop586.  Installed guest-editions 6.1.32.
drag-and-drop and clipboard work both ways.  Failed to mount an external USB drive from the list of available devices - "Failed to create a proxy device".

CC: (none) => tarazed25

mga8-64 OK with kernel-desktop-5.15.48-1

Same system and tests as in Bug 30563 Comment 1 :
- Now both my guests that had problem there, works :)
(MSWindows7-64, BOINC LHC@home ATLAS workunit)

As usual also verified USB, host filesharing, clipboard, internet, window resizing...

CC: (none) => fri

Continuing from comment 3:
It occurred to me that there must be a 6.1.34 version of guest additions  but I cannot find it on the Virtualbox site.
However, I may have solved the USB problem.  There has always been difficulty installing the extension pack.  The last time that was successful was about two years ago or maybe three.  The key to it is to do everything as root including using firefox.  askpasswd is useless in this context.
# VBoxManage extpack cleanup
# cd Downloads
# firefox https://www.virtualbox.org
Download the required file (nothing happens if you do this as a user).
# .....VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-6.1.34.vbox-extpack0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Successfully installed "Oracle VM VirtualBox Extension Pack".

Hurray!
But no.  After a reboot external USB devices are still unavailable.

After seeing comment 5, I changed the settings for my x86_64 guest to add
an external usb drive. Started the guest. I can open the device in the file
manager and access the files.
# lsusb |head -n 1
Bus 001 Device 002: ID 0781:5591 SanDisk Corp. Ultra Flair

I had reverted my production desktop install to the 5.15.43 kernel because of this issue. After restoring the 5.15.46 kernel, I used qarepo to download and update. No installation issues. I did not have to update the extension pack.

I had one Mageia 8 Plasma guest that was so unstable before this update that it was unusable. After installing this update, it is normal once more.

After reading Comment 5, I too checked out USB. My venerable Deskjet 5650 had been detected and was ready to use, and when I plugged in a usb thumb drive the device manager detected it and asked me what I wanted to do with it. Removing the drive caused it to be removed from the guest's list of active USB devices. So, it seems to be acting normally.

My guest is set to use the USB 3 xHCI controller, because this system does have two USB 3.0 ports. I plugged an external usb 3 drive into one of those, and the device notifier detected it. But, before I could access it in Dolphin, I had to activate it  by clicking on the Devices menu, then usb, and then the device. But all this is normal behavior.

I have also checked this with the 5.15.48 server kernel, and it works there, too. If it weren't for Comment 5, I'd be inclined to OK this.

CC: (none) => andrewsfarm

(In reply to Len Lawrence from comment #5)
> The key to it is to do everything as root including using firefox

I always download the extpack as normal user, then 

$ sudo VBoxManage extpack install --replace Oracle_VM_VirtualBox_Extension_Pack-6.someversion.vbox-extpack

Bug 18962 - VirtualBox GUI Manager fails to install extension pack (have workarounds)

(In reply to Len Lawrence from comment #5)

 
> Hurray!
> But no.  After a reboot external USB devices are still unavailable.

is your user on the host a member of the vboxusers group ?

Also keep in mind that if you've selected safely remove on the host, the
usb device must be unplugged and plugged back in to be visible for selection.

In reply to comment 10:
Yes, user on host is a member of vboxusers.

That should have been in reply to comment 9.
In reply to comment 10:
I tried that sequence without success.  In the virtualbox interface the device is listed under the USB filters with all relevant information.  It is seen in vbox under the device tab but fails to connect.

Anyway, this vbox stuff is getting seriously off-topic so I shall pursue it elsewhere.  No regressions noted with the server kernel.

I disagree with it being off-topic. This bug is about fixing an issue with vbox on some systems. If that fix may be introducing a different regression on other systems, we at least need to examine it.

(In reply to Len Lawrence from comment #5)
> Continuing from comment 3:
> It occurred to me that there must be a 6.1.34 version of guest additions 
> but I cannot find it on the Virtualbox site.

We provide the guest additions in a Mageia package. Notice that a new version of the guest additions is in the list of rpms. Remember, they are installed in the guest, not the host. I don't believe that installing them on the host does any harm, and indeed I have noticed that if a system is installed from the Live isos on real hardware, the guest additions are installed, too. But they aren't necessary on the host.

But I messed up on my tests, as I failed to update the guest additions in my guest. The older ones do still work, as I still have access to shared folders, but when I get to that computer again I shall have to install the updated ones and test again.

Updated guest additions in the guest on the system from Comment 7. No installation issues. Rebooted the guest, with no issues noted. Shared folders still accessible, mouse and keyboard function are the same as before.

As far as I know guest additions don't govern usb 3.0 access, but I tested it again anyway. I was able to mount an external hard drive in a usb3 port, and a thumb drive in a usb 2.0 port, and copied a file from the first to the second with no issues.

@TJ, with regard to comment 13:
And I have to continue to disagree with you.  I am a complete amateur as far as virtualbox is concerned - always in trouble with this application - so the issue is the user not vbox.  Note that these problems have occurred with a succession of hardware over a period of seven years.  It is probably some setup misconfiguration.

OK, continuing the USB saga.  This is an i686 system; chose the i586 version of the guestbox-additions package.  Rebooted after installation.  Dismounted the USB device on the host and unplugged it.  Plugged it in again and selected the drive from the dev list and the host got in first and mounted it again.  How do you get past that?

Another attempt to connect to USB.  Unmounted the drive on the host so that it was still visible in the Devices list as hardware.  Clicked on the filter and still no connection:
"Failed to create a proxy device for the USB device (Error: VERR_PDM_NO_USB_PORTS)"

(In reply to Len Lawrence from comment #19)
> Another attempt to connect to USB.  Unmounted the drive on the host so that
> it was still visible in the Devices list as hardware.  Clicked on the filter
> and still no connection:
> "Failed to create a proxy device for the USB device (Error:
> VERR_PDM_NO_USB_PORTS)"

This means you need the extension pack installed to get it to work....

Meaning this one: https://download.virtualbox.org/virtualbox/6.1.34/Oracle_VM_VirtualBox_Extension_Pack-6.1.34.vbox-extpack

Oracle_VM_VirtualBox_Extension_Pack-6.1.34.vbox-extpack I downloaded yesterday from that link and installed without a problem.  Rebooted the guest several times since then.

Something far weirder has just happened.  The three other vboxes on this machine no longer boot at all, two x64 and another i686.  All three froze with the same message (IIRC)
Please install a kernel appropriate to your hardware.  x86_64 required, i686 detected.  
That makes no sense at all to me.  Crashed out using right-Ctrl and deleted each machine completely.  The one I have been using in the tests still boots.

Changed my mind about one of the bad vboxes and tried to reinstall Mageia8, 64-bit.  After hitting install the same peculiar message came up:
This kernel requires an x86-64 CPU, but only detected an i686 CPU.
Unable to boot - please use a kernel appropriate for your CPU.

About to create a new vdi and try again.

Nope.  Something must be corrupt.  Created a new vdi and then hit New.  At the naming stage there was no sign of 64-bit versions but I carried on with mageia 32-bit, assuming that was simple a string but in fact it seems to constrain the expected architecture to 32-bits because at the iso install stage  it failed again with the same message about finding an i686 CPU.

Looks like a case for removing all trace of VirtualBox from the system and starting from scratch.  Not today, and probably not this week.

Does it say:

Mageia (64-bit)

or

Mageia (32-bit)

for the vms that fail ?

Mageia (32-bit)

In at least one case, before I deleted it the system had originally booted as a 64-bit system but when I came to remove it and try to recreate it and reinstall it said Mageia (32-bit) only.

Does this have any significance?

$ file Oracle_VM_VirtualBox_Extension_Pack-6.1.34.vbox-extpack
Oracle_VM_VirtualBox_Extension_Pack-6.1.34.vbox-extpack: gzip compressed data, max compression, from TOPS/20, original size modulo 2^32 42705408

(In reply to Len Lawrence from comment #25)
> Mageia (32-bit)

This explains why it complains about 64bit kernel

(In reply to Len Lawrence from comment #26)
> In at least one case, before I deleted it the system had originally booted
> as a 64-bit system but when I came to remove it and try to recreate it and
> reinstall it said Mageia (32-bit) only.

Try to create a new vm, and ensure it's set as "Mageia (64-bit)"


(In reply to Len Lawrence from comment #27)
> Does this have any significance?
> 
> $ file Oracle_VM_VirtualBox_Extension_Pack-6.1.34.vbox-extpack
> Oracle_VM_VirtualBox_Extension_Pack-6.1.34.vbox-extpack: gzip compressed
> data, max compression, from TOPS/20, original size modulo 2^32 42705408

Nope.

And that package is intended to install on the host which has to be 64bit

Thanks Thomas.
Removed dkms-virtualbox and then installed it again.

Starting with a clean slate created a new VDI and found that Mageia 8 64-bit was offered this time, no 32-bit.
Pointed the IDE controller at the Mageia 8 64-bit iso and started the installation - that went smoothly but when it came to creating the partitions, starting with /boot I could not find ESP in the type list.  What type should be used?

Replying to comment 29:
Ran diskdrake on another vbox and noted that there was no boot partition so went ahead with the installation.

(In reply to Len Lawrence from comment #29)
> Thanks Thomas.
> Removed dkms-virtualbox and then installed it again.
> 
> Starting with a clean slate created a new VDI and found that Mageia 8 64-bit
> was offered this time, no 32-bit.
> Pointed the IDE controller at the Mageia 8 64-bit iso and started the
> installation - that went smoothly but when it came to creating the
> partitions, starting with /boot I could not find ESP in the type list.  What
> type should be used?

ESP is only available when booted in efi mode, but vbox efi mode is "so-so", so it defaults to non-efi installs

Thanks for the clarification Thomas.

This time everything ran smoothly.  The XHCI controller appeared from somewhere.  With that enabled the USB problem vanished and the rebooted system mounted the selected USB drive at boot.

Great.

flushing it out then :)

Whiteboard: (none) => MGA8-64-OK, MGA8-32-OK
Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

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

https://advisories.mageia.org/MGAA-2022-0087.html

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