This is being discussed in dev mail list

Same for mga9 kernel in backport testing

I do not set flag MGA9TOO because we only have 6.12 in testing.

Assignee: bugsquad => kernel
CC: (none) => fri

Any update here ?  I haven't seen anything about this in dev.  I assume that the problem is that something else requires VMX root mode, otherwise why not just rebuild the kernels without it ?

In mail correspondence with Giuseppe, he suggested the workaround:

$ sudo rmmod kvm_intel
$ sudo rmmod kvm

And after that VirtualBox (7.1.10) runs fine on mga9 backport_testing kernel 6.12.37-desktop-1.stable

So he is on it..

Same workaround for 6.12.39-desktop-1.stable.mga9 as in Comment 3

I confirm that the workaround works on cauldon.

Ditto for kernel-stable-desktop-6.12.41-1.stable.mga9-1-1.mga9

This is also an upstream bug:

https://www.virtualbox.org/ticket/22248

A further fix could be to provide a file in:

/etc/modprobe.d/virtualbox-blacklist-kvm.conf

with

blacklist kvm-intel
blacklist kvm-amd
blacklist kvm

CC: (none) => ghibomgx

Still valid for kernel-stable-desktop-6.12.43-1.stable.mga9

A fix/workaround is in virtualbox 7.1.12-X in cauldron.

There will be a 7.1.12/14 for mga9. This will be the latest, as Virtualbox 7.2.0 would require qt6.8 for the UI, and we have only 6.4.1 in mga9.

In the upstream bug they also suggest an alternative workaround:
  add kvm.enable_virt_at_load=0 to kernel command line. 

...

I see VB 7.1.14 in mga9 testing.  Ready for QA?

BTW if it have increased CPU requirements compared to our released version, maybe it should go as packport?

(In reply to Morgan Leijström from comment #10)
> In the upstream bug they also suggest an alternative workaround:
>   add kvm.enable_virt_at_load=0 to kernel command line. 
> 
> ...
> 
> I see VB 7.1.14 in mga9 testing.  Ready for QA?
> 
> BTW if it have increased CPU requirements compared to our released version,
> maybe it should go as packport?

The package is ready, but hadn't had time for creating a new bug report (changelog https://www.virtualbox.org/wiki/Changelog-7.1) and the files list.

AFAIK the CPU requirement is not changed. What is changed in the CPU requirements is for virtualbox-kvm, for which there isn't yet any backport for mga9, but there is in cauldron, which requires at least CPU Sandybridge or Bulldozer. So it's another package.

I think we can use this bug report, instead of a new one for 7.1.14-1.mga9.

Source RPM: kernel => kernel, kmod-virtualbox

OK yes, go ahead and use this bug for VB 7.1.14 in mga9.

I noticed new 6.6.116 kernel in mga9 testing, and I am using it now.

I suggest to ship that kernel first, setting this this bug to depend on that, to not waste energy on checking with pre 6.6.116 kernel.

We need an advisory proposal and files list.

Version: Cauldron => 9
Depends on: (none) => 34713

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

> OK yes, go ahead and use this bug for VB 7.1.14 in mga9.
> 
> I noticed new 6.6.116 kernel in mga9 testing, and I am using it now.
> 
> I suggest to ship that kernel first, setting this this bug to depend on
> that, to not waste energy on checking with pre 6.6.116 kernel.
> 
> We need an advisory proposal and files list.

I was suggesting to start with VB 7.1.14 first, only because was older, and thought testing could be faster. The only problem is to avoid overlapping with kmod-virtualbox, because otherwise we need to produce a kmod-virtualbox for 7.1.10 first for kernel-6.6.116, instead of kmod-virtualbox 7.1.14 for kernel-6.6.105.

Yes... I think you are right, we should have binary VB 7.1.14 kmods for 6.6.105

Problem: Fail updating VBoxGuestAdditions:
 fail asking, and fail finding the automatically downloaded iso.


Updated host to:
virtualbox-7.1.14-1.mga9.x86_64
virtualbox-kernel-server-latest-7.1.14-11.mga9.x86_64
virtualbox-kernel-6.6.105-server-1.mga9-7.1.14-11.mga9.x86_64
dkms-virtualbox-7.1.14-1.mga9.x86_64


Running on kernel-desktop-6.6.105-1.mga9, using dkms built kmod.

Booted MSW 7 64 bit guest:

In difference from earlier updates, it did not prompt for updating guest additions.

And when I told it to, it first asked if it should fetch from internet:
https://download.virtualbox.org/virtualbox/7.1.14/VBoxGuestAdditions_7.1.14.iso (61 343 744 byte)
 i said yes and then the error was 
VBoxGuestAdditions, during network request: the URL was not found on server.  (translated by me from Swedish)

But in gkrellm I noticed a bunch of data get downloaded before it was "not found", and in guest Firefox can surf internet.

Something is broken here, and I pause further testing until solved.

Does it work for other testers?
Seem to be two problems
1) user should not need to initiate - it should prompt user like before to update to correct version
2) whatever happened to what it downloaded?

