Thanks for the report, and the link to the other [closed] bug.

Seems suitable to assign immediately to the kernel team.

Assignee: bugsquad => kernel

Nope, thia ia a drakx issue

Assignee: kernel => mageiatools
Source RPM: (none) => rpmdrake

and this is probably an "ancient" bug that has not shown up for a long time since I haven't almost never pushed core core kernels to both updates and backports...

so we are probably missing a filtering of disabled media repos...

drakx allows to search even disabled repos by design, but it should not do the same when fulfilling deps from active medias

Could this be due to ...
$ urpmq --whatprovides 'kmod(vboxdrv.ko) = 6.1.22'
No package named kmod(vboxdrv.ko) = 6.1.22
$ urpmq --whatprovides 'kmod(vboxdrv.ko)'
dkms-virtualbox|virtualbox-kernel-5.10.16-server-1.mga8|virtualbox-kernel-5.10.16-desktop-1.mga8|virtualbox-kernel-5.10.19-server-1.mga8|virtualbox-kernel-5.10.19-desktop-1.mga8|virtualbox-kernel-5.10.20-server-2.mga8|virtualbox-kernel-5.10.20-desktop-2.mga8|virtualbox-kernel-5.10.25-server-1.mga8|virtualbox-kernel-5.10.25-desktop-1.mga8|virtualbox-kernel-5.10.27-server-1.mga8|virtualbox-kernel-5.10.27-desktop-1.mga8|virtualbox-kernel-5.10.30-desktop-1.mga8|virtualbox-kernel-5.10.30-server-1.mga8|virtualbox-kernel-5.10.30-desktop-1.mga8|dkms-virtualbox|virtualbox-kernel-5.10.30-server-1.mga8|virtualbox-kernel-5.10.33-server-1.mga8|virtualbox-kernel-5.10.33-desktop-1.mga8|virtualbox-kernel-5.10.33-server-1.mga8|virtualbox-kernel-5.10.33-desktop-1.mga8|dkms-virtualbox|virtualbox-kernel-5.10.37-desktop-2.mga8|virtualbox-kernel-5.10.37-server-2.mga8|virtualbox-kernel-5.10.41-desktop-1.mga8|virtualbox-kernel-5.10.41-server-1.mga8|virtualbox-kernel-5.10.43-server-1.mga8|virtualbox-kernel-5.10.43-desktop-1.mga8

CC: (none) => davidwhodgins

Strange: 
$ uname -a
Linux mach1.hviaene.thuis 5.10.43-server-1.mga8 #1 SMP Fri Jun 11 07:34:35 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
but then the command
$ urpmq --whatprovides 'kmod(vboxdrv.ko)'
does not list the last two virtualbox-kernels, it stops at 5.10.41.

