* chore: remove centos and centos-kmodsig akmods support
CentOS Stream 10 builds are no longer needed. This change removes:
- The centos kernel flavor from images.yaml and its generated workflow
- The centos-kmodsig dead code from Justfile and fetch-kernel.sh
- All centos-specific branches in build scripts (prep, test, nvidia, dual-sign)
- The #ifndef CENTOS preprocessor guard in Containerfile.in
- CentOS references from README.md badges and examples
- CentOS from artifacthub package keywords
* docs: update akmods example version to 44
* chore: drop Fedora 43 builds
Fedora 43 akmods are no longer needed by the maintained downstreams.
Retire their build matrix alongside the removal of GTS support in
ublue-os/main to stop producing unused kernel and module caches.
* fix: preserve Fedora 43 CoreOS stable builds
Bluefin LTS HWE and GDX still consume coreos-stable-43 akmods, so retain that flavor while dropping the other Fedora 43 builds.
* chore(deps): update ghcr.io/ublue-os/devcontainer:latest docker digest to ba4c0e5
* fix(build): enable just list support
The refreshed devcontainer's just version requires list support for which(). Enable it so CI can evaluate build recipes.
---------
Co-authored-by: ubot-7274[bot] <217212047+ubot-7274[bot]@users.noreply.github.com>
Co-authored-by: Benjamin Sherman <benjamin@holyarmy.org>
ubuntu-latest will soon migrate to 26.04. Update in advance to verify
behavior. Pin every job in the build, cache, and publish path to 26.04
explicitly so the runner OS is deterministic there. Housekeeping
workflows (cleanup, scorecard) stay on ubuntu-latest.
* chore(nvidia): move negativo nvidia repos to /usr
This PR should do the following things:
On Fedora 45 and higher, move .repo files from /etc/yum.repos.d to
/usr/share/dnf5/repos.d.
On Fedora 44 and centos/rhel, don't touch anything, package should be
identical after this change and keep the
/usr/share/ublue-os/etc/yum.repos.d for everything for now.
As discussed in: https://github.com/ublue-os/akmods/issues/591#issuecomment-5742188994
* debug package contents
* rm /usr/share/ublue-os/etc/yum.repos.d from F45 and higher
* remove more redundant leading slashes
or else this results in /usr/share/ublue-os//etc/yum.repos.d with 2
slashes as %{_sysconfdir} resolves to /etc which already has a slash
character
* add check to prevent shipping enabled repos
* changelog
* make test check for True and yes as well
These are also valid options in dnf5, however at least Fedora sticks
with 0/1.
See: https://dnf5.readthedocs.io/en/stable/dnf5.conf.5.html#boolean-label
See: https://dnf5.readthedocs.io/en/stable/dnf5.conf.5.html#repo-options
This gets rid of one occurence of the hardcoded yum.repos.d, also we
should be using the standard COPR naming scheme, nothing in the org, for
this particular dnf repo at least, relies this non-standard naming
convention.
The dnf copr plugin seems to create a new .repo file in /etc/yum.repos.d
even though it is already present and disabled in
/usr/share/dnf5/repos.d (which is what we want to do in Aurora [1])
So if you rely on this script to add/enable ublue-os/staging then this
shouldn't affect anything, however, if you are vendoring the repo files
and putting them in /usr/share/dnf5/repos.d then you won't have this
specific COPR repo anymore in /etc/yum.repos.d.
This is a step towards [2].
[1] https://github.com/ublue-os/aurora/issues/2854
[2] https://github.com/ublue-os/akmods/issues/591
* bringup f45
* update the workflow
* do-not-test
* use dnf repo commands instead of sed
* gate openrazer on f45
* add notice for temp workaround for openrazer
* fix: Fail the build when a common or nvidia kmod script fails
The RUN blocks that call build-kmod-*.sh for the common and nvidia
targets ran `bash <<'RUNEOF'` without `set -euo pipefail`, unlike every
other block in the Containerfile. When a script exited non-zero, the
remaining scripts still ran and the build went on to RPM caching and
signing with a partial set of modules.
That is how the Terra openrazer change broke aarch64 builds. openrazer
aborted before removing its repo file, and the later kmod scripts kept
running with that repo still enabled, pulling in x86_64 RPMs.
Add `set ${CI+-x} -euo pipefail` to the common kmod block and the three
nvidia blocks so any failure stops the job. The extra block already has
it and intentionally keeps going on per-kmod failures via
`|| echo "SKIPPED: ..."`, so it is unchanged.
* fix: Retry the ZFS release downloads and fail on bad responses
`build-kmod-zfs.sh` fetched the OpenZFS release list from the
unauthenticated GitHub API with a bare `curl`, no retry and no `--fail`.
When GitHub throttled the runner it wrote the rate-limit page to
`data.json`, `jq` then died with "Invalid numeric literal", and the
build stopped with no hint of the real cause. The release tarball and
signature downloads had the same exposure to a transient github.com
error.
Route all four through a shared `curl --fail --show-error --location
--retry 5 --retry-delay 5 --retry-all-errors`, so a throttle or 5xx is
retried and a persistent bad response aborts the script at the curl
call.
* don't attempt vhba for aarch64
* feat: Switch to terra package for openrazer, now auto-updates and no longer requires manual ublue intervention for updates
* fix: Skip openrazer build on aarch64
Terra only publishes openrazer for x86_64. On aarch64 the build script
fails at `dnf install akmod-openrazer` (no arch match) before reaching
its `rm -f /etc/yum.repos.d/terra.repo` cleanup.
The leaked Terra repo then stays enabled for every later script in the
same layer, so `dnf download` pulls x86_64 builds of v4l2loopback and
xpadneo into the shared /var/cache/rpms/common set. The final aarch64
test install then fails on the incompatible-arch RPMs.
Exit early on aarch64 so the Terra repo is never added, matching the
existing wl build script.
---------
Co-authored-by: Benjamin Sherman <benjamin@holyarmy.org>
ZFS failing on a too-new CoreOS stable kernel turns the whole
coreos-stable check red and blocks nvidia and CVE updates. The
Justfile pin exists for that hold, but it was only a comment, so
the 7.1 incident went to local ZFS backports instead.
Document the pin policy in the README and point the ZFS configure
failure path at it when the kernel looks newer than OpenZFS
declares supported.
coreos-stable ZFS builds have failed since CoreOS moved to kernel 7.1,
holding back kernel CVE fixes and nvidia driver updates from ucore and
other downstream consumers.
The 7.1 code compat (openzfs/zfs#18471) already shipped in 2.4.3 — only
META's Linux-Maximum gates it. Raising that ceiling (openzfs/zfs#18682)
unblocks the build without --enable-linux-experimental, which would
otherwise flood dmesg with EXPERIMENTAL warnings and mask real errors.
Also carry openzfs/zfs#18715, which replaces a compiled-out ASSERT3U in
zfs_fillpage() with a real bounds check. Without it an mmap read racing a
truncate underflows io_len and zero-fills forward across physical memory.
This is not 7.1-specific and already affects the 7.0.x builds we ship.
Neither commit is on zfs-2.4-release, so patching is gated to exactly
2.4.3 and stops once upstream ships a release carrying them.
coreos-testing no longer needs the experimental switch now that META
covers 7.1.
* fix(nvidia): order CDI generation before nvidia-persistenced to fix boot race
nvidia-persistenced and nvidia-powerd only start if /dev/nvidia* already
exists, but those device nodes aren't created until CDI generation runs.
Without any ordering between the two, persistenced would sometimes lose
that race and stay stopped for the rest of the boot (ublue-os/ucore#419).
nvidia-container-toolkit-base now ships its own nvidia-cdi-refresh
service, which is better than our old ublue-nvctk-cdi.service: it forces
device creation explicitly, retries on failure, and re-runs on driver
upgrades. Switch to it and add a drop-in ordering it before
nvidia-persistenced and nvidia-powerd, so the race can't happen.
Verified on real NVIDIA hardware across multiple reboots.
* chore: Add missing service to nvidia-install.sh
---------
Co-authored-by: Kyle Gospodnetich <me@kylegospodneti.ch>
* Readd vhba to support CDEmu again in Bazzite
* Also add vhba-kmod-common in cache manually, to allow to build it correctly.
* Fix wrong changelog date
---------
Co-authored-by: RodoMa92 <marco.rodolfi.1992@gmail.com>
Store build provenance in GitHub's attestations API without attaching it to GHCR. Add post-publication verification for Podman signatures, containers/image policy enforcement, and manifest provenance.