Probably I can download the iso per the URL above and let guest run that, but it should work automatically.

But the previous 7.1.10 version was working or was the same for the downloading? Maybe the downloading servers were just slow or down.

Yes in the previous (two?) updates this have worked flawlessly on my system.
Current actually do download the file, I see same amount getting downloaded like i see when i download the file manually.  Several tries different day.
I see now it have downloaded VBoxGuestAdditions_7.1.14.iso.tmp
to ~/.config/VirtualBox/ sucessfully!
So the error message is misleading - it seemt to *think* it failed and therefore abort?

We have seen similar but different, various problems with earlier versions.
See for example Bug 18962
Now aired by mail list https://ml.mageia.org/l/arc/qa-discuss/2025-11/msg00014.html, and i remember we also have noted in some bug reports here.

This issue seem to come and go in various variants...

  -lets go ahead QA this update!

Please provide a files list, then assign to QA.
And post an advisory proposal.
I might add about the problem to https://wiki.mageia.org/en/VirtualBox#On_guests

Keywords: feedback => (none)

Created attachment 15154 [details]
files list

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

> We have seen similar but different, various problems with earlier versions.
> See for example Bug 18962
> Now aired by mail list
> https://ml.mageia.org/l/arc/qa-discuss/2025-11/msg00014.html, and i remember
> we also have noted in some bug reports here.
> 
> This issue seem to come and go in various variants...

An explanation could be this, as I've observed recently this on many sites for some time, alongside DNS resolution problems: with the increasing volume of scraper bot traffic, many sites now implement a delay or use JS scripts before allowing downloads or connections. This can cause failures when using a simple C library function for downloading over HTTP/HTTPS, because it doesn't expect "unstable" connections. When you manually download the file with a dedicated downloader it might work better, as these tools are designed to retry downloads with longer timeouts and with more "unstable" connections.

A closer look at guest additions VirtualBox have downloaded:

$ ls -l ~/.config/VirtualBox/ | grep Addit
-rw------- 1 morgan kamo 53526528 mar 25  2024 VBoxGuestAdditions_7.0.14.iso
-rw------- 1 morgan kamo 52887552 jun 15  2024 VBoxGuestAdditions_7.0.18.iso
-rw------- 1 morgan kamo 53504000 dec 21  2024 VBoxGuestAdditions_7.0.20.iso
-rw------- 1 morgan kamo 54300672 dec 28  2024 VBoxGuestAdditions_7.0.22.iso
-rw------- 1 morgan kamo 54804480 jan 24  2025 VBoxGuestAdditions_7.0.24.iso
-rw------- 1 morgan kamo 61378560 jun 25 23:43 VBoxGuestAdditions_7.1.10.iso
-rw------- 1 morgan kamo 61343744 nov  6 10:39 VBoxGuestAdditions_7.1.14.iso.tmp
-rw------- 1 morgan kamo 61380608 apr 22  2025 VBoxGuestAdditions_7.1.8.iso

All *.iso have it succeeded downloading previously.
So this version downloads the file with ".tmp" as suffix and i suppose it mean to remove that when finished downloading.

But instead it gives up *after* the download.
Do it use some downloading mechanism in our distro that is not fully compatible in means of status reporting?