(In reply to Dave Hodgins from comment #4)
> Could this be due to ...

Nope.

> $ urpmq --whatprovides 'kmod(vboxdrv.ko) = 6.1.22'
> No package named kmod(vboxdrv.ko) = 6.1.22

This is basically asking for a package name "kmod(vboxdrv.ko) = 6.1.22"

you cant search for version that way...

and for real provides checks:

urpmq --provides virtualbox-kernel-5.10.43-desktop-1.mga8 |grep kmod
kmod(vboxdrv.ko)[== 6.1.22]

urpmq --provides dkms-virtualbox |grep kmod
dkms-virtualbox: kmod(vboxdrv.ko)[== 6.1.22]

(In reply to Thomas Backlund from comment #3)

> drakx allows to search even disabled repos by design

I see that now in new try.

Then the UI should reflect that. (or fix the design, to obey user selection in media configuration, unless it have some side effect)

As now in the menu there is a link to media configuration, user go there, deselect media, return, and drakx still list packages from the repos user disabled...  So user may accidentally i.e install packages from debug repos if user rely on the apparently offered but not obeyed filtering...

CC: (none) => fri

This may explain why I often get pop-up messages like the following.
They pop up after drakrpm have successfully installed packages, before it return to main UI.  Now after having updated and kernel and friends from 5.10.45-1 to 5.10.45-2 :

Paketet "cpupower-5.10.45-2.mga8.i586" hittades.   ( was found )
Men det här paketet finns inte med i paketlistan.   ( but is not in packet list )
Du behöver nog uppdatera din urpmi-databas.     ( you should probably update your urpmi data base )

Matchande paket:                  ( matching packages: )

- cpupower-5.10.45-2.mga8.x86_64 (media: Ingen (installerad))
- cpupower-5.12.10-2.mga8.i586 (media: Core 32bit Backports (distrib34))
- cpupower-5.12.10-2.mga8.x86_64 (media: Core Backports (distrib7))
- cpupower-5.12.4-1.mga8.i586 (media: Core 32bit Backports (distrib34))
- cpupower-5.12.4-1.mga8.x86_64 (media: Core Backports (distrib7))
- cpupower-5.12.6-1.mga8.i586 (media: Core 32bit Backports (distrib34))
- cpupower-5.12.6-1.mga8.x86_64 (media: Core Backports (distrib7))
- cpupower-5.12.8-1.mga8.i586 (media: Core 32bit Backports (distrib34))
- cpupower-5.12.8-1.mga8.x86_64 (media: Core Backports (distrib7))
- cpupower-devel-5.10.16-1.mga8.i586 (media: Core 32bit Release (distrib31))
- cpupower-devel-5.10.16-1.mga8.x86_64 (media: Core Release (distrib1))
- cpupower-devel-5.10.43-1.mga8.i586 (media: Core 32bit Updates (distrib32))
- cpupower-devel-5.10.43-1.mga8.x86_64 (media: Core Updates (distrib3))
- cpupower-devel-5.10.45-2.mga8.i586 (media: Core 32bit Updates Testing (distrib33))
- cpupower-devel-5.10.45-2.mga8.x86_64 (media: Core Updates Testing (distrib5))
- cpupower-devel-5.12.10-2.mga8.i586 (media: Core 32bit Backports (distrib34))
- cpupower-devel-5.12.10-2.mga8.x86_64 (media: Core Backports (distrib7))
- cpupower-devel-5.12.4-1.mga8.i586 (media: Core 32bit Backports (distrib34))
- cpupower-devel-5.12.4-1.mga8.x86_64 (media: Core Backports (distrib7))
- cpupower-devel-5.12.6-1.mga8.i586 (media: Core 32bit Backports (distrib34))
- cpupower-devel-5.12.6-1.mga8.x86_64 (media: Core Backports (distrib7))
- cpupower-devel-5.12.8-1.mga8.i586 (media: Core 32bit Backports (distrib34))
- cpupower-devel-5.12.8-1.mga8.x86_64 (media: Core Backports (distrib7))

Except that is looks in disabled repos, i wonder what it is trying to achieve at that moment?
- it have already successfully performed what user wanted.

Further observations:

§ In rpmdrake the menu choice for updating correctly lists only the enabled media.

§ When rpmdrake is set to show updates it do *not* consider Core Backports *Testing* when it is disabled, but *do* list packages from Core Backports even when it is disabled.  (have not tested other repos)

@Thierry, 
is it hard to get this fixed ?

we now got a "duplicate bug" that actually broke the setup with nvidia-current driver: https://bugs.mageia.org/show_bug.cgi?id=29169

CC: (none) => thierry.vignaud

(In reply to Morgan Leijström from comment #9)
> Further observations:
> 
> § In rpmdrake the menu choice for updating correctly lists only the enabled
> media.
> 
> § When rpmdrake is set to show updates it do *not* consider Core Backports
> *Testing* when it is disabled, but *do* list packages from Core Backports
> even when it is disabled.  (have not tested other repos)

(copied from a comment in Bug 29169):

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

Also keep in mind that the synthesis files on the localhost will only have
indexed what was available in those repos when the repo was added to urpmi.

The backports synthesis files will will not be updated when checking for updates
unless they have been enabled. At least I think that's the case. That makes it
even harder to trigger.

So far, as far as I've seen, the problem is only triggered when installing virtualbox. Not updating it, or installing something else. And, if you remove the backport repos, not just disable them, it's not triggered, either. (As one would suspect would happen)

Also, it seems just a bit too coincidental that the only disabled repos that are being accessed by this issue are the backport repos, and the backport synthesis files are the only files from disabled repos being "examined" when you run drakrpm.

Not only virtualbox, see tmb's comment 10 for nvidia, and my comment referenced in comment 0: i selected to install packages for kernel 5.10.43, but drakrpm gave me some for 5.12.10

The bug in Comment 10 was triggered when the reporter installed virtualbox. The 5.12 series kernel was drawn in from backports, but the corresponding kernel-devel package was not, so dkms-nvidia couldn't build the kernel module.

I have a relatively new mga8 install available. I asked drakrpm to install virtualbox, and it wanted to draw in a 5.12 series kernel from backports, even though all backports repos have never been enabled on this install. Same thing if I tried to install the "latest" virtualbox kmod package without virtualbox. Same thing if I tried to install the "latest" vbox kmod for the server kernel, which isn't installed. In that case, it properly wanted to install the 5.10.45 server kernel, but also the 5.12.

But when I asked to install the "latest" for the 5.10.45 server kernel *without* any vbox packages, nothing from backports was listed to be brought in as a dependency. That was what led me to believe that vbox is somehow always involved.

I wonder what would happen if vbox was already installed, and the user decided to switch to another kernel flavor? I'd be willing to bet that drakrpm would want to draw in the 5.12 series kernel then, too.

After messing around with this, I found out that I could successfully install Virtual Box if I first manually select and install the correct virtualbox-kernel version.

That other bug 29169 (see especially its comments 7 8 12) shows that using 'urpmi' avoids the basic problem of looking in Backports & mixing kernel versions. Although it specifically complains about breaking nVidia graphics, the root cause for that is *this* bug; so I shall make it a duplicate.

*** Bug 29169 has been marked as a duplicate of this bug. ***

CC: (none) => martin

*** Bug 27436 has been marked as a duplicate of this bug. ***

CC: (none) => yves.brungard_mageia

*** Bug 29390 has been marked as a duplicate of this bug. ***

CC: (none) => jeanmichel.varvou

I ran into this bug when attempting to install dkms-rtl8192eu on a system that did not have any kernel-devel packages installed. Installed kernels were 5.10.60 and 5.10.62. When dkms-rtl8192eu was selected, it properly wanted to draw in kernel-desktop-devel 5.10.60, but it also wanted kernel-desktop-devel 5.13.something and kernel-desktop-devel-latest from backports. It did NOT ask for kernel-desktop-devel-latest or kernel-desktop-devel 5.10.62 as it should have done.

Others have attempted to install this driver this way, and of course it failed for them. Raising the priorities of this bug, as it prevents proper installation of almost any proprietary device drivers.

Severity: normal => major
Priority: Normal => High

Thomas A Comment 21 experience in Bug 28795 - Newer rtl8192eu driver with support for kernel 5.12 series

Repeating my answer to that, because it more properly belongs here:

I must disagree, Morgan. 

When users first install Mageia, at the step where the online repositories are configured, if they use our GUI tool all of the mirror's hdlists are downloaded. Backports, testing, debug, all are there, even if they have never been activated. 

If they installed Mageia at release time, there was nothing in Backports, and if they never activate backports they never update that and they don't run into the bug. But if they install now, or use the gui to switch to a different mirror, new hdlists are downloaded, and now backports are no longer empty. And that means that even if they never did anything with backports, they run into the bug if they install almost anything that involves a "latest" package. 

The system from https://bugs.mageia.org/show_bug.cgi?id=28795#c21 was, until about a month ago, an old Mageia 7 test system. I made a new, clean install of Mageia 8 for testing purposes, clean rather than upgrade because I wanted to clear out all residue of old tests. 

Consequently, when I used the MCC tool to set up my mirror, the situation I described occurred. I have never done anything with backports on that system, other than set up the mirror with the gui. Many, if not most of our users are doing just that. They are not using the command line when one of our well-advertised Mageia tools is there.

Closing this as dupe of 29830 as that start with easier repeatable test case, and get directly to the point.

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

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