I see it built for Cauldron too, including kmod.

@Packager:
* Still missing pre-built kmod for mga9 * for current kernels.


OK here 

Updated to
- dkms-virtualbox-7.0.24-1.mga9.x86_64
- virtualbox-7.0.24-1.mga9.x86_64
And rebooted.

kernel 6.6.65-desktop-2
dkms built kmod

TEST Running MSW 7 64 bit guest: 
On first launch it detected it needed new guest addition - I let it download & update.
Windows update found security updates, I let it update, and rebooted.
Tested dynamic window resizing, USB 2 flash disk, host folder sharing write protected and not, bidirectional clipboard, drag file from Dolphin to Explorer, Internet video in Firefox.

morgan@svarten ~]$ inxi -SMCG
System:
  Host: svarten.tribun Kernel: 6.6.65-desktop-2.mga9 arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 5.27.10 Distro: Mageia 9
Machine:
  Type: Desktop Mobo: ASRock model: P55 Pro serial: <superuser required>
    BIOS: American Megatrends v: P2.60 date: 08/20/2010
CPU:
  Info: quad core model: Intel Core i7 870 bits: 64 type: MT MCP cache:
    L2: 1024 KiB
  Speed (MHz): avg: 3213 min/max: 1200/2934 cores: 1: 3213 2: 3213 3: 3213
    4: 3213 5: 3213 6: 3213 7: 3213 8: 3213
Graphics:
  Device-1: Advanced Micro Devices [AMD/ATI] Navi 24 [Radeon RX 6400/6500
    XT/6500M] driver: amdgpu v: kernel
  Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X:
    loaded: amdgpu,v4l dri: radeonsi gpu: amdgpu resolution: 3840x2160~60Hz
  API: EGL v: 1.5 drivers: kms_swrast,radeonsi,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6 vendor: amd mesa v: 24.2.8 renderer: AMD Radeon RX
    6400 (radeonsi navi24 LLVM 15.0.6 DRM 3.54 6.6.65-desktop-2.mga9)


I plan to repeat tests with prebuilt kmod when it appears, and with new kernels I see building.

Assignee: kernel => qa-bugs
Whiteboard: MGA9TOO => (none)
Version: Cauldron => 9

CC usual VBox testers

CC: (none) => andrewsfarm, brtians1

Packages list

i586:
virtualbox-7.0.24-1.mga9.i586.rpm
virtualbox-guest-additions-7.0.24-1.mga9.i586.rpm

x86_64:
dkms-virtualbox-7.0.24-1.mga9.x86_64.rpm
python-virtualbox-7.0.24-1.mga9.x86_64.rpm
virtualbox-7.0.24-1.mga9.x86_64.rpm
virtualbox-devel-7.0.24-1.mga9.x86_64.rpm
virtualbox-guest-additions-7.0.24-1.mga9.x86_64.rpm

SRPM:
virtualbox-7.0.24-1.mga9.src.rpm

Is not supposed that 32b host are unsupported since some time ago?
Adding to Giuseppe who usually updates the kmod vbox

Keywords: (none) => advisory

Yes VB is only 64b