The file is fully OK, i checked according to https://download.virtualbox.org/virtualbox/7.1.14/MD5SUMS

Also, Firefox downloads it without problems, as do
 wget https://download.virtualbox.org/virtualbox/7.1.14/VBoxGuestAdditions_7.1.14.iso

The thing is that VirtualBox always do succeed in downloading the file, but think it failed.  Additionally it gives wrong message - saying URL was not found on server - despite that the same dialogue (right top in guest window) the seconds before showed an alive progress bar indicating the progress of downloading the "non existing" file...

If it's that downloading the iso wasn't "finished" by Vbox, that would seem to be an upstream problem with their downloader, something for them to fix. 

I wonder if one tried downloading the file, then closed the guest when it failed and renamed the downloaded file to remove the '.tmp', if the guest would then find the file and use it properly if you 'inserted guest additions' again.

I see the files list was uploaded, but the bug wasn't assigned to QA. Is there a  reason for that, or was it just missed?

CC: (none) => andrewsfarm

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

> A closer look at guest additions VirtualBox have downloaded:
> 
> $ ls -l ~/.config/VirtualBox/ | grep Addit
> -rw------- 1 morgan kamo 53526528 mar 25  2024 VBoxGuestAdditions_7.0.14.iso
> -rw------- 1 morgan kamo 52887552 jun 15  2024 VBoxGuestAdditions_7.0.18.iso
> -rw------- 1 morgan kamo 53504000 dec 21  2024 VBoxGuestAdditions_7.0.20.iso
> -rw------- 1 morgan kamo 54300672 dec 28  2024 VBoxGuestAdditions_7.0.22.iso
> -rw------- 1 morgan kamo 54804480 jan 24  2025 VBoxGuestAdditions_7.0.24.iso
> -rw------- 1 morgan kamo 61378560 jun 25 23:43 VBoxGuestAdditions_7.1.10.iso
> -rw------- 1 morgan kamo 61343744 nov  6 10:39
> VBoxGuestAdditions_7.1.14.iso.tmp
> -rw------- 1 morgan kamo 61380608 apr 22  2025 VBoxGuestAdditions_7.1.8.iso
> 
> All *.iso have it succeeded downloading previously.
> So this version downloads the file with ".tmp" as suffix and i suppose it
> mean to remove that when finished downloading.
> 
> But instead it gives up *after* the download.
> Do it use some downloading mechanism in our distro that is not fully
> compatible in means of status reporting?
> 
> The file is fully OK, i checked according to
> https://download.virtualbox.org/virtualbox/7.1.14/MD5SUMS
> 
> Also, Firefox downloads it without problems, as do
>  wget
> https://download.virtualbox.org/virtualbox/7.1.14/VBoxGuestAdditions_7.1.14.
> iso
> 
> The thing is that VirtualBox always do succeed in downloading the file, but
> think it failed.  Additionally it gives wrong message - saying URL was not
> found on server - despite that the same dialogue (right top in guest window)
> the seconds before showed an alive progress bar indicating the progress of
> downloading the "non existing" file...

Probably it is another bug already present in 7.1.10. What is weird is that it seems downloads correctly correct checksum but sometimes doesn't complete the last stage of validation.

For the above and related quirks, I entered https://github.com/VirtualBox/virtualbox/issues/372
And while working on it I also discovered localisation problem https://github.com/VirtualBox/virtualbox/issues/371

Well... recap and progressing on Mageia QA for VB 7.1.14 :

Updated host to:
virtualbox-7.1.14-1.mga9.x86_64
virtualbox-kernel-server-latest-7.1.14-11.mga9.x86_64
virtualbox-kernel-6.6.105-server-1.mga9-7.1.14-11.mga9.x86_64
dkms-virtualbox-7.1.14-1.mga9.x86_64

I rebooted host.

* Running on kernel-desktop-6.6.105-1.mga9, using dkms built kernel module *
(Other flavours & binary kmod I report later below)

