For security,

https://www.oracle.com/security-alerts/cpuoct2023.html#AppendixOVIR

for lists have to check in a while.

You should include the kmods for our current kernel in this bug. Updating to a new kernel doesn't remove the old one, and if for whatever reason a user who doesn't have dkms-virtualbox installed wants/needs to boot into that kernel, Virtualbox will no longer work.

Look at previous Virtualbox updates that were close to a kernel update. That is what TMB used to do.

CC: (none) => andrewsfarm

In bug 32482 ghibo said:


Ok, kmod-virtualbox-7.0.12-35.mga9.src.rpm built, providing:

> virtualbox-kernel-6.4.16-desktop-3.mga9-7.0.12-35.mga9.x86_64.rpm
> virtualbox-kernel-6.4.16-server-3.mga9-7.0.12-35.mga9.x86_64.rpm
> virtualbox-kernel-desktop-latest-7.0.12-35.mga9.x86_64.rpm
> virtualbox-kernel-server-latest-7.0.12-35.mga9.x86_64.rpm

> which is for current kernel-6.4.16-3.mga9. After that we'll pushed virtualbox,
> we'll provide kmod-virtualbox-7.0.12-36.mga9 for 6.4.16-5.mga9 (can't now yet
> because otherwise the .src.rpm will be overridden). kmod files list in #32490
> needs to be updated accordingly.

So, IIUCm for this update, we now have:

 
SRPMS:
virtualbox-7.0.12-2.mga9
kmod-virtualbox-7.0.12-35.mga9

i586:
virtualbox-7.0.12-2.mga9.i586.rpm
virtualbox-guest-additions-7.0.12-2.mga9.i586.rpm


x86_64:
dkms-virtualbox-7.0.12-2.mga9.x86_64.rpm
python-virtualbox-7.0.12-2.mga9.x86_64.rpm
virtualbox-7.0.12-2.mga9.x86_64.rpm
virtualbox-devel-7.0.12-2.mga9.x86_64.rpm
virtualbox-guest-additions-7.0.12-2.mga9.x86_64.rpm
virtualbox-kernel-6.4.16-desktop-3.mga9-7.0.12-35.mga9.x86_64.rpm
virtualbox-kernel-6.4.16-server-3.mga9-7.0.12-35.mga9.x86_64.rpm
virtualbox-kernel-desktop-latest-7.0.12-35.mga9.x86_64.rpm
virtualbox-kernel-server-latest-7.0.12-35.mga9.x86_64.rpm

Please correct me if I misunderstood

Advisory with the 2 SRPMs from comment 6 added to SVN. 
Included are also the 3 CVEs with their description and these links:
https://www.virtualbox.org/wiki/Changelog-7.0#v12
https://www.oracle.com/security-alerts/cpuoct2023.html#AppendixOVIR

Please remove the "advisory" keyword if it needs to be changed. It also helps when obsolete advisories are tagged as "obsolete"

Keywords: (none) => advisory