(In reply to Morgan Leijström from comment #1)
> * Still missing pre-built kmod for mga9 * for current kernels.

Is built now, testing...

(In reply to Morgan Leijström from comment #5)
> Yes VB is only 64b
> 
> (In reply to Morgan Leijström from comment #1)
> > * Still missing pre-built kmod for mga9 * for current kernels.
> 
> Is built now, testing...

I see also kernel are in wat perhaps wise wait until reports for kernels
 come

(In reply to katnatek from comment #6)
> (In reply to Morgan Leijström from comment #5)
> > Yes VB is only 64b
> > 
> > (In reply to Morgan Leijström from comment #1)
> > > * Still missing pre-built kmod for mga9 * for current kernels.
> > 
> > Is built now, testing...
> 
> I see also kernel are in wat perhaps wise wait until reports for kernels
>  come

To avoid conflicts, let's validate virtualbox before, then kernel (6.6.74) later for which will be built the corresponding kmod-virtualbox after virtualbox 7.0.24 has been validated.

I repeated my test procedure in Comment 1 on same system, running:

§ kernel-linus-6.6.65-1 with dkms built kmod

§ kernel-server-6.6.65-2 with packaged module (virtualbox-kernel-6.6.65-server-2.mga9-7.0.24-63.mga9)

All OK.

I also paused and restarted the guest.


Plus also test OK kernel 6.6.74-server-1, dkms built kmod

---

Sidenote: also running 6.6.74 on two laptops OK
I see new mesa is building too, more fun tomorrow :)
- Please open bug reports to QA!

(In reply to Morgan Leijström from comment #5)
> Yes VB is only 64b

More exactly we seem to on mga9 support running it as a guest so we have 'virtualbox-guest-additions' packages and also a 'virtualbox' package but it is tiny and I do not know what it is for?

I just realise we have
https://wiki.mageia.org/en/QA_procedure:VirtualBox
- see there what is left to test.
For example install mga9 32 bit as guest :)

MGA9-64 Plasma i5-7500, nvidia Quadro K620 graphics.

Updated VirtualBox and kmods, rebooted just to be sure, then ran Windows 7 and Windows 10 guests, installed guest additions with no issues. Rebooted each guest, no issues to report.

Booted a MGA9-64 guest that hadn't been run in a while, used qarepo to get the guest additions package, then got 43 updates, rebooted the guest, all is well.

Looks good so far.

Guest install tested in Bug 26214 Comment 28

This is about how much we test point version updates

Validating

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

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

https://advisories.mageia.org/MGASA-2025-0027.html

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

We forgot/left out of pushing the kmod-virtualbox modules prepared for kernel*6.6.65-2.mga9. I see in mirrors virtualbox gone, but those modules still there.

(In reply to Giuseppe Ghibò from comment #14)
> We forgot/left out of pushing the kmod-virtualbox modules prepared for
> kernel*6.6.65-2.mga9. I see in mirrors virtualbox gone, but those modules
> still there.

I think they sould be included in packages to remove as they have the -1 release and the current ones have the -2 release

Added to https://bugs.mageia.org/show_bug.cgi?id=33791

according to mirrors I see these ones:

virtualbox-kernel-server-latest-7.0.24-63.mga9.x86_64.rpm
virtualbox-kernel-6.6.65-desktop-2.mga9-7.0.24-63.mga9.x86_64.rpm
virtualbox-kernel-6.6.65-server-2.mga9-7.0.24-63.mga9.x86_64.rpm
virtualbox-kernel-desktop-latest-7.0.24-63.mga9.x86_64.rpm

the other are pushed.

The new virtualbox update tries to install dkms, kernel-desktop-devel and a *lot* of other -devel packages. Why is this happening? Is it a bug? I don't want them.

(In reply to Giuseppe Ghibò from comment #16)
> according to mirrors I see these ones:
> 
> virtualbox-kernel-server-latest-7.0.24-63.mga9.x86_64.rpm
> virtualbox-kernel-6.6.65-desktop-2.mga9-7.0.24-63.mga9.x86_64.rpm
> virtualbox-kernel-6.6.65-server-2.mga9-7.0.24-63.mga9.x86_64.rpm
> virtualbox-kernel-desktop-latest-7.0.24-63.mga9.x86_64.rpm
> 
> the other are pushed.

Let's see this are generated by kmod-virtualbox-7.0.24-63.mga9.src.rpm , and is not include in this report

As long as I can see that packages are no tested so should be tested before call to sysadmins

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

Then we need to update the files list and validate the missed files.

after testing them.

good spotting, kmod it was missed there. But SRPMS lists is usually the version to be replaced, not the version replacing. There is still a typo -> "irtualbox".

Packages to test in comment#16 
Note that is for kernels 6.6.65

yes, kernel 6.6.65. After all the modules will be validated, I'll rebuild kmod for kernel 6.6.74 and include those in 6.6.74's bug.

My test in comment 11 used 
virtualbox-kernel-6.6.65-desktop-2.mga9-7.0.24-63.mga9.x86_64.rpm and has been for several days.

In addition, another test that I never reported, on an HP Pavilion 15, used the same kmod. I haven't used it as much, but I have used it.

Once the source rpm field has been corrected, you can give the OK and re-validate.

Ah. I see now the OK and validation hadn't been removed. Do we need to remove them and then restore them to satisfy requirements, or can we just go with it as it is?

(In reply to Thomas Andrews from comment #25)
> Ah. I see now the OK and validation hadn't been removed. Do we need to
> remove them and then restore them to satisfy requirements, or can we just go
> with it as it is?

I let that to your consideration, If we can have just another confirmation would be good, but as you are regular tester I think should be good

Just tell me if I call to Dan to help

(In reply to katnatek from comment #18)
> Let's see this are generated by kmod-virtualbox-7.0.24-63.mga9.src.rpm , and
> is not include in this report
> 
> As long as I can see that packages are no tested so should be tested before
> call to sysadmins

This still doesn't answer the question why are dkms and all these -devel packages suddenly needed? This has never been the case in the past for previous kernel updates.

(In reply to katnatek from comment #26)

> (In reply to Thomas Andrews from comment #25)
> > Ah. I see now the OK and validation hadn't been removed. Do we need to
> > remove them and then restore them to satisfy requirements, or can we just go
> > with it as it is?
> 
> I let that to your consideration, If we can have just another confirmation
> would be good, but as you are regular tester I think should be good
> 
> Just tell me if I call to Dan to help

IMHO everything would be fine by just releasing the extra missed files.

(In reply to Frédéric "LpSolit" Buclin from comment #27)
> (In reply to katnatek from comment #18)
> > Let's see this are generated by kmod-virtualbox-7.0.24-63.mga9.src.rpm , and
> > is not include in this report
> > 
> > As long as I can see that packages are no tested so should be tested before
> > call to sysadmins
> 
> This still doesn't answer the question why are dkms and all these -devel
> packages suddenly needed? This has never been the case in the past for
> previous kernel updates.

That is a call for Giuseppe but I see they are required by dkms-virtualbox , virtualbox-guest-additions and virtualbox and that is at less from previous version

Are the -devel and dkms packages functionally needed if using pre built kmod?

The following should not hold this up, but I note it here to remember.
**********************************************************************
I have seen it once before, and this time I know what I did: 

Launched VirtualBox from CLI,
launched and put my guest to work.
Suspended host.
resumed host.
Closed guest.
When then closing VirtualBox GUI, in terminal the output:

-----8<------

!!Assertion Failed!!
Expression: state <= 1 && ( (state == 0 && count == 0) || (state == 1 && count < PR_UINT32_MAX/2))
Location  : /home/iurt/rpmbuild/BUILD/VirtualBox-7.0.24/src/libs/xpcom18a4/xpcom/components/nsComponentManager.cpp(931) virtual nsrefcnt nsComponentManagerImpl::AddRef()
Stack     :

AddRef: illegal refcnt=3221225469 state=2
Spårningsfälla (minnesutskrift skapad)

------>8------

Last is Swedish, meaning literally  "Tracking trap (memory printout created)"

This seem harmless.  Just strange.

Just now this was with kernel linus 6.6.74-1, I have forgot which of .65 and 74 kernel I saw it with last time, but it was not .74 linus.

(In reply to Frédéric "LpSolit" Buclin from comment #27)
> (In reply to katnatek from comment #18)
> > Let's see this are generated by kmod-virtualbox-7.0.24-63.mga9.src.rpm , and
> > is not include in this report
> > 
> > As long as I can see that packages are no tested so should be tested before
> > call to sysadmins
> 
> This still doesn't answer the question why are dkms and all these -devel
> packages suddenly needed? This has never been the case in the past for
> previous kernel updates.

Ah sorry I understand it now as Giuseppe says is due the missing packages in comment#16 If you install what you need from updates_testing or get them by qarepo and perform a update should fix the issue and will be a extra test to can move the missing rpms

(In reply to katnatek from comment #26)
> (In reply to Thomas Andrews from comment #25)
> > Ah. I see now the OK and validation hadn't been removed. Do we need to
> > remove them and then restore them to satisfy requirements, or can we just go
> > with it as it is?
> 
> I let that to your consideration, If we can have just another confirmation
> would be good, but as you are regular tester I think should be good
> 
> Just tell me if I call to Dan to help

There was a report of a test of the server kmod in comment 8.

Go ahead and call Dan. We need to get this out before more users have the same experience as Frederic.

@Frederic: Because the prebuilt kmods were not released with the rest of the update (as they should have been. Our mistake.), the dkms package was pulled in to build them locally. This, in turn, pulled in those other devel packages. If you can wait until the prebuilt kmods are pushed before you update the virtualbox packages, you shouldn't need any of the devel packages that aren't already installed.

So, what's the consensus on fixing this? Update 33952.adv to add the additional packages and push them manually? Or is the -devel dependency issue going to be fixed in a new bug and we just piggyback on that? Updating 33952 leaves anyone looking at the original push e-mail missing some packages, although anyone looking at the copy on the web will see the update.

CC: (none) => dan

@Dan Fandrich
I update the advisory for this bug adding the missing src.rpm and updating the subject, could you please move
ASAP packages in comment#16 produced by kmod-virtualbox-7.0.24-63.mga9

Thank you

(In reply to Dan Fandrich from comment #34)
> So, what's the consensus on fixing this? Update 33952.adv to add the
> additional packages and push them manually? Or is the -devel dependency
> issue going to be fixed in a new bug and we just piggyback on that? Updating
> 33952 leaves anyone looking at the original push e-mail missing some
> packages, although anyone looking at the copy on the web will see the update.

The first the second is produced due to missing packages that should be included in this update

I think the -devel issue is expected behavior under this situation, virtualbox pushed without the kmods.

I just ran another system that has vbox installed with just the prebuilt kmods. I went after updates, and was told I needed to choose one of the kernel-devel packages, and install all the dkms-related stuff that would be needed to build the kmods locally. 

I backed out without updating, and used qa repo to download the kmod candidates. (BTW, there's a lot of old kmods in testing that need to be removed...) Then I went back to updates, and this time the dkms and devel packages weren't brought up. I updated, and rebooted. VirtualBox worked perfectly for a very quick test.

One last thing: I believe we shouldn't try to "fix" the -devel dependencies for virtualbox. 

The way they are, should we at some time in the future decide we aren't going to pre-build the kmods, as we once had to do with the nvidia drivers, then the transition from prebuilt to locally built would already be built in.

I've moved the kmod-virtualbox-7.0.24-63.mga9.src.rpm packages and update the advisories web site with the updated 33952.adv.

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

(In reply to Dan Fandrich from comment #39)
> I've moved the kmod-virtualbox-7.0.24-63.mga9.src.rpm packages and update
> the advisories web site with the updated 33952.adv.

Thank you very much

Good this was handles quickly :)

(In reply to Thomas Andrews from comment #37)
> (BTW, there's a lot of old kmods in testing that need to be removed...)

Handled in Bug 33791

(TJ #38)
> One last thing: I believe we shouldn't try to "fix" the -devel dependencies
> for virtualbox. 
> 
> The way they are, should we at some time in the future decide we aren't
> going to pre-build the kmods, as we once had to do with the nvidia drivers,
> then the transition from prebuilt to locally built would already be built in.

I agree fully.
- And now we got this fallback tested :)

(In reply to Thomas Andrews from comment #38)
> One last thing: I believe we shouldn't try to "fix" the -devel dependencies
> for virtualbox. 
> 
> The way they are, should we at some time in the future decide we aren't
> going to pre-build the kmods, as we once had to do with the nvidia drivers,
> then the transition from prebuilt to locally built would already be built in.

But actually it seems already correct.

There is the kmod(vboxdrv) virtual dependency which is provided either in dkms-virtualbox as well as in kmod-virtualbox packages. So either one or the other would be retrieved.

The nvidia kmod were pulled because of license reasons about redistributing bin kmod files.

We all agree :)

---

Re my Comment 31:
When I first observed it it was with, from my terminal log
$ dkms status
virtualbox, 7.0.24-1.mga9, 6.6.65-desktop-2.mga9, x86_64: installed

So both cases with dkms built kmod, with .65 desktop and .74 linus kernels.
I have not stressed it, maybe happens in other cases by suspend-resume.