I have an NVIDIA laptop running Fedora 40 Silverblue. It’s been running fine for weeks, but I shut it down for a few days and now rpm-ostree is getting conflicting requests.
$ sudo rpm-ostree upgrade
2 metadata, 0 content objects fetched; 788 B transferred in 1 seconds; 0 bytes content written
Checking out tree 7681f89... done
Inactive requests:
langpacks-en (already provided by langpacks-en-4.0-12.fc40.noarch)
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora copr:copr.fedorainfracloud.org:phracek:PyCharm rpmfusion-nonfree-steam rpmfusion-nonfree-nvidia-driver google-chrome nvidia-container-toolkit updates-archive
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2023-12-11T14:43:50Z solvables: 4
rpm-md repo 'updates' (cached); generated: 2024-02-13T17:21:08Z solvables: 0
rpm-md repo 'fedora' (cached); generated: 2024-04-11T08:47:23Z solvables: 74881
rpm-md repo 'copr:copr.fedorainfracloud.org:phracek:PyCharm' (cached); generated: 2024-03-18T11:54:41Z solvables: 14
rpm-md repo 'rpmfusion-nonfree-steam' (cached); generated: 2024-03-24T13:27:05Z solvables: 2
rpm-md repo 'rpmfusion-nonfree-nvidia-driver' (cached); generated: 2024-03-24T11:36:11Z solvables: 16
rpm-md repo 'google-chrome' (cached); generated: 2024-04-17T17:16:30Z solvables: 3
rpm-md repo 'nvidia-container-toolkit' (cached); generated: 2024-04-16T12:39:24Z solvables: 59
rpm-md repo 'updates-archive' (cached); generated: 2023-10-06T17:04:49Z solvables: 0
Resolving dependencies... done
error: Could not depsolve transaction; 2 problems detected:
Problem 1: package akmods-0.5.8-8.fc40.noarch from fedora requires (kernel-devel-matched if kernel-core), but none of the providers can be installed
- package kernel-devel-matched-6.8.4-300.fc40.x86_64 from fedora requires kernel-core = 6.8.4-300.fc40, but none of the providers can be installed
- package akmod-nvidia-3:550.67-1.fc40.x86_64 from rpmfusion-nonfree-nvidia-driver requires akmods, but none of the providers can be installed
- cannot install both kernel-core-6.8.4-300.fc40.x86_64 from fedora and kernel-core-6.8.5-301.fc40.x86_64 from @System
- package kmod-nvidia-3:550.67-1.fc40.x86_64 from rpmfusion-nonfree-nvidia-driver requires akmod-nvidia = 3:550.67-1.fc40, but none of the providers can be installed
- conflicting requests
Problem 2: package kmod-nvidia-3:550.67-1.fc40.x86_64 from rpmfusion-nonfree-nvidia-driver requires akmod-nvidia = 3:550.67-1.fc40, but none of the providers can be installed
- package xorg-x11-drv-nvidia-3:550.67-1.fc40.x86_64 from rpmfusion-nonfree-nvidia-driver requires nvidia-kmod >= 3:550.67, but none of the providers can be installed
- package akmod-nvidia-3:550.67-1.fc40.x86_64 from rpmfusion-nonfree-nvidia-driver requires akmods, but none of the providers can be installed
- package akmods-0.5.8-8.fc40.noarch from fedora requires gcc, but none of the providers can be installed
- package gcc-14.0.1-0.13.fc40.x86_64 from fedora requires cpp = 14.0.1-0.13.fc40, but none of the providers can be installed
- cannot install both cpp-14.0.1-0.13.fc40.x86_64 from fedora and cpp-14.0.1-0.15.fc40.x86_64 from @System
- conflicting requests
You have kmod-nvidia layered instead of akmod-nvidia. I’m not very familiar with the details of RPM Fusion’s nvidia packaging, but that may be the problem (and it isn’t what they instruct). Try:
P.S. rpm-ostree will resolve dependencies of layered packages, so you could for example just install the packages in virtualization group instead of that whole list. Rebasing will be a bit painful if any of those packages disappear or are renamed in a future release.
Thanks! I didn’t realize I could install a group with rpm-ostree. By the way, do I need the sudo with rpm-ostree? I’ve seen it in the documentation without sudo but it’s a habitual thing.
To be clear, you can’t install groups directly, but you can install the constituent packages manually, as listed in comps.
And no, you don’t need to use sudo with rpm-ostree. Authentication happens via polkit, and most actions are allowed for active local users in the wheel group. The same is true for flatpak.
Ah, OK. I actually don’t need the virtualization any more; distrobox does most of what I want except emulating risc-v and xtensa, and I’ve got enough hardware now that I don’t need emulators.
This is definitely an issue. Rpmfusion states that package is for RHEL and centos. The instructions tell users to install akmod-nvidia. This means the kmod-nvidia package should be removed then install the akmod-nvidia package. (The akmod-nvidia package then builds a kmod-nvidia package locally that matches the kernel.
Meanwhile, it still looks like there’s a conflict:
$ rpm-ostree status | more
State: idle
Deployments:
● fedora:fedora/40/x86_64/silverblue
Version: 40.20240412.n.0 (2024-04-12T08:13:30Z)
BaseCommit: 33868bd22cefb70fc9b160a1aa15bc52d97c30968f547e390de22e7ebae422bd
GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
LayeredPackages: akmod-nvidia bitstream-vera-fonts-all cascadia-fonts-all
distrobox git-lfs gnome-tweaks minicom net-tools
nvidia-container-toolkit nvtop variety vim xorg-x11-drv-nvidia
zsh zsh-autosuggestions zsh-syntax-highlighting
...
$ rpm-ostree upgrade
2 metadata, 0 content objects fetched; 788 B transferred in 1 seconds; 0 bytes content written
Checking out tree 7681f89... done
Inactive requests:
langpacks-en (already provided by langpacks-en-4.0-12.fc40.noarch)
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora copr:copr.fedorainfracloud.org:phracek:PyCharm rpmfusion-nonfree-steam rpmfusion-nonfree-nvidia-driver google-chrome nvidia-container-toolkit updates-archive
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2023-12-11T14:43:50Z solvables: 4
rpm-md repo 'updates' (cached); generated: 2024-02-13T17:21:08Z solvables: 0
rpm-md repo 'fedora' (cached); generated: 2024-04-11T08:47:23Z solvables: 74881
rpm-md repo 'copr:copr.fedorainfracloud.org:phracek:PyCharm' (cached); generated: 2024-03-18T11:54:41Z solvables: 14
rpm-md repo 'rpmfusion-nonfree-steam' (cached); generated: 2024-03-24T13:27:05Z solvables: 2
rpm-md repo 'rpmfusion-nonfree-nvidia-driver' (cached); generated: 2024-03-24T11:36:11Z solvables: 16
rpm-md repo 'google-chrome' (cached); generated: 2024-04-17T17:16:30Z solvables: 3
rpm-md repo 'nvidia-container-toolkit' (cached); generated: 2024-04-16T12:39:24Z solvables: 59
rpm-md repo 'updates-archive' (cached); generated: 2023-10-06T17:04:49Z solvables: 0
Resolving dependencies... done
error: Could not depsolve transaction; 2 problems detected:
Problem 1: package gcc-14.0.1-0.13.fc40.x86_64 from fedora requires cpp = 14.0.1-0.13.fc40, but none of the providers can be installed
- package akmods-0.5.8-8.fc40.noarch from fedora requires gcc, but none of the providers can be installed
- cannot install both cpp-14.0.1-0.13.fc40.x86_64 from fedora and cpp-14.0.1-0.15.fc40.x86_64 from @System
- package akmod-nvidia-3:550.67-1.fc40.x86_64 from rpmfusion-nonfree-nvidia-driver requires akmods, but none of the providers can be installed
- conflicting requests
Problem 2: package kmod-nvidia-3:550.67-1.fc40.x86_64 from rpmfusion-nonfree-nvidia-driver requires akmod-nvidia = 3:550.67-1.fc40, but none of the providers can be installed
- package xorg-x11-drv-nvidia-3:550.67-1.fc40.x86_64 from rpmfusion-nonfree-nvidia-driver requires nvidia-kmod >= 3:550.67, but none of the providers can be installed
- package akmod-nvidia-3:550.67-1.fc40.x86_64 from rpmfusion-nonfree-nvidia-driver requires akmods, but none of the providers can be installed
- package akmods-0.5.8-8.fc40.noarch from fedora requires (kernel-devel-matched if kernel-core), but none of the providers can be installed
- package kernel-devel-matched-6.8.4-300.fc40.x86_64 from fedora requires kernel-core = 6.8.4-300.fc40, but none of the providers can be installed
- cannot install both kernel-core-6.8.4-300.fc40.x86_64 from fedora and kernel-core-6.8.5-301.fc40.x86_64 from @System
- conflicting requests
Yes I did … maybe I should uninstall akmod and the NVIDIA driver, then reboot, upgrade and re-install them. Now that I have all the virtualization packages removed rpm-ostree runs fairly quickly`.
The conflict is between the versions of cpp (the C preprocessor) in the base image and gcc being layered for akmod.rpm-ostree refresh-md should fix it by making the latest gcc available for client-side layering. It would also start working within 6 hours when that cache expired.
This sort of thing is a common issue when layering a package that is tightly coupled to one in the base image. I have no idea why cpp is in the base image though. (Edit: it’s a recommended package of xrdb, which is a dependency of gdm.)
Now I am actually more confused. When I originally installed I followed these directions:
which call for kmod, not akmod. That has been working for some time now; it just started giving me trouble last night. Also, I tried refresh-md and it didn’t help.
Given that the GPU is fairly old, an RTX 1650, maybe I should just use nouveau until I hit some application that doesn’t work. How do I remove the kernel arguments that were set when I followed those instructions?
Yeah, that page should probably be changed, but either one seems to work; I think that was a red herring.
I’m not sure why refresh-md didn’t work. You could try rpm-ostree cleanup -m, but that should have the same effect. It’s possible the mirror is a bit stale. I expect it will start working soon (after the cache expires in 6 hours, or you manually refresh again).
My F40 toolbox container was also in that 6 hour time window where it didn’t show the new version until I used dnf --refresh upgrade.
I think that’s still new enough that nouveau would be a poor experience. Fortunately, it’s also just barely new enough to be targeted by the upcoming nova / nvk open source driver.
To remove those kernel arguments, you can use the same rpm-ostree kargs command, but with --delete instead of --append.
I went ahead and deleted the NVIDIA packages entirely. The GPU has no tensor cores or ray tracing cores and it’s two generations behind what you can buy today so I think nouveau can probably handle everything I’m going to be running.
I do have a script that runs pytorch with a GPU that currently lives in a conda virtual environment. That all worked in a Distrobox Fedora40 NVIDIA container in the previous builds so if it works with nouveau I can stop troubleshooting.