(In reply to Marja Van Waes from comment #7)
> Advisory with the 2 SRPMs from comment 6 added to SVN. 

it can be read here: https://svnweb.mageia.org/advisories/32490.adv?revision=15226&view=markup

MGA9-64 Plasma. Installed without issues with kernel 6.4.16-3. This particular host happened to have dkms-virtualbox installed. (I have other installs that do not.)

A MGA9 Plasma guest booted with no issues. I updated the guest additions, then did a quick check and everything seemed to work.

A MGA8 Plasma guest booted without issues. It did tell me the guest additions are outdated, but the 7.0.10 additions still seem to work. I don't believe we need to provide a guest additions update for MGA8 this close to its EOL, unless the lack of it breaks the upgrade path somehow.

A Windows 7 Professional guest booted without issues, but when I attempted to update the guest additions Windows complained that the CD iso downloaded from https://download.virtualbox.org/virtualbox/7.0.12/ had a bad signature, and refused to install it. This is not unheard of; another recent Virtualbox version had issues with the guest additions CD. It is surely an upstream problem.

If you have kmod installed from packages you might uninstall dkms-virtualbox installed. Probably you got it installed because you tried on 6.5.x series.

For the bad signature on ISO Guest Additions online downloading, I got the same problems too (but IIRC it was also happening on previous releases such as 7.0.10). Sometimes it downloads but then the progress bar no longer completes even if the file is completely downloaded. I bypassed downloading the tools by hand from:

https://download.virtualbox.org/virtualbox/7.0.12/VBoxGuestAdditions_7.0.12.iso

and then inserting the ISO as a plain CD/DVD. Apparently is reported upstream here https://www.virtualbox.org/ticket/21883.

For the files list above it should be completed with the following entries:

x86_64:
virtualbox-kernel-6.4.16-desktop-3.mga9-7.0.12-35.mga9.x86_64.rpm
virtualbox-kernel-6.4.16-server-3.mga9-7.0.12-35.mga9.x86_64.rpm
virtualbox-kernel-desktop-latest-7.0.12-35.mga9.x86_64.rpm
virtualbox-kernel-server-latest-7.0.12-35.mga9.x86_64.rpm

SRPMS:
kmod-virtualbox-7.0.12-35.mga9.src.rpm

after virtualbox 7.0.12 will be pushed we'll add a kmod-virtualbox-7.0.12-36.mga9.src.rpm in the kernel bug packages list itself with modules built for 6.4.16-{desktop,server}-5.mga9.

CC: (none) => ghibomgx

(In reply to Marja Van Waes from comment #6)
> In bug 32482 ghibo said:
> 
> 
> Ok, kmod-virtualbox-7.0.12-35.mga9.src.rpm built, providing:
> 
> > virtualbox-kernel-6.4.16-desktop-3.mga9-7.0.12-35.mga9.x86_64.rpm
> > virtualbox-kernel-6.4.16-server-3.mga9-7.0.12-35.mga9.x86_64.rpm
> > virtualbox-kernel-desktop-latest-7.0.12-35.mga9.x86_64.rpm
> > virtualbox-kernel-server-latest-7.0.12-35.mga9.x86_64.rpm
> 
> > which is for current kernel-6.4.16-3.mga9. After that we'll pushed virtualbox,
> > we'll provide kmod-virtualbox-7.0.12-36.mga9 for 6.4.16-5.mga9 (can't now yet
> > because otherwise the .src.rpm will be overridden). kmod files list in #32490
> > needs to be updated accordingly.
> 
> So, IIUCm for this update, we now have:
> 
>  
> SRPMS:
> virtualbox-7.0.12-2.mga9
> kmod-virtualbox-7.0.12-35.mga9
> 
> i586:
> virtualbox-7.0.12-2.mga9.i586.rpm
> virtualbox-guest-additions-7.0.12-2.mga9.i586.rpm
> 
> 
> x86_64:
> dkms-virtualbox-7.0.12-2.mga9.x86_64.rpm
> python-virtualbox-7.0.12-2.mga9.x86_64.rpm
> virtualbox-7.0.12-2.mga9.x86_64.rpm
> virtualbox-devel-7.0.12-2.mga9.x86_64.rpm
> virtualbox-guest-additions-7.0.12-2.mga9.x86_64.rpm
> virtualbox-kernel-6.4.16-desktop-3.mga9-7.0.12-35.mga9.x86_64.rpm
> virtualbox-kernel-6.4.16-server-3.mga9-7.0.12-35.mga9.x86_64.rpm
> virtualbox-kernel-desktop-latest-7.0.12-35.mga9.x86_64.rpm
> virtualbox-kernel-server-latest-7.0.12-35.mga9.x86_64.rpm
> 
> Please correct me if I misunderstood

The list is correct.

(In reply to Giuseppe Ghibò from comment #10)
> If you have kmod installed from packages you might uninstall dkms-virtualbox
> installed. Probably you got it installed because you tried on 6.5.x series.
> 
That install originated as a Cauldron install many months ago.(January? February? I don't know.) As I recall, I installed dkms-virtualbox when the kmods weren't included until a couple of days after a kernel update. I don't remember the circumstances now, but they probably had something to do with Cauldron being Cauldron.

> For the bad signature on ISO Guest Additions online downloading, I got the
> same problems too (but IIRC it was also happening on previous releases such
> as 7.0.10). Sometimes it downloads but then the progress bar no longer
> completes even if the file is completely downloaded. I bypassed downloading
> the tools by hand from:
> 
> https://download.virtualbox.org/virtualbox/7.0.12/VBoxGuestAdditions_7.0.12.
> iso
> 
> and then inserting the ISO as a plain CD/DVD. Apparently is reported
> upstream here https://www.virtualbox.org/ticket/21883.
> 
That is what I did. my url was for the same site, but for the list of available packages. If I use "update guest additions," the file downloads but the install fails with an cryptic error. It was when I tried to use the iso that I downloaded manually that I got the bad signature message. I did the download twice, in the unlikely chance of a bad download the first time.

 Yes, it has happened before. The last one was even worse. The additions would install, but once they did Windows wouldn't start except in safe mode. It was definitely an upstream problem last time.

(In reply to Thomas Andrews from comment #12)
> (In reply to Giuseppe Ghibò from comment #10)
> > If you have kmod installed from packages you might uninstall dkms-virtualbox
> > installed. Probably you got it installed because you tried on 6.5.x series.
> > 
> That install originated as a Cauldron install many months ago.(January?
> February? I don't know.) As I recall, I installed dkms-virtualbox when the
> kmods weren't included until a couple of days after a kernel update. I don't
> remember the circumstances now, but they probably had something to do with
> Cauldron being Cauldron.
> 
> > For the bad signature on ISO Guest Additions online downloading, I got the
> > same problems too (but IIRC it was also happening on previous releases such
> > as 7.0.10). Sometimes it downloads but then the progress bar no longer
> > completes even if the file is completely downloaded. I bypassed downloading
> > the tools by hand from:
> > 
> > https://download.virtualbox.org/virtualbox/7.0.12/VBoxGuestAdditions_7.0.12.
> > iso
> > 
> > and then inserting the ISO as a plain CD/DVD. Apparently is reported
> > upstream here https://www.virtualbox.org/ticket/21883.
> > 
> That is what I did. my url was for the same site, but for the list of
> available packages. If I use "update guest additions," the file downloads
> but the install fails with an cryptic error. It was when I tried to use the
> iso that I downloaded manually that I got the bad signature message. I did
> the download twice, in the unlikely chance of a bad download the first time.
> 
>  Yes, it has happened before. The last one was even worse. The additions
> would install, but once they did Windows wouldn't start except in safe mode.
> It was definitely an upstream problem last time.

Note that I did Devices/Choose a disk file or disk image, not the Devices/Insert Guest Additions|Update Guest Additions, pointing to the ISO downloaded from the URL above (with wget or curl). I haven't understand where the signature is taken from, as I see only MD5SUMS and SHA256SUMS in the same place i.e. https://download.virtualbox.org/virtualbox/7.0.12/SHA256SUMS or https://download.virtualbox.org/virtualbox/7.0.12/MD5SUMS, and since the beginning, i.e. even on the aborted attempts the residual of the downloaded ISO in the virtualbox dirs was always with the correct checksum when tested externally against MD5SUMS or SHA256SUMS.

Under Win you have to insists a couple of times (with snapshots), because the first attempts it tries to install but then hangs, but next attempts works.

Problem updating guest additions using upstream
(running on kernel 6.4.16-desktop-5)

In MSWindows guest (This use to work):

I launch my MSwindows 7 guest, and if Virtualbox have been updated, it soon asks to update it. I use the guest window's frame menu item "Devices" and let it download and install guest additions.

It use to work, but today the install step fail with the message:

----8<---

Name: /home/morgan/.config/VirtualBox/VBoxGuestAdditions_7.0.12.iso

Running update file on guest failed: Error VERR_LDR_IMAGE_HASH for guest process "C:\Program Files\Oracle\VirtualBox Guest Additions\Update\VBoxCertUtil.exe" occurred
.
Result Code:
VBOX_E_IPRT_ERROR (0X80BB0005)
Component:
GuestSessionWrap
Interface:
IGuestSession {234f0627-866d-48c2-91a5-4c9d50f04928}

--->8---

Trying same file manually: 

$ sudo VBoxManage extpack install --replace VBoxGuestAdditions_7.0.12.iso 
VBoxManage: error: RTZipGzipDecompressIoStream failed: VERR_ZIP_BAD_HEADER
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackFileWrap, interface IExtPackFile, callee nsISupports
VBoxManage: error: Context: "Install(fReplace, __null, ptrProgress.asOutParam())" at line 1908 of file VBoxManageMisc.cpp

And same result with directly downloaded file by

wget https://download.virtualbox.org/virtualbox/7.0.12/VBoxGuestAdditions_7.0.12.iso

So it was not a bad download.

So what is it then...?

CC: (none) => fri

(In reply to Morgan Leijström from comment #14)
> Problem updating guest additions using upstream
> (running on kernel 6.4.16-desktop-5)
> 
> In MSWindows guest (This use to work):
> 
> I launch my MSwindows 7 guest, and if Virtualbox have been updated, it soon
> asks to update it. I use the guest window's frame menu item "Devices" and
> let it download and install guest additions.
> 
> It use to work, but today the install step fail with the message:
> 
> ----8<---
> 
> Name: /home/morgan/.config/VirtualBox/VBoxGuestAdditions_7.0.12.iso
> 
> Running update file on guest failed: Error VERR_LDR_IMAGE_HASH for guest
> process "C:\Program Files\Oracle\VirtualBox Guest
> Additions\Update\VBoxCertUtil.exe" occurred
> .
> Result Code:
> VBOX_E_IPRT_ERROR (0X80BB0005)
> Component:
> GuestSessionWrap
> Interface:
> IGuestSession {234f0627-866d-48c2-91a5-4c9d50f04928}
> 
> --->8---
> 
> Trying same file manually: 
> 
> $ sudo VBoxManage extpack install --replace VBoxGuestAdditions_7.0.12.iso 
> VBoxManage: error: RTZipGzipDecompressIoStream failed: VERR_ZIP_BAD_HEADER
> VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component
> ExtPackFileWrap, interface IExtPackFile, callee nsISupports
> VBoxManage: error: Context: "Install(fReplace, __null,
> ptrProgress.asOutParam())" at line 1908 of file VBoxManageMisc.cpp
> 
> And same result with directly downloaded file by
> 
> wget
> https://download.virtualbox.org/virtualbox/7.0.12/VBoxGuestAdditions_7.0.12.
> iso
> 
> So it was not a bad download.
> 
> So what is it then...?

Apparently seems an upstream prob.

To check it is downloaded correctly, download the checksum from:

wget https://download.virtualbox.org/virtualbox/7.0.12/SHA256SUMS

sha256sum -c SHA256SUMS

in the same dir where you have have downloaded the Guest Additions ISO. Also don't install pushing as Guest Additions from menu, but insert the ISO from menu Devices/Choose a disk file or image. And then in Win7 go to the file manager and open the plain CD/DVD device and the run the vbox 64bit guest addition installation (do a quick snapshot to preserve the Win working config).

(In reply to Giuseppe Ghibò from comment #15)

> > Name: /home/morgan/.config/VirtualBox/VBoxGuestAdditions_7.0.12.iso

also it seems doesn't like installing the ISO from $HOME/.config/VirtualBox/..., dunno why, probably keepen locked by some previous attempt.

rebooted
downloaded the file in my regular downloads folder
checksummed it OK
Still same problem:

$ sudo VBoxManage extpack install --replace VBoxGuestAdditions_7.0.12.iso
VBoxManage: error: RTZipGzipDecompressIoStream failed: VERR_ZIP_BAD_HEADER
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackFileWrap, interface IExtPackFile, callee nsISupports
VBoxManage: error: Context: "Install(fReplace, __null, ptrProgress.asOutParam())" at line 1908 of file VBoxManageMisc.cpp

Then i did as you told, put the .iso file in the virtual drive and opened it in file manager:
Doublelicking VBoxWindowsAdditions.exe prompts a warning dialogue that the source is not verified, i click OK but nothing happens.
The solution is to directly click VBoxWindowsAdditions-amd64.exe (-x86 if you have 32 bit)

Then it runs, seem to operate correctly.

BUT after reboot it is still old version 7.0.10, the tray icon say :(

Weird problem.
I have to leave this for another day.

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

> rebooted
> downloaded the file in my regular downloads folder
> checksummed it OK
> Still same problem:
> 
> $ sudo VBoxManage extpack install --replace VBoxGuestAdditions_7.0.12.iso
> VBoxManage: error: RTZipGzipDecompressIoStream failed: VERR_ZIP_BAD_HEADER
> VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component
> ExtPackFileWrap, interface IExtPackFile, callee nsISupports
> VBoxManage: error: Context: "Install(fReplace, __null,
> ptrProgress.asOutParam())" at line 1908 of file VBoxManageMisc.cpp
> 
> Then i did as you told, put the .iso file in the virtual drive and opened it
> in file manager:
> Doublelicking VBoxWindowsAdditions.exe prompts a warning dialogue that the
> source is not verified, i click OK but nothing happens.
> The solution is to directly click VBoxWindowsAdditions-amd64.exe (-x86 if
> you have 32 bit)
> 
> Then it runs, seem to operate correctly.
> 
> BUT after reboot it is still old version 7.0.10, the tray icon say :(

yes, it needs to be issued/reinstalled several times under Win, but in the end you get 7.0.12...

(In reply to Giuseppe Ghibò from comment #18)
> (In reply to Morgan Leijström from comment #17)
> yes, it needs to be issued/reinstalled several times under Win, but in the
> end you get 7.0.12...

Tried three more times now, from inside Windows, no change.

And always since first try, at shutdown a dialogue in traditional Microsoft style

_____ Windows - Bad image _____
Processing Message 0x000007b Parameters
0x000007FEFD19C 0x000007FEFD19C
0x000007FEFD19C 0x000007FEFD19C

Googling that it seems to normally display at startup, come from bad/interrupted update, mix 32/64 bit, invalid file path, system file corruption...  

I guess say it is a bug in the windows method in that it proceed and produce bad results , and VBoxManage probably fail for a valid reason.

Leaving it for now.

* REVERTING TO USABLE STATE *

According to the thread https://forums.virtualbox.org/viewtopic.php?p=542189#p542189, installing 7.0.10 works, and yes I see no more that "Bad image" warning, and guest seem to work OK.

How: Put VBoxGuestAdditions_7.0.12.iso in the virtual optical drive and open it in file manager, doubleclick VBoxWindowsAdditions.exe and it works.

I the thread they say also 7.0.11 and 7.0.13 additions have the same problem.
They seem to have found no issues with using 7.0.10 guest additions with 7.0.12 host.

As this upstream bug affects Windows 7, 8, 8,1 guests, I think we should not release this... possibly in backport... until it is fixed.

Removing advisory flag because either we shall have a fixed version, or advisory should mention the bug and remedy.

Keywords: advisory => (none)

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

OOPS I meant of course 7.0.*10* in
> Put VBoxGuestAdditions_7.0.12.iso in the virtual optical drive

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

> VBoxManage extpack install --replace VBoxGuestAdditions_7.0.12.iso

Doh, that command is for server side extension, so dont work of course

Now off to take some rest...

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

> * REVERTING TO USABLE STATE *
> 
> According to the thread
> https://forums.virtualbox.org/viewtopic.php?p=542189#p542189, installing
> 7.0.10 works, and yes I see no more that "Bad image" warning, and guest seem
> to work OK.
> 
> How: Put VBoxGuestAdditions_7.0.12.iso in the virtual optical drive and open
> it in file manager, doubleclick VBoxWindowsAdditions.exe and it works.
> 
> I the thread they say also 7.0.11 and 7.0.13 additions have the same problem.
> They seem to have found no issues with using 7.0.10 guest additions with
> 7.0.12 host.

7.0.11 and 7.0.13 are probably internal beta version, as I don't see them in 

https://download.virtualbox.org/virtualbox/

> 
> As this upstream bug affects Windows 7, 8, 8,1 guests, I think we should not
> release this... possibly in backport... until it is fixed.

We might just postpone virtualbox 7.0.12 update, without need of moving to backports.

So the new plan could be to swap the release order of kernel and virtualbox, and
release kernel-6.4.16-5.mga9 BEFORE virtualbox-7.0.12-2.mga9 (or newer, if any); for this we need to build a newer kmod-virtualbox-7.0.10-36.mga9 providing virtualbox-kernel-6.4.16-desktop-5.mga9-7.0.10-36.mga9; for this purpose we need to ask sysadms to remove kmod-virtualbox-7.0.12-35.mga9 from updates_testing.

@ Sysadmins, please remove kmod-virtualbox-7.0.12-35.mga9 from updates_testing.

Per Comment 23.

We postpone the virtualbox 7.0.12 update, keeping it in updates_testing for now.

CC: (none) => sysadmin-bugs

The lack of the advisory keyword will not stop the script that pushes updates from pushing a validated update.  Removing the keyword just hides the fact that one has already been committed and may result in a validated update getting pushed prematurely.  Be careful not to validate this until the SVN advisory has been updated.

Keywords: (none) => advisory

The last time something like this happened was with vbox 7.0.8. See Bug 31882. The "fix" then was to either continue to use 7.0.6 guest additions, or download "experimental" ones from https://www.virtualbox.org/wiki/Testbuilds 

Our fix was to wait for vbox 7.0.10, which did work.

(In reply to David Walser from comment #25)
> The lack of the advisory keyword will not stop the script that pushes
> updates from pushing a validated update.  Removing the keyword just hides
> the fact that one has already been committed and may result in a validated
> update getting pushed prematurely.  Be careful not to validate this until
> the SVN advisory has been updated.

Thanks for telling that.

Removing the advisory keyword was done, so that I would know that it would need to be updated. I've now deleted 32490.adv from SVN, so that nothing can go wrong.

Keywords: advisory => (none)

MGA9-64, Gnome, VirtualBox

Installed and running VM without issue.

CC: (none) => brtians1

MGA9 64 GNOME Mac Mini Core I5 16Go RAM

After repairing virtual box with the help of comment 32 of bug report #32482

I updated VB with QA repo and RPM:

virtualbox                     7.0.12       2.mga9        x86_64  
virtualbox-guest-additions     7.0.12       2.mga9        x86_64 

VB with MGA works as expected

CC: (none) => guillaume.royer

Hm. After the adventure ending with the revert in comment 20, guest MSWindows7 at lower right corner display:

 Test Mode
 Windows 7
 Build 7601

I guess it somehow lost registration :(
No need to comment, I will do a web search. Just noting.

Regarding the Windows 7 guest additions problem, it has been discussed in depth at https://forums.virtualbox.org/viewtopic.php?t=110346 and the developers believe they have found the problem and it should be corrected for the 7.0.14 release.

In the meantime, we are advised to download guest additions 7.0.13r160164 (or newer) from https://www.virtualbox.org/wiki/Testbuilds and use that. 

I just downloaded 7.0.13r160458 from that page and installed it into my Windows 7 guest without issues. (This was with Vbox 7.0.12 where modules had been built locally for kernel 6.5.11-5 using dkms)

Thank you TJ

I now updated to 7.0.12, downloaded BoxGuestAdditions_7.0.13-160458.iso, let the windows 7 guest install it, reboot, and I performed my usual tests OK:

internet videos, dynamic guest window resizing, USB2 flashstick, host folder sharing, bidirectional clipboard, and drag file from Dolphin to Explorer (worked on second attempt, quirky as usual)

With latest testing updates, i.e:
kernel-linus-6.5.11-2 on i7-870, nvidia470.223.02 on GTX750Ti, Plasma, VB module built by dkms at boot for this kernel.

---

I think we can ship this for people who want 7.0.12.
But how to warn/tell users who run MSWindows guests?
Blog note and forum?
Alternatively hide it in backports while waiting for 7.0.14 ?

Status comment: (none) => Elder MSWindows need 7.0.13 guest additions, see Comment 13
Whiteboard: (none) => MGA9-64-OK

Removing the OK, because now that the 6.5.11-5 kernel has been pushed, this update will need the kmods for it added to the packages, and they will need to be tested.

Whiteboard: MGA9-64-OK => (none)

Thanks, I forgot about pre-built kmods!

(In reply to Thomas Andrews from comment #33)
> Removing the OK, because now that the 6.5.11-5 kernel has been pushed, this
> update will need the kmods for it added to the packages, and they will need
> to be tested.

Joeghi is already in the CC. Setting "feedback"

Keywords: (none) => feedback

kmod prebuilts *virtualbox-kernel-*7.0.12-38.mga9.x86_64.rpm in the build.

We might issue virtualbox 7.0.12 now, pointing also docs to URL for temporarely vboxadditions ISO 7.0.13, then update to 7.0.14 later.

MGA9-64 Plasma, HP Pavilion 15. VirtualBox had not yet been updated on this system, and dkms-virtualbox is not installed.

I used the list from comment 6 in qarepo with the "fuzzy version" option enabled. This downloaded the proper kmods. No installation issues for the updates.

VirtualBox ran without issues. I ran my Windows 7 guest, and installed the 7.0.13 guest additions that I downloaded as described in comment 31. No issues there, either. Then I ran a Mageia guest, and went after the updates that were waiting, also without issues. I did not install the Mageia 9 guest additions for vbox 7.0.12, but I had already checked them in comment 9.

Removing the feedback flag, giving this an OK, and validating. 

BTW, qarepo's fuzzy version option also picked up some old kmod builds for vbox 7.0.10 and two test kernels that were never pushed. That makes me think that perhaps the testing repos probably need some housekeeping...

Whiteboard: (none) => MGA9-64-OK

Advisory added to SVN, with SRPMs:

 virtualbox-7.0.12-2.mga9
 kmod-virtualbox-7.0.12-38.mga9

Please remove the 'advisory' keyword if that isn't correct.

Keywords: (none) => advisory

Prebuilt kmod OK in same system as tested earlier in this thread with dkms built kmod, same tests.

kernel 6.5.11-desktop-5.mga9

---

I have not checked before, but note in journal during boot, the three instances of "Only network interfaces can be renamed" :

[morgan@svarten ~]$ journalctl -b|grep virtualb
nov 30 14:43:33 svarten.tribun dkms-autorebuild.sh[1072]: virtualbox (7.0.12-2.mga9): Already installed on this kernel.
nov 30 14:43:35 svarten.tribun (udev-worker)[7883]: vboxdrvu: /usr/lib/udev/rules.d/virtualbox.rules:2 Only network interfaces can be renamed, ignoring NAME="vboxdrvu".
nov 30 14:43:35 svarten.tribun (udev-worker)[8237]: vboxdrv: /usr/lib/udev/rules.d/virtualbox.rules:1 Only network interfaces can be renamed, ignoring NAME="vboxdrv".
nov 30 14:43:35 svarten.tribun (udev-worker)[8238]: vboxnetctl: /usr/lib/udev/rules.d/virtualbox.rules:3 Only network interfaces can be renamed, ignoring NAME="vboxnetctl".

As vbox works nicely, maybe udev tries to do something funny?

No reason to hold this back as i see it.

(In reply to Thomas Andrews from comment #37)

> BTW, qarepo's fuzzy version option also picked up some old kmod builds for
> vbox 7.0.10 and two test kernels that were never pushed. That makes me think
> that perhaps the testing repos probably need some housekeeping...

These files should be removed from core/updates_testing:

virtualbox-kernel-6.4.16-desktop-1.mga9-7.0.10-32.mga9.x86_64.rpm
virtualbox-kernel-6.4.16-desktop-5.mga9-7.0.10-36.mga9.x86_64.rpm
virtualbox-kernel-6.4.16-server-1.mga9-7.0.10-32.mga9.x86_64.rpm
virtualbox-kernel-6.4.16-server-5.mga9-7.0.10-36.mga9.x86_64.rpm

IMHO we should add some trivial mechanism to allow easy cleanup of older packages in updates_testing without need of calling "firemens" every time, that maybe are busy. Pratical suggestions might go into the umbrella of https://bugs.mageia.org/show_bug.cgi?id=32329

Actually removing validation until more discussed and decided

Shipping this as update will temporarily disrupt some users work.

I vote for either keeping it here (most simple) or putting it in backport.

- And in either case post in forum abut this upstream problem, and that users who want 7.0.12 can fetch it from testing (or backport) and them who use old windows guests can fetch that .13 guest addition.

Keywords: validated_update => (none)

(we already disrupted some users by letting kernel 6.5 out before nvidia470 update... Not another one please.)

Forum post: https://forums.mageia.org/en/viewtopic.php?f=7&t=15160

Also, Bug 32587 has been created using much of the same txt, to remain open until VirtualBox 7.0.14 has been confirmed to fix the Windows guest additions issue, and is pushed to Mageia 9.

If the subject comes up on the discuss ML, we can direct users to one of those two places.

We can give those messages a chance to settle in, and validate again in a day or two.

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=32587

Well formulated TJ :)

IMO we can restore the advisory keyword in 24 hours, so this ships out 24 to 48 hrs from now.

@Marja: Maybe add something about the known problem to the advisory, with link to Bug 32587 - VirtualBox 7.0.12 and Windows guest additions https://bugs.mageia.org/show_bug.cgi?id=32587

Roll out

Keywords: (none) => validated_update

(In reply to Morgan Leijström from comment #45)
> @Marja: Maybe add something about the known problem to the advisory, with
> link to Bug 32587 - VirtualBox 7.0.12 and Windows guest additions
> https://bugs.mageia.org/show_bug.cgi?id=32587

I've added:

WARNING
  VirtualBox 7.0.12 and Windows guest additions between (not incl)
  7.0.10 & 7.0.13r160164 are problematic for Windows guests less than
  Win10 https://bugs.mageia.org/show_bug.cgi?id=32587

Good :)

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

https://advisories.mageia.org/MGASA-2023-0335.html

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