They don’t want to install. I get strange messages from dnf but they don’t help much. Here’s what I’m seeing:
dnf install $(cat doit)
Updating and loading repositories:
Repositories loaded.
Failed to resolve the transaction:
Problem: installed package kernel-6.19.0-0.rc7.47.fc44.x86_64 requires (kernel-modules-extra-uname-r = 6.19.0-0.rc7.47.fc44.x86_64 if kernel-modules-extra-matched), but none of the providers can be installed
conflicting requests
problem with installed package
You can try to add to command line:–skip-broken to skip uninstallable packages
I installed the missing(?) package but dnf still fails.
If you are running what is labeled as fc44 then that is rawhide and a development version where things may not be (and probably aren’t) stable so users should expect breakage. If you want a stable system where we can assist with issues then you should downgrade to f43 instead.
It is quite understandable that it does not work with that kernel-modules-extra package. The message you posted calls for kernel-modules-extra-uname-r = 6.19.0-0.rc7.47.fc44.x86_64 if kernel-modules-extra-matched and the package you installed was kernel-modules-extra-6.19.0-0.rc8.54.fc44.x86_64 which is a clear version mismatch.
To manually install a kernel you have to install at least the matching kernel , kernel-core , kernel-modules , and kernel-modules-core packages together. If you need a module from -extra you also need kernel-modules-extra . You have to do this all in one command, with all the packages from the same build.
rc7.47.fc44 has been in Rawhide since Jan 27 anyway, though, so you shouldn’t need to download it from Koji in the first place. In fact, your rpm -q output shows you already got one newer kernel package - the currently-tagged rc8.54.fc44. Why not just run dnf update and see if you get the rest of the rc8.54.fc44 kernel packages that way?
I’m running into support people who do NOT want to help me with this situation.
I don’t know just where this string “kernel-modules-extra-uname-r” comes from but it seems to me that the “uname-r” is wrong. I think it should be the output of a command so that the “current” systems kernel name is substituted into the string. I tested this by first installing with kernel-modules-extra-uname-r which faild since that package does NOT exist. I then replaced the “uname -r” with my systems output of the uname -r command… IT WORKED. Hmmm… Packaging error?
Regards,
George..
Someone replied to your post.
Jeff V computersavvy You can call me "Wikipedia Brown" (Ask Fedora V)
February 5
George R. Goffe:
my FC44 system
If you are running what is labeled as fc44 then that is rawhide and a development version where things may not be (and probably aren’t) stable so users should expect breakage. If you want a stable system where we can assist with issues then you should downgrade to f43 instead.
It is quite understandable that it does not work with that kernel-modules-extra package. The message you posted calls for kernel-modules-extra-uname-r = 6.19.0-0.rc7.47.fc44.x86_64 if kernel-modules-extra-matched and the package you installed was kernel-modules-extra-6.19.0-0.rc8.54.fc44.x86_64 which is a clear version mismatch.
This build system is a FC44 install on a Vivobook S16 system, 20 cores and 40G memory.
I’m trying to resolve a VirtualBox support problem. VB does NOT support the 6.19 kernel(s) yet; since they are release candidates.
My kernel-6.18"*" got lost, probably a user (me) error.
I’m trying to get the 6.18 kernel back so I can run VB and do this work in an environment that won’t be destroyed or damaged by my efforts.
My thoughts are that if I install a pristine FC44 and make NO mods to the system… and download gcc from the repo and other software it needs… and try to build again. If it fails the same way… well, I think it’s a bug somewhere but where?
The main bug I’m trying to work on is a segfault in the make command while building gcc from the gcc repo. I have tried all the make-4"*" versions and all fail… the same way… I went to github and cloned “libcody” and tried to build it. SAME symptom.
i.e. kernel-modules-extra-uname-r is a ‘virtual capability’ provided by the kernel-modules-extra package. This kind of virtual provide is very, very common in RPM packaging, and used for all kinds of reasons.
Yes, we usually say mixing packages from different releases is a bad idea, but it’s actually usually fine for kernels.
I don’t know anything about VirtualBox (I only ever run it once every six months, on Windows, to test it runs the new Fedora release okay), though. Sorry.
I generally don’t use this for kernels because there’s a ton of packages in the build, most of which you don’t need, and some of which are quite large.