Add monolith-gnome-nvidia edition#12
Merged
Merged
Conversation
Add an NVIDIA variant of the GNOME edition and factor the shared module stack so the two recipes do not duplicate ~290 lines. - recipes/gnome-base.yml: shared modules (files, packages, CachyOS kernel swap, GNOME defaults/extensions, flatpaks, Terra mesa swap, scripts), imported by both recipes via from-file. mesa is kept: it is required for iGPU/Optimus and software rendering, and coexists with nvidia via glvnd. - recipes/recipe-gnome.yml: now from-file gnome-base.yml + os-release + initramfs + signing. - recipes/recipe-gnome-nvidia.yml: name monolith-gnome-nvidia; same base + nvidia.yml, PRETTY_NAME "Monolith GNOME (NVIDIA)". - recipes/nvidia.yml: install Negativo17 nvidia-driver + akmod-nvidia (incl. i686 libs for Steam/Proton) and compile the akmod against the CachyOS kernel using kernel-cachyos-devel-matched, then set modeset/nouveau- blacklist modprobe options, add the modules to the initramfs via dracut, enable the nvidia services, versionlock the stack, and drop the repo. BlueBuild's akmods module and ublue's prebuilt nvidia images cannot be used because they are locked to the ublue kernel. - build.yml: add recipe-gnome-nvidia.yml to the matrix.
🧪 Test this PR on a real installOnce the build check on this PR passes, a signed test image is published to rpm-ostree rebase ostree-image-signed:docker://ghcr.io/mondrethos/monolith-gnome:pr-12-44
systemctl rebootThe tag is rebuilt on every new commit here, so rpm-ostree rebase ostree-image-signed:docker://ghcr.io/mondrethos/monolith-gnome:latestThe test tag stops updating once this PR is merged or closed. |
The first build failed resolving the transaction: nvidia-driver-libs.i686 -> libglvnd-gles.i686 -> mesa-libEGL.i686, but gnome-base.yml's Terra mesa swap excludes Fedora mesa and versionlocks the 64-bit Terra mesa, so the Fedora i686 mesa is both filtered and version-skewed. Re-enable the on-disk terra-mesa repo for the nvidia transaction and pull mesa-libGL.i686 / mesa-libEGL.i686 from it, matching the locked version (same build, same repo snapshot). Also drop gcc/make/elfutils-libelf-devel from the explicit install since the base already ships them.
The previous build resolved and installed all 46 packages but died in
akmod-nvidia's kmodtool %posttrans ("Rpm transaction failed" with no log):
that scriptlet auto-runs akmods during the rpm transaction, targeting the
wrong kernel in this container and hiding any build output.
Split the install: bring in the akmods framework + 32-bit mesa first, then
shim /usr/sbin/akmods to a no-op (same trick the kernel swap uses for the
kernel-install hooks) across the driver/akmod install so the transaction
can't fail on the auto-build, restore akmods, and build explicitly against
the CachyOS kernel with the build log dumped to stdout. This both fixes the
wrong-kernel auto-build and surfaces the real compiler error if the driver
genuinely won't compile against the CachyOS kernel.
The previous build got all the way to akmod-nvidia's kmodtool %post, which auto-runs akmods for the (correct) CachyOS kernel but fails because akmods refuses to run as root: "Not to be used as root; start as user or 'akmodsbuild' instead". Shimming /usr/sbin/akmods did not help since the %post inlines that logic rather than calling the wrapper. Install akmod-nvidia with rpm --noscripts (just to drop its SRPM into /usr/src/akmods), then build the module with akmodsbuild --kernels $KVER, which is the root-safe builder, and install the resulting kmod rpm. Pull in gcc-c++/make/elfutils-libelf-devel and dnf5-plugins (for `dnf5 download`). A genuine compile failure now surfaces as akmodsbuild's build output.
Root cause of the repeated "Not to be used as root" failure: the nvidia userspace requires the virtual `nvidia-kmod`, which dnf satisfies by pulling akmod-nvidia, whose kmodtool %post runs akmods -- and akmods refuses to run as root, failing the rpm transaction. Shimming/--noscripts could not help because akmod-nvidia is dragged in as a dependency of nvidia-driver. Build-first approach: install only the akmods framework + toolchain (no userspace, so nvidia-kmod is never requested and akmod-nvidia is never pulled); download akmod-nvidia solely to extract its kmod SRPM (rpm2cpio, never installed); build kmod-nvidia with akmodsbuild (root-safe) against the CachyOS kernel; then install the built kmod-nvidia together with the userspace in one transaction. kmod-nvidia Provides nvidia-kmod, so akmod-nvidia stays out entirely, and the cyclic kmod<->common dep resolves in the single transaction. --nogpgcheck covers the locally built, unsigned kmod.
Every prior attempt hit "Not to be used as root" because both akmod-nvidia's %post and a direct `akmodsbuild` call refuse to run as root. The akmods source shows the wrapper is the intended root entrypoint: `akmods --force` runs as root and drops to the unprivileged `akmods` user via runuser to do the actual akmodsbuild, then installs the kmod. Mirror ublue-os/akmods exactly: stage akmod-nvidia's /usr/src/akmods payload (SRPM + nvidia-kmod.latest) without installing the package, then `akmods --force --kernels $KVER --kmod nvidia`, dumping the failed.log on error. Install the userspace afterward; the freshly built kmod-nvidia satisfies the virtual nvidia-kmod so akmod-nvidia is never pulled.
Breakthrough: the previous build proved NVIDIA 610 compiles cleanly against
CachyOS 7.0.12 (~3min build). akmods reported "[FAILED]" only on the
self-install step ("Could not install newly built RPMs") because kmod-nvidia
Requires nvidia-kmod-common, which ships with the userspace and wasn't
installed yet -- the cyclic kmod<->common dep. akmods still exits 0 and leaves
the built rpm in /var/cache/akmods/nvidia/, so step 4 then pulled akmod-nvidia
and hit the root %post wall again.
Take the built rpm from /var/cache/akmods/nvidia/ and install it together with
the userspace in one dnf transaction, resolving the cycle. kmod-nvidia
Provides the virtual nvidia-kmod so akmod-nvidia is never pulled. Detect build
success by the rpm's presence (akmods' exit code is unreliable) and dump the
failed.log otherwise.
Negativo17's 610.x nvidia-kmod builds only NVIDIA's open-gpu-kernel-modules (kernel-open/*.ko); proprietary module support was dropped (vGPU-only, now in the nvidia-lts branch). The kmod-nvidia we build is therefore already the open module -- nothing to toggle. Document it so it isn't re-litigated.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds an NVIDIA variant of the GNOME edition and factors the shared module stack so the two recipes don't duplicate ~290 lines.
recipes/gnome-base.yml(new) — shared module stack (files, packages, CachyOS kernel swap, GNOME defaults/extensions, flatpaks, Terra mesa swap, scripts), imported by both recipes viafrom-file.recipes/recipe-gnome.yml— trimmed tofrom-file gnome-base.yml+ os-release + initramfs + signing.recipes/recipe-gnome-nvidia.yml(new) —name: monolith-gnome-nvidia, base +nvidia.yml,PRETTY_NAME="Monolith GNOME (NVIDIA)".recipes/nvidia.yml(new) — edition-agnostic NVIDIA module (see below).build.yml— matrix builds both recipes → publishes…/monolith-gnomeand…/monolith-gnome-nvidia.NVIDIA approach
BlueBuild's
akmodsmodule and ublue's prebuilt-nvidiaimages are locked to the ublue kernel, and this image swaps to the CachyOS kernel. CachyOS dropped prebuilt nvidia (Feb 2026) and point to RPMFusion/Negativo17. Sonvidia.yml:fedora-nvidiarepo (temporary, removed at the end).nvidia-driver+akmod-nvidia+ toolchain +nvidia-driver-libs.i686(Steam/Proton).kernel-cachyos-devel-matched, with hard-fail checks if headers or the.koare missing.nvidia-drm modeset=1, VRAM preservation, nouveau blacklist) + dracutadd_driversso it's baked into the initramfs.mesa is intentionally kept (glvnd coexistence; required for Optimus/iGPU and software rendering).
Notes / risk
pull_requestbuild is the test. Failures are loud (won't ship a GPU-less image).generate_release.yml/pr-rebase-hint.ymlstill operate onmonolith-gnomeonly; making them edition-aware is a follow-up.nvidia.ymlis edition-agnostic, so future editions reuse it via a ~30-line stub recipe.