Total Kernel Pin Events Documented: 10
Detailed Changelog of Kernel Pins (Newest to Oldest)#
2026-03-24: GDX kernel pin removed#
The kernel pin (6.17.12-200.fc42) was removed from GDX builds to resolve NVIDIA driver version mismatches. The pinned kernel had locked AKMODS_VERSION to an outdated container (akmods-nvidia-open:coreos-stable-42-6.17.12-200.fc42.x86_64) built on 2026-02-03 with kmod-nvidia-590.48.01, but negativo17's Fedora 43 repo had moved past that version and no longer carried matching nvidia-driver packages. GDX builds follow the coreos-stable akmods pattern, using the floating tag that tracks current driver versions and prevents version drift. This resolves build failures such as "No match for argument: libnvidia-fbc-3:590.48.01". PR #1231
2025-09-04: Unpinned gts and stable kernels#
The pins for gts kernel (6.14.11-200.fc41.x86_64) and stable kernel (6.14.11-300.fc42.x86_64) were removed after 49 days. These pins were originally applied to address stability concerns and ensure consistent behavior across streams. PR #3133
2025-07-17: Pinned kernels for gts and stable streams#
gts kernel was pinned to 6.14.11-200.fc41.x86_64 (PR #2779), and stable kernel was pinned to 6.14.11-300.fc42.x86_64 (PR #2777). These pins were implemented to mitigate regressions and maintain compatibility with critical hardware and software components.
2025-01-03: Kernel pin to 6.11.8#
Kernel was pinned to version 6.11.8 due to a reported issue affecting bazzite, which required holding back kernel updates to avoid breaking functionality. Issue #2103
Persistent Kernel Pins via Scripts#
Kernel packages (kernel, kernel-core, kernel-modules, kernel-modules-core, kernel-modules-extra) are persistently pinned using dnf5 versionlock add for stability and to prevent unexpected upgrades that could introduce incompatibilities or break system components. This mechanism is implemented in the main install script, which first removes existing kernel packages, installs specific RPMs, and then applies versionlocks. For Fedora 43, additional logic temporarily bypasses kernel-install scripts to avoid dracut errors during installation, restoring them after the process completes. This ensures reliable builds even when upstream scriptlets are problematic. See script
In Bluefin-LTS, kernel pinning is applied conditionally for x86_64 architecture, with a kernel swap script invoked before pinning. The following packages are pinned: kernel, kernel-devel, kernel-devel-matched, kernel-core, kernel-modules, kernel-modules-core, kernel-modules-extra, and kernel-uki-virt. This addresses kernel-devel update issues, especially on GDX hardware, and prevents skew between kernel and module versions. See script
Akmods Kernel Management#
The akmods repository manages kernel versions explicitly per build, fetching, installing, signing, and verifying specific kernel versions and flavors (including bazzite, centos, longterm, main). While it does not use versionlock, it ensures that only the intended kernel version is present and verified, supporting dual signing if required. This approach is critical for out-of-tree module compatibility and secure boot scenarios. See script
Notes:
- Kernel pins are applied for stability, compatibility, and to address specific issues (e.g., dracut errors, hardware support, module compatibility).
- Persistent pins via scripts may not have explicit removal dates; their duration is ongoing until the logic changes.
- Pin durations are calculated as the difference in days between the pin's introduction and its removal, or to the present if still active.
- For full context and rationale, see the linked pull requests, issues, and scripts.