Faster init builds: Bootlin external toolchain (x64/arm64) + un-freeze ccache persistence

[mastacontrola]

Why

Every init build in CI currently spends its first ~10+ minutes compiling GCC/binutils/glibc from source (Buildroot "internal toolchain"), and the ccache that's supposed to soften the rest of the build has been frozen since 2026-06-29: actions/cache never re-saves on an exact key hit, and the keys were constants (ccache-x64 etc.), so every run restores the same first-ever cache and throws away its own compile results.

Baseline from the last fully green run (28464611090, 2026-06-30, with that stale ccache restored):

job	duration
build_initrd_x64	31m 15s
build_initrd_arm64	30m 50s
build_initrd_x86	28m 44s

Changes

1. configs/fs{x64,arm64}.config: internal toolchain → Bootlin external toolchain (glibc, bleeding-edge = GCC 15, matching the GCC 15.2 the internal toolchain builds today). The toolchain arrives as a prebuilt tarball into BR2_DL_DIR — which the existing buildroot-dl-* cache already persists — so the entire toolchain-bootstrap stage disappears from every run. Regenerated via olddefconfig with the FOS overlay applied; all six FOG package selections (fog, partclone, chntpw, testdisk, cabextract, partimage) verified retained; BR2_CCACHE settings unchanged.

Bonus: with an external toolchain, Buildroot no longer downloads/installs linux-headers from kernel.org at all (headers ship inside the toolchain tarball) — which would have made these two arches immune to today's kernel.org outage that broke run 28741856230.

2. configs/fsx86.config: unchanged, deliberately. The x86 init targets i486 (BR2_x86_i486=y), and Bootlin's i686 toolchain has depends on !BR2_x86_i486. No prebuilt glibc toolchain exists for i486, so x86 keeps the internal toolchain. (If we ever decide 32-bit can be i686+, this same switch becomes available there.)

3. create_experimental_release.yml: fix the frozen ccache keys — key: ccache-<arch>-${{ github.run_id }} with restore-keys: ccache-<arch>-. Every run now restores the newest cache and saves its own on top, so the x86 build (still compiling its toolchain) and all incremental package compiles actually get warmer over time instead of being stuck at day one.

Expected effect

• x64/arm64: the toolchain build (~10-12 min of the ~31 min job) is replaced by a ~100 MB cached tarball download/extract, and with a working ccache the package compiles shrink further on subsequent runs.
• x86: no toolchain change, but the un-frozen ccache should finally accumulate.

Measurements — pending

No timing numbers yet, deliberately: dispatching this workflow today would create/update the EXP_$(date) prerelease tag and collide with today's kernel-6.18 run's artifacts (the tag is date-based, not branch-based). Plan: dispatch the experimental workflow on this branch (inits only — the workflow inputs allow unchecking the kernels) on a day with no other experimental run, twice back-to-back — first run = cold ccache + toolchain tarball download, second run = everything warm. I'll put both sets of numbers here before marking this ready for review.

Not touched

• create_release.yml / make_usb.yml — neither uses caching today.
• Runtime behavior: same glibc, same GCC major (15), same package set. The init binaries should be functionally identical; still, this wants one real imaging smoke-test before merge.

🤖 Generated with Claude Code