No registered maintainer, but ghibo is the de facto maintainer, so assigning to ghibo :-)

Assignee: bugsquad => ghibomgx
CC: (none) => marja11

Ready for QA?

virtualbox-7.1.18-1.mga9 OK here, current and upcoming kernels, nvidia470

Simple test: just see if an old MSW XP 32 bit guest launch and use USB2.

Tested with
kernel desktop 6.6.130 with binary kmod
kernel desktop 6.6.137-1 with dkms built kmod
kernel-stable-testing-desktop-6.18.4-3, dkms built kmod


[morgan@republic ~]$ inxi -SMCG
System:
  Host: republic.tribun Kernel: 6.18.4-desktop-3.stabletesting.mga9
    arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 5.27.10 Distro: Mageia 9
Machine:
  Type: Laptop System: ASUSTeK product: G75VW v: 1.0
    serial: <superuser required>
  Mobo: ASUSTeK model: G75VW v: 1.0 serial: <superuser required>
    UEFI: American Megatrends v: G75VW.223 date: 01/07/2013
CPU:
  Info: quad core model: Intel Core i7-3610QM bits: 64 type: MT MCP cache:
    L2: 1024 KiB
  Speed (MHz): avg: 3086 min/max: 1200/3300 cores: 1: 3086 2: 3086 3: 3086
    4: 3086 5: 3086 6: 3086 7: 3086 8: 3086
Graphics:
  Device-1: NVIDIA GK107M [GeForce GTX 660M] driver: nvidia v: 470.256.02
  Device-2: Sunplus Innovation ASUS Webcam driver: uvcvideo type: USB
  Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X:
    loaded: nvidia,v4l gpu: nvidia resolution: 1920x1080~60Hz
  API: EGL v: 1.5 drivers: nvidia,swrast platforms: x11,surfaceless,device
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 470.256.02
    renderer: NVIDIA GeForce GTX 660M/PCIe/SSE2
  API: Vulkan v: 1.3.231 drivers: nvidia,llvmpipe surfaces: xcb,xlib

CC: (none) => fri

@Morgan: in Bug 35459 (new kernel) ghibo says the included kmods are for virtualbox-7.1.18-1 under testing in this bug, so it looks like it's supposed to be ready for QA. Making the assignment...

CC: (none) => andrewsfarm
Assignee: ghibomgx => qa-bugs

64-bit packages:

dkms-virtualbox-7.1.18-1.mga9.x86_64.rpm
python-virtualbox-7.1.18-1.mga9.x86_64.rpm
virtualbox-7.1.18-1.mga9.x86_64.rpm
virtualbox-devel-7.1.18-1.mga9.x86_64.rpm
virtualbox-guest-additions-7.1.18-1.mga9.x86_64.rpm
virtualbox-kernel-6.6.130-desktop-1.mga9-7.1.18-17.mga9.x86_64.rpm
virtualbox-kernel-6.6.130-server-1.mga9-7.1.18-17.mga9.x86_64.rpm
virtualbox-kernel-desktop-latest-7.1.18-17.mga9.x86_64.rpm
virtualbox-kernel-server-latest-7.1.18-17.mga9.x86_64.rpm

i586:

virtualbox-7.1.18-1.mga9.i586.rpm
virtualbox-guest-additions-7.1.18-1.mga9.i586.rpm

Host system: $ inxi -SMCG
System:
  Host: localhost Kernel: 6.6.130-server-1.mga9 arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 5.27.10 Distro: Mageia 9
Machine:
  Type: Desktop Mobo: ASUSTeK model: PRIME Q270M-C v: Rev X.0x
    serial: <superuser required> UEFI: American Megatrends v: 2201
    date: 12/21/2023
CPU:
  Info: quad core model: Intel Core i5-7500 bits: 64 type: MCP cache:
    L2: 1024 KiB
  Speed (MHz): avg: 800 min/max: 800/3800 cores: 1: 800 2: 800 3: 800 4: 800
