[alert] FluxImageAutomationNotReady (cluster) #1527

Closed
opened 2026-10-29 21:21:49 +00:00 by hermes-bot · 1 comment
Member

What is firing: FluxImageAutomationNotReady (warning), flux-system ImageRepository/lidarr, Ready=False since 2026-10-29T18:56:20Z (alert since 20:56Z). Only lidarr is affected; all other ghcr.io ImageRepositories are Ready.

Evidence

  • kubectl -n flux-system get imagerepository lidarr -o yaml: scan failed: GET https://ghcr.io/v2/linuxserver/lidarr/tags/list?n=1000: UNAUTHORIZED: authentication required; last successful scan 2026-10-29T17:56:04Z (9419 tags). Repeats every 15 min in kubectl -n flux-system logs deploy/image-reflector-controller.
  • Spec: image: lscr.io/linuxserver/lidarr, provider: generic, no secretRef. It is the only ImageRepository on lscr.io.
  • Probe from the hermes pod: GET https://lscr.io/v2/linuxserver/lidarr/tags/list?n=1000 with a valid anonymous ghcr bearer token returns 302 -> https://ghcr.io/v2/linuxserver/lidarr/tags/list?n=1000.
  • The same call directly against ghcr.io with an anonymous token (https://ghcr.io/token?scope=repository:linuxserver/lidarr:pull) returns 200 and paginates all 10 pages / 9419 tags. ghcr anonymous access works; the failure is specific to going through lscr.io.
  • ImagePolicy lidarr is still Ready (3.1.6.5079-ls46 from the cached scan), so the deployment is not broken, only frozen.

Root cause: Verified: lscr.io 302-redirects the tag-list call to ghcr.io, and ghcr.io works anonymously. Hypothesis: the reflector's registry client drops the bearer token on the cross-host redirect, so ghcr.io sees an unauthenticated request. Pointing the ImageRepository at ghcr.io directly and checking that it goes Ready settles it.

Where to fix it: kubernetes/infrastructure/image-automation/lidarr.yaml: set spec.image: ghcr.io/linuxserver/lidarr (same image; lscr.io is LinuxServer's redirector to ghcr). Change the two $imagepolicy-marked image refs in kubernetes/apps/navidrome/lidarr.yaml (about lines 96 and 143) to ghcr.io/linuxserver/lidarr:... to match.


Filed automatically by the Hermes alert-monitor job (2026-10-29) for the apollo expert, whose kanban card takes it to a fix PR.

**What is firing**: FluxImageAutomationNotReady (warning), flux-system ImageRepository/lidarr, Ready=False since 2026-10-29T18:56:20Z (alert since 20:56Z). Only lidarr is affected; all other ghcr.io ImageRepositories are Ready. **Evidence** - `kubectl -n flux-system get imagerepository lidarr -o yaml`: `scan failed: GET https://ghcr.io/v2/linuxserver/lidarr/tags/list?n=1000: UNAUTHORIZED: authentication required`; last successful scan 2026-10-29T17:56:04Z (9419 tags). Repeats every 15 min in `kubectl -n flux-system logs deploy/image-reflector-controller`. - Spec: `image: lscr.io/linuxserver/lidarr`, `provider: generic`, no secretRef. It is the only ImageRepository on lscr.io. - Probe from the hermes pod: `GET https://lscr.io/v2/linuxserver/lidarr/tags/list?n=1000` with a valid anonymous ghcr bearer token returns **302 -> https://ghcr.io/v2/linuxserver/lidarr/tags/list?n=1000**. - The same call directly against ghcr.io with an anonymous token (`https://ghcr.io/token?scope=repository:linuxserver/lidarr:pull`) returns 200 and paginates all 10 pages / 9419 tags. ghcr anonymous access works; the failure is specific to going through lscr.io. - ImagePolicy lidarr is still Ready (3.1.6.5079-ls46 from the cached scan), so the deployment is not broken, only frozen. **Root cause**: Verified: lscr.io 302-redirects the tag-list call to ghcr.io, and ghcr.io works anonymously. Hypothesis: the reflector's registry client drops the bearer token on the cross-host redirect, so ghcr.io sees an unauthenticated request. Pointing the ImageRepository at ghcr.io directly and checking that it goes Ready settles it. **Where to fix it**: `kubernetes/infrastructure/image-automation/lidarr.yaml`: set `spec.image: ghcr.io/linuxserver/lidarr` (same image; lscr.io is LinuxServer's redirector to ghcr). Change the two `$imagepolicy`-marked image refs in `kubernetes/apps/navidrome/lidarr.yaml` (about lines 96 and 143) to `ghcr.io/linuxserver/lidarr:...` to match. --- <!-- alert-monitor:fingerprint=20156f16d88c9a85 --> _Filed automatically by the Hermes alert-monitor job (2026-10-29) for the `apollo` expert, whose kanban card takes it to a fix PR._
hermes-bot added the apollo label 2026-10-29 21:21:49 +00:00
Author
Member

Hermes kanban card t_894a66a0 for this issue is assigned to apollo.

Hermes kanban card `t_894a66a0` for this issue is assigned to apollo. <!-- hermes-kanban-card:t_894a66a0 -->
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: konairius/homelab#1527