merge fix/kernel-btf-assert (`bd04255c84`) #66

Merged

pipeline-bot merged 3 commits from fix/kernel-btf-assert into trunk

2026-07-29 19:33:36 +00:00

pipeline-bot commented

2026-07-29 19:32:49 +00:00

Collaborator

No description provided.

pipeline-bot added 3 commits

2026-07-29 19:32:49 +00:00

fix(linux-kernel): gate reads arch/$SRCARCH, and fails when it cannot read at all db48a78ffa

Caught by the first live BuildRun (linux-kernel-ci-h667z, 13s).

Two defects in the gate landed in d3aa310:

1. Wrong path. `make ARCH=x86_64` builds out of arch/x86, so the defconfig is
   arch/x86/configs/seanfarm_defconfig — not arch/x86_64/configs/. KARCH is the
   make ARCH, which is not the source-dir name on x86. Split out SRCARCH.

2. The gate was VACUOUS on that wrong path. Each check is
   `grep <sym> $SRC && ! grep <sym> .config`; when $SRC does not exist the
   first grep is non-zero, the && short-circuits, the if is false, and the loop
   reports "hard-gated symbols survived configure" having verified nothing.
   The build only failed later, incidentally, on the drift report's redirect.
   A gate that cannot read its input must fail, not pass — silently passing is
   worse than no gate because it reads as proof. Assert $SRC and .config are
   readable first.

pahole in kernel-builder:v9 is v1.31, comfortably over the 1.21 that
CONFIG_DEBUG_INFO_BTF needs for DWARF5, so BTF is genuinely supported.

Fixture-tested: green with BTF present; fails on a dropped BTF, on an
unreadable defconfig (regression test for defect 2), and on a missing pahole.

fix(node-bootc): retry dnf past EPEL stale-metadata 404s 6da455d98a

This is what actually killed the v6.18.35-seanfarm26 release. The kernel built
fine; node-bootc — the `bootc switch` target, and so the thing a roll actually
boots — died at:

  Status code: 404 for .../epel/10z/.../bb9a3191...-primary.xml.zst
  Error: Failed to download metadata for repo 'epel'

EPEL rotates its repodata frequently and deletes the old hashed files at once.
repomd.xml is the index naming them, so a build reading a repomd even slightly
behind the current rotation requests a primary.xml.zst that no longer exists.

Probed rather than assumed: the pkg-cache is NOT at fault. Its cached repomd is
byte-identical to upstream, it holds index files only 1m with revalidate, the
file the build wanted 404s UPSTREAM too, and the one the current repomd names
returns 200 through the cache. The race is against EPEL itself; the cache only
widens the window. Confirmed transient — the identical install succeeded
unchanged minutes after the failure.

Retry up to 5 times with backoff. `dnf clean metadata` between attempts is what
makes it work: without it dnf re-reads the same stale repomd from /var/cache/dnf
and every retry fails the same way. A genuine outage still fails, loudly, after
5 tries.

node-bootc had not built successfully in 24 days. Leaving a kernel roll gated on
a coin flip against EPEL's sync schedule is not acceptable for the one path that
ships CVE-patched kernels.

fix(node-bootc): hc-utils via pkg-cache doubled the eco base and 404'd bd04255c84

Second, distinct node-bootc failure, found once the EPEL retry got the build far
enough to reach it.

pkg-cache convention: nginx re-injects host AND base
(`proxy_pass https://$origin_host$origin_base/$rest`), so the CONSUMER must
strip both. The hetzner eco maps to packages.hetzner.com + base /hcloud/rpm, but
the Containerfile appended /hcloud/rpm itself, so $rest carried it a second time
and nginx proxied to packages.hetzner.com/hcloud/rpm/hcloud/rpm/<rpm>.

Probed, not inferred:
  .../hetzner/hcloud/rpm/hc-utils-0.0.8-1.el10.noarch.rpm  -> 404
  .../hetzner/hc-utils-0.0.8-1.el10.noarch.rpm             -> 200
  https://packages.hetzner.com/hcloud/rpm/<same>           -> 200

This is exactly the almalinux bug fixed in 2a69d28; hetzner was the last
outlier. It stayed latent because node-bootc never actually reached the cache
until the PKG_CACHE-drop in pipeline-build-kernel was fixed — the same
'latent, newly exposed' shape as before.

Only the CACHED form strips the base; the direct fallback keeps the full
upstream path.