Graphics:
  Device-1: NVIDIA GM107GL [Quadro K620] driver: nouveau v: kernel
  Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X:
    loaded: modesetting,v4l dri: nouveau gpu: nouveau resolution: 1920x1080~60Hz
  API: EGL v: 1.5 drivers: nouveau,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.5 compat-v: 4.3 vendor: mesa v: 25.0.7 renderer: NV117
  API: Vulkan v: 1.3.231 drivers: llvmpipe surfaces: xcb,xlib

No installation issues. Ran a Windows 7 guest, played around with no issues. Ran a Mageia 8 Plasma guest, got updates, including guest additions under test, played a game. No issues to report.

(In reply to Thomas Andrews from comment #3)

> @Morgan: in Bug 35459 (new kernel) ghibo says the included kmods are for
> virtualbox-7.1.18-1 under testing in this bug, so it looks like it's
> supposed to be ready for QA. Making the assignment...

Yes, ready.

CC: (none) => ghibomgx

Please next time have a few of consideration for the work of the rest of contributors.
One thing is updating an advisory to have new versions, and other is make new advisory & delete the obsolete advisory
Thanks

Source RPM: virtualbox-7.1.16-1.mga9.src.rpm => virtualbox-7.1.14-2.mga9,kmod-virtualbox-7.1.14-15.mga9

(In reply to Morgan Leijström from comment #2)

Same host and guest, now verified OK with
kernel desktop 6.6.137-1 with binary packaged kmod,
kernel-stable-testing-desktop-6.18.26-1 with dkms built kmod

It seems there was some overlap in the reports.

The main problem appears to be that in updates_testing, when a new package is built while a previous version is still undergoing QA testing, the older versions disappear. It would be beneficial to validate intermediate versions (as was the case with 7.1.16) before releasing the latest one. I think it would be helpful to preserve the packages in a repository before validation, so they aren't lost and 
can be published seamlessly after validation.

installing dkms-virtualbox-7.1.18-1.mga9.x86_64.rpm virtualbox-7.1.18-1.mga9.x86_64.rpm from //home/katnatek/qa-testing/x86_64
Preparing...                     ###################################################################################################
      1/2: dkms-virtualbox       ###################################################################################################
+ /usr/sbin/dkms --rpm_safe_upgrade add -m virtualbox -v 7.1.18-1.mga9

Creating symlink /var/lib/dkms/virtualbox/7.1.18-1.mga9/source ->
                 /usr/src/virtualbox-7.1.18-1.mga9

DKMS: add Completed.
+ '[' -z '' ']'
+ /usr/sbin/dkms --rpm_safe_upgrade build -m virtualbox -v 7.1.18-1.mga9

Preparing kernel 6.18.4-server-3.stabletesting.mga9 for module build:
(This is not compiling a kernel, just preparing kernel symbols)
Storing current .config to be restored when complete
Running Generic preparation routine
make mrproper....
using /proc/config.gz
make oldconfig....
make prepare.....

Building module:
cleaning build area....(bad exit status: 2)
./vboxbuild /lib/modules/6.18.4-server-3.stabletesting.mga9/build...........
cleaning build area....(bad exit status: 2)
cleaning kernel tree (make mrproper)....

DKMS: build Completed.
+ /usr/sbin/dkms --rpm_safe_upgrade install -m virtualbox -v 7.1.18-1.mga9

vboxdrv.ko.xz:
 - Installation
   - Installing to /lib/modules/6.18.4-server-3.stabletesting.mga9/dkms/3rdparty/vbox/

vboxnetflt.ko.xz:
 - Installation
   - Installing to /lib/modules/6.18.4-server-3.stabletesting.mga9/dkms/3rdparty/vbox/

vboxnetadp.ko.xz:
 - Installation
   - Installing to /lib/modules/6.18.4-server-3.stabletesting.mga9/dkms/3rdparty/vbox/

depmod...........

DKMS: install Completed.
+ /sbin/rmmod vboxnetflt
+ /sbin/rmmod vboxnetadp
+ /sbin/rmmod vboxdrv
+ /sbin/modprobe vboxdrv
+ /sbin/modprobe vboxnetflt
+ /sbin/modprobe vboxnetadp
+ :
      2/2: virtualbox            ###################################################################################################
      1/2: removing virtualbox-7.1.16-1.mga9.x86_64
                                 ###################################################################################################
+ /usr/sbin/dkms --rpm_safe_upgrade remove -m virtualbox -v 7.1.16-1.mga9 --all

-------- Uninstall Beginning --------
Module:  virtualbox
Version: 7.1.16-1.mga9
Kernel:  6.18.4-server-3.stabletesting.mga9 (x86_64)
-------------------------------------

Status: This module version was INACTIVE for this kernel.
depmod.......

DKMS: uninstall Completed.

------------------------------
Deleting module version: 7.1.16-1.mga9
completely from the DKMS tree.
------------------------------
Done.
      2/2: removing dkms-virtualbox-7.1.16-1.mga9.x86_64
                                 ###################################################################################################

Run VM with mageia 9 Plasma 64b as guest
Looks good

(In reply to Giuseppe Ghibò from comment #9)
> It seems there was some overlap in the reports.
> 
> The main problem appears to be that in updates_testing, when a new package
> is built while a previous version is still undergoing QA testing, the older
> versions disappear. It would be beneficial to validate intermediate versions
> (as was the case with 7.1.16) before releasing the latest one. I think it
> would be helpful to preserve the packages in a repository before validation,
> so they aren't lost and 
> can be published seamlessly after validation.

Or packagers just can check if exist a version pending of validation in madb before send new release, or the new version can be send to the original bug instead of open new.

(In reply to katnatek from comment #11)
> (In reply to Giuseppe Ghibò from comment #9)
> > It seems there was some overlap in the reports.
> > 
> > The main problem appears to be that in updates_testing, when a new package
> > is built while a previous version is still undergoing QA testing, the older
> > versions disappear. It would be beneficial to validate intermediate versions
> > (as was the case with 7.1.16) before releasing the latest one. I think it
> > would be helpful to preserve the packages in a repository before validation,
> > so they aren't lost and 
> > can be published seamlessly after validation.
> 
> Or packagers just can check if exist a version pending of validation in madb
> before send new release, or the new version can be send to the original bug
> instead of open new.

Yes, it's definitely something to keep in mind.

(In reply to Giuseppe Ghibò from comment #12)
> (In reply to katnatek from comment #11)
> > (In reply to Giuseppe Ghibò from comment #9)
> > > It seems there was some overlap in the reports.
> > > 
> > > The main problem appears to be that in updates_testing, when a new package
> > > is built while a previous version is still undergoing QA testing, the older
> > > versions disappear. It would be beneficial to validate intermediate versions
> > > (as was the case with 7.1.16) before releasing the latest one. I think it
> > > would be helpful to preserve the packages in a repository before validation,
> > > so they aren't lost and 
> > > can be published seamlessly after validation.
> > 
> > Or packagers just can check if exist a version pending of validation in madb
> > before send new release, or the new version can be send to the original bug
> > instead of open new.
> 
> Yes, it's definitely something to keep in mind.

Yes, we've had several bugs where a newer version superseded the original for the bug. There's a long history of that with kernels, for example.

No issues so far, this needs to go out so the kernel update can go.

Validating.

Keywords: (none) => validated_update
Whiteboard: (none) => MGA9-64-OK
CC: (none) => sysadmin-bugs

Where the kmod-virtualbox shoould be handled?

in kernel 6.6.137.

The kmods listed in this bug are for kernel 6.6.130, and should go with this bug since it goes out before kernel 6.6.137. The kmods for 6.6.137 will get pushed with the kernel.update.

(In reply to Thomas Andrews from comment #17)
> The kmods listed in this bug are for kernel 6.6.130, and should go with this
> bug since it goes out before kernel 6.6.137. The kmods for 6.6.137 will get
> pushed with the kernel.update.

The issue is srpm for 6.6.130 kmods is gone, so will not be possible push that modules in this bug, and is why I make bug 35459, block this update

(In reply to katnatek from comment #18)
> (In reply to Thomas Andrews from comment #17)
> > The kmods listed in this bug are for kernel 6.6.130, and should go with this
> > bug since it goes out before kernel 6.6.137. The kmods for 6.6.137 will get
> > pushed with the kernel.update.
> 
> The issue is srpm for 6.6.130 kmods is gone, so will not be possible push
> that modules in this bug, and is why I make bug 35459, block this update

I didn't realize that at the time. Sorry for the noise. I certainly don't wish to add to the confusion these bugs have generated.

(In reply to Thomas Andrews from comment #19)
> (In reply to katnatek from comment #18)
> > (In reply to Thomas Andrews from comment #17)
> > > The kmods listed in this bug are for kernel 6.6.130, and should go with this
> > > bug since it goes out before kernel 6.6.137. The kmods for 6.6.137 will get
> > > pushed with the kernel.update.
> > 
> > The issue is srpm for 6.6.130 kmods is gone, so will not be possible push
> > that modules in this bug, and is why I make bug 35459, block this update
> 
> I didn't realize that at the time. Sorry for the noise. I certainly don't
> wish to add to the confusion these bugs have generated.

I was thinking of an alternative approach that could be less confusing and might work given the kernel urgency:

1) Let's put the VirtualBox 7.1.18 bug on hold for a moment.

2) Ask the sysadmins to remove the "kmod-virtualbox-7.1.18-kernel-6.6.137" package from the `updates_testing` repository.

3) Build a new "kmod-7.1.14-kernel-6.6.137" module, this will be just the kernel prebuilt module for the already validated VirtualBox-7.1.14.

4) Validate kernel 6.6.137.

5) Return to the VirtualBox 7.1.18 bug.

6) Rebuild the "kmod-7.1.18-kernel-6.6.137" module.

7) Validate the VirtualBox 7.1.18 bug.

WDYT?

It would require some new, quick tests, as I believe I tested updating to VirtualBox 7.1.18 before I tested updating the kernel, meaning I have not tested VirtualBox 7.1.14 with kernel 6.6.137. 

Since I only have one MGA9 install left for testing VirtualBox(the rest have been upgraded to Cauldron), to get a proper test of the 7.1.14 kmod for kernel 6.6.137 I'd need to downgrade the tests I've done so far.

Not impossibly difficult, so I'd be OK with it. But, we'd need katnatek's input regarding playing musical chairs with the advisories.

(In reply to Thomas Andrews from comment #21)

> It would require some new, quick tests, as I believe I tested updating to
> VirtualBox 7.1.18 before I tested updating the kernel, meaning I have not
> tested VirtualBox 7.1.14 with kernel 6.6.137. 
> 
> Since I only have one MGA9 install left for testing VirtualBox(the rest have
> been upgraded to Cauldron), to get a proper test of the 7.1.14 kmod for
> kernel 6.6.137 I'd need to downgrade the tests I've done so far.
> 
> Not impossibly difficult, so I'd be OK with it. But, we'd need katnatek's
> input regarding playing musical chairs with the advisories.

OK, so, given how close we are, let's stay with the current RPMs.

For me the best solution possible is wait to kernel bugs.
For users that still want to use kernels previous to 6.6.137, we should recommend use the dkms-virtualbox module instead prebuild modules for previous kernels that will not be updated. I can add information about this in the advisory for this bug.

Hello,
Some users complain that virtualbox is no more usable after the kernel update to 6.4.137.

rpm -qa | grep virtual
virtualbox-7.1.14-2.mga9
virtualbox-kernel-6.6.120-desktop-1.mga9-7.1.14-14.mga9
virtualbox-kernel-6.6.130-desktop-1.mga9-7.1.14-15.mga9
virtualbox-kernel-desktop-latest-7.1.18-18.mga9
virtualbox-kernel-6.6.137-desktop-1.mga9-7.1.18-18.mga9
dkms-virtualbox-7.1.14-2.mga9
virtualbox-guest-additions-7.1.14-2.mga9

https://www.mageialinux-online.org/forum/topic-32547-0-336466-virtualbox-7-1-14-et-noyau-6-6-137.php

CC: (none) => yves.brungard

@Papoteur

Replacing VirtualBox version 7.1.14 by the 7.1.18 one solved my problem.
I can use it now with kernel 6.6.137

rpm -qa | grep virtual
virtualbox-kernel-6.6.120-desktop-1.mga9-7.1.14-14.mga9
virtualbox-kernel-6.6.130-desktop-1.mga9-7.1.14-15.mga9
virtualbox-kernel-desktop-latest-7.1.18-18.mga9
virtualbox-kernel-6.6.137-desktop-1.mga9-7.1.18-18.mga9
virtualbox-7.1.18-1.mga9
virtualbox-guest-additions-7.1.18-1.mga9
dkms-virtualbox-7.1.18-1.mga9

CC: (none) => temporis56

This update need to ship ASAP, as users update to released kernel 6.6.137 and have no kmod for previous version.

Priority: Normal => High

(In reply to papoteur from comment #24)
> Hello,
> Some users complain that virtualbox is no more usable after the kernel
> update to 6.4.137.
> 
> rpm -qa | grep virtual
> virtualbox-7.1.14-2.mga9
> virtualbox-kernel-6.6.120-desktop-1.mga9-7.1.14-14.mga9
> virtualbox-kernel-6.6.130-desktop-1.mga9-7.1.14-15.mga9
> virtualbox-kernel-desktop-latest-7.1.18-18.mga9
> virtualbox-kernel-6.6.137-desktop-1.mga9-7.1.18-18.mga9
> dkms-virtualbox-7.1.14-2.mga9
> virtualbox-guest-additions-7.1.14-2.mga9
> 
> https://www.mageialinux-online.org/forum/topic-32547-0-336466-virtualbox-7-1-
> 14-et-noyau-6-6-137.php

I think users should not mix dkms-virtualbox with virtualbox-kernel-* packages and should update to the packages in this bug also.

Dan please move ASAP the packages for this bug

CC: (none) => dan

Package moves are in progress.

I fixed a typo in the advisory, but there's a word in there that I can't make sense of: "think", and I'm not sure what the sentence is trying to say. Could you look that over? Any fixes will appear after the next security push.

Status: NEW => ASSIGNED

(In reply to Dan Fandrich from comment #28)
> Package moves are in progress.
> 
> I fixed a typo in the advisory, but there's a word in there that I can't
> make sense of: "think", and I'm not sure what the sentence is trying to say.
> Could you look that over? Any fixes will appear after the next security push.

please  think in use dkms-virtualbox package instead of virtualbox-kernel as
  that packages has not been updated for previous kernels.

I'm trying to say that is better use dkms-virtualbox for kernels previous to 6.6.137, not sure how write it in more compressive way :S

Is using dkms-virtualbox over virtualbox-kernel merely preferred or is it mandatory for kernels < 6.6.137? If it's mandatory, then perhaps "To run Virtualbox on kernels previous to 6.6.137, install the dkms-virtualbox package to create the necessary kernel modules for your kernel." But, I'm not completely sure I understand the requirement.

I dont know if it is optimal, but works for me:

I always have dkms-virtualbox installed. (and kernel-devel)
Thus I am guaranteed there is always a kernel module built.

And i use that in first pass test of VirtualBox when testing a new kernel.

Then, I install virtualbox-kernel when available, and test with that.

If I understand correctly it overwrites the kmod built kernel module, but it would be nice to have a confirmation on that.

(In reply to Dan Fandrich from comment #30)
> Is using dkms-virtualbox over virtualbox-kernel merely preferred or is it
> mandatory for kernels < 6.6.137? If it's mandatory, then perhaps "To run
> Virtualbox on kernels previous to 6.6.137, install the dkms-virtualbox
> package to create the necessary kernel modules for your kernel." But, I'm
> not completely sure I understand the requirement.

For kernels previous to 6.6.137 could be mandatory, I am not sure, the virtualbox-kernel packages that should go with this update can't be pushed because their src.rpm was replaced by the 6.6.137 version

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

https://advisories.mageia.org/MGASA-2026-0109.html

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

(In reply to Morgan Leijström from comment #31)
> I dont know if it is optimal, but works for me:
> 
> I always have dkms-virtualbox installed. (and kernel-devel)
> Thus I am guaranteed there is always a kernel module built.
> 
> And i use that in first pass test of VirtualBox when testing a new kernel.
> 
> Then, I install virtualbox-kernel when available, and test with that.
> 
> If I understand correctly it overwrites the kmod built kernel module, but it
> would be nice to have a confirmation on that.

Yes the dkms module "replace" the prebuild module but if you going to use dkms any way then is waste of space have bith

You have explained already it correctly.

It hasn't been changed since previous releases. What happened was that, due to the urgency of the kernel update and because the newer kmod (src.rpm) was already built for 7.1.16 (which had been under testing from a previous round), we had to skip an intermediate set of prebuilt modules for the combination of "an older VirtualBox-7.1.14 and a newer kernel-6.6.137". This led to some confusion.

dkms-virtualbox is only mandatory for kernels that don't provide prebuilt modules (e.g., kernel-linus or kernel-stable-testing). For other stock kernels, you can install either one or both (of course installing both, would consume a little more space). Prebuilt modules save building time and on-the-fly compilation, and allow the system to operate without needing any -devel packages installed, such as gccm gcc-devel, dkms and dkms-minimal.

In the past (mga8, and at the beginning of the mga9 cycle, etc.), we were used to releasing new kernels and newer VirtualBox updates together (contextually). However, we've seen that releasing them separately, with smaller steps (one before the other), results in smoother 
updates (and up to kernel 6.6.130 we were doing this). In this case, though, we had to skip that process.

When kmods are installed both ways, I have seen the command "dkms status" list both the dkms built module (lines ending in "installed", and prebuilt module (ending in "installed-binary from <kernel name here>") of same sort for same kernel.

-Which one gets use when there are both?

(In reply to Morgan Leijström from comment #36)

> When kmods are installed both ways, I have seen the command "dkms status"
> list both the dkms built module (lines ending in "installed", and prebuilt
> module (ending in "installed-binary from <kernel name here>") of same sort
> for same kernel.
> 
> -Which one gets use when there are both?

In case you have both sets installed, the module loaded is the one found first. The priority is determined by the file /etc/depmod.d/dkms.conf; in mga9 (and mga10), this file contains:

 search dkms dkms-binary built-in

This means that /lib/modules/<kernel_version>/dkms is searched first, then /lib/modules/<kernel_version>/dkms_binary second, and finally the modules included in the kernel packages.

/lib/modules/<kernel_version>/dkms_binary is where the prebuilt modules are moved, while /lib/modules/<kernel_version>/dkms is where the dkms-<package> modules are moved after they are built.

Therefore, as anticipated, dkms-<package> modules are searched first, followed by the prebuilt modules, and then by the internal kernel modules.

You can also create a custom config priority /etc/depmod.d/, for example, adding a 99_virtualbox.conf file there, to override the default lookup path for a 
specific module, using the "override" directive.

If there is no dkms-minimal package installed, then there is no /etc/depmod.d/dkms.conf file installed and the prority is determined by the hardcoded value of depmod (usually /lib/modules/<kernel_version>/).

You can check the path using "modinfo -n <module>", for example, "modinfo -n vboxdrv" will show you the path.

Thank you for the thorough explanation.
I will soon add some note on our Virtualbox wiki page.