Booted MSW 7 64 bit guest:
As mentioned in previous comments it this time do not detect it needed new guest addition. After some tries described in https://github.com/VirtualBox/virtualbox/issues/372 it got updated and I rebooted the guest. By that time Windows had already downloaded new antivirus definitions which it installed during reboot.
 All OK: 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.


Host:
[morgan@svarten ~]$ inxi -SMCG
System:
  Host: svarten.tribun Kernel: 6.6.105-desktop-1.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: 1273 min/max: 1200/2934 cores: 1: 1273 2: 1273 3: 1273
    4: 1273 5: 1273 6: 1273 7: 1273 8: 1273
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 compat-v: 4.5 vendor: amd mesa v: 25.0.7 renderer: AMD
    Radeon RX 6400 (radeonsi navi24 LLVM 15.0.6 DRM 3.54

Attached file list is missing virtualbox-7.1.14-1.mga9.x86_64.rpm .

I had not realized the above (most important) package was missing when I first updated using QArepo. Everything there updated OK. When I ran my Win7 Professional guest it didn't detect that that new guest additions were needed, and that was when I checked the running vbox version, finding it was still using 7.1.10. 

I closed vbox, installed the missing package with the help of QArepo, and ran it again. This time, I was notified that my guest additions were out of date. I tried using the gui, and got this message about the download:

Name: VBoxGuestAdditions
During network request: Url not found on the server

But, the file had been downloaded, with the .tmp on the end. I tried renaming the file with .tmp removed, but Win7 still didn't see it as a valid iso.

Created attachment 15158 [details]
files list

Attachment 15154 is obsolete: 0 => 1

(In reply to Thomas Andrews from comment #27)

> I had not realized the above (most important) package was missing when I
> first updated using QArepo. Everything there updated OK. When I ran my Win7
> Professional guest it didn't detect that that new guest additions were
> needed, and that was when I checked the running vbox version, finding it was
> still using 7.1.10. 
> 
> I closed vbox, installed the missing package with the help of QArepo, and
> ran it again. This time, I was notified that my guest additions were out of
> date. I tried using the gui, and got this message about the download:
> 
> Name: VBoxGuestAdditions
> During network request: Url not found on the server
> 
> But, the file had been downloaded, with the .tmp on the end. I tried
> renaming the file with .tmp removed, but Win7 still didn't see it as a valid
> iso.

Which seems the same behaviour as https://bugs.mageia.org/show_bug.cgi?id=34408#c21. Did you get the same with previous 7.1.10?

I don't remember, but, because manually downloaded isos are stored in a different directory from those downloaded by Vbox, and a failed download has .tmp on the end, it looks like 7.1.10, 7.1.8, and 7.0.24 worked, 7.0.22 didn't, and others previous to those worked.

As Morgan said in comment 18, this, or something similar, has been happening off and on for a long time. When it does, I go to https://download.virtualbox.org/virtualbox/ , download the appropriate iso, and put it into the virtual optical drive. That always works.

BTW, My Win10 guest does the same thing.

Well, off to use the alternative method for Win10, as I may need a Windows guest sometime. I can leave my Win7 guest alone for the time being.

Ah yes our virtualbox-guest-additions rpm provides guest additions, and that package is good to be tested.

We have a choice of not installing it and instead separately fetch, in this case, https://download.virtualbox.org/virtualbox/7.1.14/VBoxGuestAdditions_7.1.14.iso and either mount and run it by the guest, tell virtualbox to have the guest run it, By th eGUI or by command line*), or optimally it should be automatically detected and proposed it need download and then automatically run it - that is what i wrote have been working for some versions now but not with 7.1.14.

*) Some time before, command line was the only working method for some systems: https://bugs.mageia.org/show_bug.cgi?id=18962#c48 

I dont know the procedure to have the guest use the guest additions from packaged virtualbox-guest-additions rpm?

I have lost track of what is different from the upstream provided version, but upstream traditionally includes some more support, other licence so it could not be freely distributed by distros.

It used to add more USB support but nowadays IIRC it is included in our packaged version. I have just continued using upstream by habit I suppose...

I have never used anything but our guest additions in Mageia guests. When I run a Mageia guest right after updating VirtualBox, I get a notice about the additions being old, and a warning that because I'm using distro-supplied additions I should update them from the distro.

The procedure is simply to install the Mageia rpm in the Mageia guest. If Mageia additions are already installed, they are updated like any other normal update. But, that is if no other additions are installed in the guest. I don't know what conflict there might be if one attempts to use BOTH.

Interesting: If I in drakrpm select virtualbox-guest-additions, it also wants to install - x11-driver-video-vboxvideo-1.0.0-9.mga9.x86_64 by dependency.

Is this some functionality that else is included in the upstream virtualbox-guest-additions, or if optimal for that too it should be a dep of virtualbox, or is it not really needed at all?

Different MGA9-64 Plasma host machine, different Win7 guest. This time I updated virtualbox and the kmods in one operation. I rebooted, and ran the guest, getting the notice that the additions were out of date. I waited until the antivirus did its thing and then tried to insert guest additions from the gui. It appeared to download, but I got the error message at the end. I closed the guest and ran it again, and tried again with the same result. 

BTW, I did not get the old guest additions warning a second time.

I rarely use this guest this time of year, so I'll leave it alone with regard to guest additions until we decide what, if anything, we are going to do.

In the meantime, the Win10 guest manual guest additions update worked perfectly. I ran the guest briefly, tried a few things, and there were no other issues. In addition, the Win7 guests that were using the old additions continued to work, though I confess to not trying to do much with them.

I Request help for the advisory, thanks

MGA9-64, Plasma, AMD Ryzen 5 2600, GeForce GTX 1650 SUPER

The following 6 packages are going to be installed:

- dkms-virtualbox-7.1.14-1.mga9.x86_64
- perl-5.36.0-1.2.mga9.x86_64
- perl-base-5.36.0-1.2.mga9.x86_64
- perl-doc-5.36.0-1.2.mga9.noarch
- virtualbox-7.1.14-1.mga9.x86_64
- virtualbox-guest-additions-7.1.14-1.mga9.x86_64

1005KB of additional disk space will be used.

- rebooted


So new install of Virtualbox since rebuild of the OS on this box.

- able to load and run the VM
- created a new VM image of Manjaro that worked
- able to RDP into the VM.

Working from my perspective.


I don't do windows VM's on these boxes, so can't help there.

CC: (none) => brtians1

From comment 25, continued testing:
Same test procedure, same system, other kernel 6.6.105 flavours

OK all:
kernel-desktop and -server with binaly prebuilt kmod packages,
kernel-linus dkms built kmod

---

Another host system, our backport kernel 6.12.44, MSW XP 32 bit guest.
Quick test OK.
Most importantly, when VB starts it asks user for credentials to rmmod, so it performs the procedure like we else must do manually like comment 3, for 6.12 kernels: Good.
Regarding guest additions: identical problems, see comment 24.

---

We can ship this regardless of the guest additions installing problems, but optimally we should fine a reliable method and describe it in https://wiki.mageia.org/en/VirtualBox#On_guests 

---

I think this is ready to ship.

@Giuseppe:

(In reply to katnatek from comment #35)
> I Request help for the advisory, thanks

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

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

> 
> We can ship this regardless of the guest additions installing problems, but
> optimally we should fine a reliable method and describe it in
> https://wiki.mageia.org/en/VirtualBox#On_guests 
> 
I'll see if I can add my procedure for adding Windows guest additions when the gui doesn't work, if it's not there already.

Validating.

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

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

> @Giuseppe:
> 
> (In reply to katnatek from comment #35)
> > I Request help for the advisory, thanks

We can add that it fixes 2 problems:

1) since kernel 6.12.x the kvm modules is preloaded at boot, and thus it conflicts with vbox modules. This version has a fix that rmmod the kvm module before starting virtualbox VMs (there is also upstream bug https://www.virtualbox.org/ticket/22248).

2) changelog for 7.1.14, on top of page https://www.virtualbox.org/wiki/Changelog-7.1

Thank you

Keywords: (none) => advisory

(In reply to Giuseppe Ghibò from comment #40)
> 1) since kernel 6.12.x the kvm modules is preloaded at boot, and thus it
> conflicts with vbox modules. This version has a fix that rmmod the kvm
> module before starting virtualbox VMs (there is also upstream bug
> https://www.virtualbox.org/ticket/22248).

Maybe in that text also tell that there will be a popup for user to enter password for executing the rmmod.

(as I experienced on kernel 6.12.44 .mga9 in comment 37)

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

> For the above and related quirks, I entered
> https://github.com/VirtualBox/virtualbox/issues/372

There is a fix for this bug. So at this point I'll upload a 7.1.14-2.mga9 with this fix merged.

OK thanks Giuseppe.
So advisory need be updated.
And we need to test again but less thorough.

Whiteboard: MGA9-64-OK => (none)
Keywords: advisory, validated_update => (none)

Created attachment 15170 [details]
files list

Attachment 15158 is obsolete: 0 => 1

(In reply to Thomas Andrews from comment #34)
> Different MGA9-64 Plasma host machine, different Win7 guest. This time I
> updated virtualbox and the kmods in one operation. I rebooted, and ran the
> guest, getting the notice that the additions were out of date. I waited
> until the antivirus did its thing and then tried to insert guest additions
> from the gui. It appeared to download, but I got the error message at the
> end. I closed the guest and ran it again, and tried again with the same
> result. 
> 
> BTW, I did not get the old guest additions warning a second time.
> 
> I rarely use this guest this time of year, so I'll leave it alone with
> regard to guest additions until we decide what, if anything, we are going to
> do.
> 

Before getting the new updates, I went to my user's .config/VirtualBox directory and deleted the unfinished guest additions file that was still there. There were no installation issues for the updates.

Running my Win7 guest, I again did not see a popup that my additions were out of date. (I think you are only supposed to see this once, as a "feature.") I told Vbox to insert the guest additions. They were downloaded, this time successfully, and the installation proceeded normally, requiring a reboot to finish, as usual.

I went on to use Win7 a bit, running an old program with no known (to me) Linux equivalent, calculating the "best" times and days to go fishing during the month of our scheduled 2026 trip, according to the relative positions of the Sun, Moon, and our fishing spot. I'm doubtful about its accuracy, however, as it's telling me that week is a poor time to go fishing there. My theory is because that is the only time we have a chance to go, and the absolute *best* time to go fishing is whenever you can, then...

Anyway, the guest is working as well as Win7 ever works.

Thanks, that new variant of guest additions update problem we now avoided to ship :-)

Revisiting the "other host" system in Comment 37, MSWindows XP guest, it now downloads on user command from menu "Upgrade Guest Additions" (it still did not prompt user to update), and it finds the file after download, but say it is unable to automatically update on Windows2000 and XP guests.

Trying the menu item "Insert Guest Additions CD image...": no reaction at all.  Another quirk, it works on the other install, two paragraphs down here -  It is even so that that guest was cloned over previously and both hosts are mga9.  And there it works, so strange it can not perform download+installation in one go.

 
Back on my main system, it now do not complain, it install with progress bar quicklu getting to 81 % then bar vanishes.  Would have been nice some feedback like reaching 100%, or some message...

Now on that same host, I launch the XP guest and directly try menu item "Insert Guest Additions CD image...", and to my surprise it installed - apparently reusing the .iso it downloaded for the other guest, good.

Quirks at updating guest additions have a long tradition, including variations between installs:  Bug 18962 - VirtualBox GUI Manager fails to install extension pack (have workarounds).  I add now there a link to here.

---

I repeated my usual tests, on my workstation, desktop 6.6.105 kernel, and no problem.

Lets ship this now, so we can build kmods for kernel 6.6.116 and get that out soon too. (and a backport kernel 6.12 please)

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

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

https://advisories.mageia.org/MGAA-2025-0097.html

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

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

> Back on my main system, it now do not complain, it install with progress bar
> quicklu getting to 81 % then bar vanishes.  Would have been nice some
> feedback like reaching 100%, or some message...
> 

To prevent the progress bar from stalling at 81% and to provide a better reporting, I think this issue should be reported upstream.

As i have already mentioned it in the upstream bug i now followed it up in the same as a start.