Thank you for the report, and sorry for the angst.
Can we assume that your system is generally up-to-date?

Do you know whether, on your original system, Nouveau (in place of the nVidia driver) did not work?

Did you try just reverting to the nVidia driver (which one?) with, for example, MCC-Install Graphics Driver? Trying to do this by fiddling xorg.conf does not look right.

I wonder also whether kernel 5.12 (rather than 5.10) should be here; somebody else will comment on that.
Also, the version of VirtualBox 6.1.18 you cite does not look right: it has passed via 6.1.20 to now 6.1.22.
Test installing VB, I see a choice of:
 virtualbox-kernel-5.10.xx-desktop-2.mga8-6.1.22-1.8.mga8.x86_64
(xx=45 latest).

You will need to re-try this with the up-to-date packages. But first await feedback on what you have said so far.

To give us details of your system graphics, please post the O/P of:-
 $ inxi -Gxx

Source RPM: virtualbox-6.1.18 => virtualbox-6.1.22-1.mga8.src.rpm
Summary: Installing virtualbox breaks the display driver => Installing virtualbox breaks the nVidia display driver
CC: (none) => lewyssmith, ouaurelien
Status: NEW => NEEDINFO

Thanks for your response.

My system is fully up to date, according to mcc. 
It is a recent clean install of Mageia 8.

I don't think Nouveau works on my system: but either way, I would not want it to change drivers without me telling it to!

Sorry, I didn't try using mcc to change the driver back to nVidia!

mcc offers two versions of virtualbox:

virtualbox-6.1.18-2.mga8 wants to also install the following:

- kernel-desktop-5.12.12-2.mga8-1-1.mga8.x86_64
- virtualbox-kernel-5.10.30-desktop-1.mga8-6.1.18-24.mga8.x86_64
- virtualbox-kernel-5.12.12-desktop-2.mga8-6.1.22-2.10.mga8.x86_64
- virtualbox-kernel-desktop-latest-6.1.22-2.10.mga8.x86_64

virtualbox-6.1.22-1.mga8 wants to also install the following:

- kernel-desktop-5.12.12-2.mga8-1-1.mga8.x86_64
- virtualbox-kernel-5.10.41-desktop-1.mga8-6.1.22-1.5.mga8.x86_64
- virtualbox-kernel-5.12.12-desktop-2.mga8-6.1.22-2.10.mga8.x86_64
- virtualbox-kernel-desktop-latest-6.1.22-2.10.mga8.x86_64

mcc does not otherwise offer to any kernel higher than
kernel-desktop-5.10.45-2.mga8 which is currently running

inxi -Gxx gives:

Graphics:  Device-1: NVIDIA GA104 [GeForce RTX 3070] vendor: ASUSTeK driver: nvidia 
           v: 460.84 bus ID: 01:00.0 chip ID: 10de:2484 
           Display: x11 server: Mageia X.org 1.20.11 compositor: kwin_x11 
           driver: nvidia,v4l resolution: 2560x1440~60Hz s-dpi: 108 
           OpenGL: renderer: GeForce RTX 3070/PCIe/SSE2 v: 4.6.0 NVIDIA 460.84 
           direct render: Yes 

Let me know if you need any more information.

This is a fallout of a rpmdrake bug, see:
https://bugs.mageia.org/show_bug.cgi?id=29148

basically it pulls deps from backports even if it's disabled.

The reason it switched from nvidia to nouveau is because it pulled in the 5.12 series kernel, but not the matching -devel packages, so the dkms-nvidia-current could not be properly be built -> switch to free driver that is known to be there...

Should it not refuse to install the kernel "due to missing xxx-devel"?

[Collision]
Thank you tmb for noticing this. My post was:

Thank you [Martin] for your quick response.
Normally you should have chosen the more recent VB 6.1.22, but never mind for the moment. The mix of kernel versions 5.10/5.12 with Add/Remove software is unhappy. [tmb has explained it]

Can you test the installation from the command line without actually doing it, and post the output?
 $ sudo urpmi --test virtualbox
or
 # urpmi --test virtualbox

Without any nVidia complications, and kernel 5.10.43-desktop-1.mga8 (just updated to .45, but not yet re-booted to same), I got:
  dkms-minimal                   2.0.19       41.mga8       noarch  
  virtualbox                     6.1.22       1.mga8        x86_64  
  virtualbox-kernel-5.10.45-des> 6.1.22       1.8.mga8      x86_64  
  virtualbox-kernel-desktop-lat> 6.1.22       1.8.mga8      x86_64 (suggest)

