Files
computer-playbook/scripts
kevinveenbirkenbachandClaude Opus 5 d0b0b464e7 fix(images): make a dnf retry fetch again instead of replaying its cache
Both image-build jobs of run 37494541850 failed, and only centos broke; arch,
debian, ubuntu and fedora built. The headline reads like an outage:

    Error: Failed to download metadata for repo 'baseos':
      Cannot download repomd.xml ... All mirrors were tried

The line above it says otherwise:

    Errors during downloading metadata for repository 'baseos':
      - Downloading successful, but checksum doesn't match.
        Calculated: 76995e25878232aba76bc22834280007be1baf40...

The download succeeds; the repomd.xml served does not match the checksum the
metalink advertises. The decisive detail is that this digest is byte-identical
on attempts 1, 2 and 3. A real re-fetch reaches a different mirror and yields a
different digest, so attempts 2 and 3 fetched nothing: dnf had written the bad
metadata to /var/cache/dnf and retry only slept and re-invoked the same command
against the same file. Three attempts, one download, and the same for all seven
build attempts.

retry_dnf is retry plus a metadata clean before each re-run, so the next
attempt is a fetch and can land on a mirror that is not mid-sync. All ten dnf
call sites use it, not just the one that failed: the zfs builddep and install
paths carry the identical weakness. apt and pacman keep retry, having no
equivalent cache trap.

The success path is unchanged, so the common case behaves identically. On the
failure path the script runs under set -e, which aborts if the clean itself
returns non-zero: measured, and it fails closed and loud rather than continuing
against a stale cache.

This fixes the retry, not the mirror. If the EL mirrors served stale metadata
for the whole window, three real fetches still fail.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-10-06 19:15:52 +02:00
..

Script Collection

This directory contains automation scripts used across the project.

  • system/ contains host and system-facing helpers.

  • container/ contains helpers that run inside the local container.

  • github/ contains GitHub workflow helper scripts.

  • For the canonical Make target index, see make.md.

  • 🛠️ Organize operational helpers for development, CI, release, and maintenance

  • 🧭 Separate responsibilities into focused subdirectories with clear scope

  • 📚 Keep script-based workflows discoverable and easier to navigate

The scope of this folder is script organization at the repository level. Detailed responsibilities belong in the README files of the respective subdirectories.