The Codename That Didn't Exist Yet: An Ubuntu 26.04 Repository Cascade

TL;DR: Every third-party install script — GitLab CE, GitLab Runner, Docker, Wazuh — failed at the same stage, each with a different surface error. All four traced back to one cause: Ubuntu 26.04 ("Resolute") was new enough that no vendor's OS-detection script recognized it yet, and each one failed differently rather than falling back gracefully.

The symptom

GitLab CE's install script failed first, at the "add repository" stage, with a 404. Retrying didn't help — this wasn't a transient mirror issue. The generated /etc/apt/sources.list.d/gitlab_gitlab-ce.list showed why:

deb [signed-by=...] https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/resolute resolute main

There was no resolute component published anywhere on GitLab's package mirror. Their install script had correctly read the host's codename — the codename just didn't exist yet as far as their package repository was concerned.

The pattern, recognized the second time

The same failure mode then showed up for GitLab Runner, Docker, and Wazuh, each with a different-looking symptom: a missing-package error, an unauthenticated-repo warning, an installer that refused to proceed outright. Different vendors, different detection scripts, different failure modes — but the same underlying cause each time, once the pattern was recognized. The first incident took roughly 30 minutes to trace back to the actual mechanism; the second, third, and fourth were each diagnosed and fixed in minutes, purely from recognizing the shape of the problem rather than starting from scratch.

Root cause

None of these install scripts had a graceful fallback for an unrecognized codename — each either errored outright or, worse, silently generated a repository entry pointing at a codename with no actual published packages, producing a confusing downstream error (missing package, GPG failure) instead of a clear "unrecognized OS" message at the point where the real problem actually was.

Fix

Stopped relying on any vendor's OS-detection logic entirely. For every affected service, the repository file was written manually, hardcoding noble (Ubuntu 24.04's codename — the nearest release with actual published packages for all four vendors):

- name: Add Docker apt repository
  copy:
    dest: /etc/apt/sources.list.d/docker.list
    content: |
      deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu noble stable

What this demonstrates

When a brand-new OS release breaks a vendor's install script, the fix is rarely going to land upstream on any useful timeline — every vendor here eventually caught up, but not on a schedule this build could wait for. Hardcoding a known-good fallback codename is a legitimate permanent answer, not just a stopgap, when the alternative is waiting on someone else's release cycle. The more durable lesson is about pattern recognition under time pressure: the real cost of a new-OS-release class of bug isn't the first occurrence, it's failing to recognize the second one as the same problem in different clothes. Once GitLab CE's failure was correctly understood as "vendor doesn't know this OS exists yet" rather than "GitLab's mirror is broken," every subsequent instance of the same pattern got cheap.