(In reply to Martin Ward from comment #4)
> Should it not refuse to install the kernel "due to missing xxx-devel"?

nope, since the kernels works fine without matching -devel packages for all not using any dkms packages, we cant enforce that dep

sudo urpmi --test virtualbox

In order to satisfy the 'kmod(vboxdrv.ko)[== 6.1.22]' dependency, one of the following packages is needed:
 1- virtualbox-kernel-5.10.41-desktop-1.mga8-6.1.22-1.5.mga8.x86_64: virtualbox driver for kernel-desktop-5.10.41-1.mga8 (to install)
 2- virtualbox-kernel-5.10.43-desktop-1.mga8-6.1.22-1.6.mga8.x86_64: virtualbox driver for kernel-desktop-5.10.43-1.mga8 (to install)
 3- virtualbox-kernel-5.10.45-desktop-2.mga8-6.1.22-1.8.mga8.x86_64: virtualbox driver for kernel-desktop-5.10.45-2.mga8 (to install)
What is your choice? (1-3) 3
To satisfy dependencies, the following packages are going to be installed:
(test only, installation will not be actually done)
  Package                        Version      Release       Arch    
(medium "Core Updates")
  virtualbox                     6.1.22       1.mga8        x86_64  
  virtualbox-kernel-5.10.45-des> 6.1.22       1.8.mga8      x86_64  
  virtualbox-kernel-desktop-lat> 6.1.22       1.8.mga8      x86_64  (recommended)
120MB of additional disk space will be used.
39MB of packages will be retrieved.
Proceed with the installation of the 3 packages? (Y/n) n

yes, urpmi will install the proper packages, it's only rpmdrake that has this bug...

The reason no-one has hit this before mga8 is that we haven't had the newer "core kernels" in backports, so it has just worked (by luck) :)

[collision again!]

Real time!
Noting comment 3 "The reason it switched from nvidia to nouveau is because it pulled in the 5.12 series kernel", the test output above looks good for installing VB without kernel 5.12 confusion. If you agree (and knowing that you can backtrack) - why not try it? without the --test parameter, of course!
 $ sudo urpmi virtualbox

An easier fallback if the system boots but the graphics do not work, you should be able to use the console (or possibly a virtual one with Ctl/Alt/F2-6) to adjust the grpahics:
 # XFdrake
and/or remove virtualbox with:
 # urpme virtualbox

(In reply to Thomas Backlund from comment #8)
> yes, urpmi will install the proper packages, it's only rpmdrake that has
> this bug...
> 
> The reason no-one has hit this before mga8 is that we haven't had the newer
> "core kernels" in backports, so it has just worked (by luck) :)

Also, most of the qa testers are using either qarepo or urpmi, not rpmdrake
for testing potential updates.

CC: (none) => davidwhodgins

This problem only seems to affect software installation, not updating. I routinely use drakrpm for testing updates, usually though MCC, but sometimes through the panel applet. Using drakrpm-update" in the command line does the same thing, and may point someone in the right direction to solve this.

Here is the terminal output from running "drakrpm-update" on this desktop (no backports, testing [except for QA testing], or 32-bit repos enabled:

> tom@localhost ~]$ drakrpm-update
> Ignore the following Glib::Object::Introspection & Gtk3 warnings
> Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539.
> getting lock on urpmi
> comparing /home/tom/qa-testing/x86_64/media_info/MD5SUM and /var/lib/urpmi/QA Testing (64-bit)/MD5SUM
> medium "QA Testing (64-bit)" is up-to-date
> not using metalink since requested downloader does not handle it
> retrieved http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/core/updates media_info/MD5SUM
> comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Updates (distrib3)/MD5SUM
> medium "Core Updates (distrib3)" is up-to-date
> retrieved http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/nonfree/updates media_info/MD5SUM
> comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Updates (distrib13)/MD5SUM
> medium "Nonfree Updates (distrib13)" is up-to-date
> retrieved http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/tainted/updates media_info/MD5SUM
> comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Updates (distrib23)/MD5SUM
> medium "Tainted Updates (distrib23)" is up-to-date
> unlocking urpmi database
> getting lock on urpmi
> examining synthesis file [/var/lib/urpmi/QA Testing (64-bit)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Core Release (distrib1)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Core Updates (distrib3)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Nonfree Release (distrib11)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Nonfree Updates (distrib13)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Tainted Release (distrib21)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Tainted Updates (distrib23)/synthesis.hdlist.cz]
> unlocking urpmi database

Note that when it examines the various hdlists, it only does so for those enabled for updates.



Now, take a look at the output from running simply "drakrpm" :

> [tom@localhost ~]$ drakrpm
> Ignore the following Glib::Object::Introspection & Gtk3 warnings
> Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539.
> Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805.
> Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805.
> Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805.
> Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805.
> Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805.
> Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805.
> Use of uninitialized value $value in numeric eq (==) at /usr/share/perl5/vendor_perl/Gtk3.pm line 805.
> Impossible to set by_group view as default
> getting lock on urpmi
> examining synthesis file [/var/lib/urpmi/QA Testing (64-bit)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Core Release (distrib1)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Core Updates (distrib3)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Core Backports (distrib7)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Nonfree Release (distrib11)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Nonfree Updates (distrib13)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Nonfree Backports (distrib17)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Tainted Release (distrib21)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Tainted Updates (distrib23)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Tainted Backports (distrib27)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Core 32bit Backports (distrib34)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Nonfree 32bit Backports (distrib39)/synthesis.hdlist.cz]
> examining synthesis file [/var/lib/urpmi/Tainted 32bit Backports (distrib44)/synthesis.hdlist.cz]
> unlocking urpmi database

Note that it is examining ALL backport hdlists, even though none of them are enabled. Why is it doing that???

CC: (none) => andrewsfarm

Installing with urpmi works, thanks!

I think that if the current driver is Nvidia, then the system should not install a new kernel (or at least, should complain about it) if the Nvidia driver cannot be used with the new kernel and will be switched out for another driver (which might not even work!)

In the future I will check that the -devel kernel is also being installed whenever it wants to install a new kernel!

Thanks for the success story.

This bug is a variant of bug 29148, so closing this one as a duplicate of that.

*** This bug has been marked as a duplicate of bug 29148 ***

Status: NEEDINFO => RESOLVED
Resolution: (none) => DUPLICATE