Saltar a contenido

Source: Stuck at versions from August 2025, it's now April 2026

Postmortem real: usuario en RPi 4 quedó 8 meses sin poder actualizar (Core 2025.8.3 + HAOS 10.5). El mecanismo de update de la UI no encontraba un upgrade path válido. La solución fue explicit version targeting con el ha CLI (ha os update --version 17.2). Evidencia directa de uno de los failure modes que el wiki necesita catalogar.

Metadatos

  • Tipo: thread del HA community forum.
  • Fecha del thread: 2026-04-10.
  • Hardware del usuario afectado: RPi 4 Model B, 64-bit (aarch64), HAOS install method.
  • Versiones rotas: HA Core/Supervisor 2025.8.3, HAOS 10.5, Frontend 20250811.01.

Por qué entró al wiki

  • Es el primer postmortem real ingerido — evidencia directa del dolor del usuario, no opinión de un blog.
  • Demuestra que la UI de updates puede fallar silenciosamente durante 8 meses sin que el usuario sepa cómo escapar.
  • Valida la importancia del ha CLI con --version como herramienta de recovery (ya documentada en ../entities/ha-cli).
  • Es la primera entrada del catálogo de failure modes que el wiki necesita armar (gap media abierto).

Páginas derivadas

Resumen del contenido

Diagnóstico

Bob (rockandrollforall) reportó 2026-04-10 que su HA estaba bloqueado en versiones de agosto 2025: - HA Core / Supervisor: 2025.8.3 - HAOS: 10.5 - Frontend: 20250811.01

Síntomas: - La UI no muestra updates disponibles (la opción "Show skipped updates" no persiste). - Warning "Unsupported system – Home Assistant OS version". - ha os update desde shell devuelve "Version 10.5 already installed". - Logs: 'StoreManager.reload' blocked from execution, unsupported OS version.

Solución

Spiro (otro user) sugirió explicit version targeting:

ha os update --version 17.2
ha core update --version 2026.4.1

Bob confirmó que ha os update --version 17.2 arrancó (HAOS 10.5 → 17.2). Tras el restart de HA, la UI volvió a mostrar updates disponibles para Core.

Root cause aparente

El mecanismo de update no encontraba un upgrade path válido desde una versión de HAOS demasiado vieja. El gap de 10.5 a la versión actual era demasiado grande para que la UI lo gestionara sola. El forzado con --version saltó la verificación que estaba bloqueando.

Citas textuales

  • "'StoreManager.reload' blocked from execution, unsupported OS version" (error message en logs).

  • "ha os update" → "Version 10.5 already installed" (output del CLI antes del fix).

  • ha os update --version 17.2 / ha core update --version 2026.4.1 (la solución).

Abierto / gaps

  • Por qué la UI no ofreció jamás esa ruta: ¿bug? ¿por diseño? Buscar issue en GitHub que documente la fix.
  • ¿Cuál es la gap máxima de versiones que el mecanismo automático tolera? (Heurística: si HAOS está más de N versiones atrás, hay que forzar.)
  • ¿Hay un healthcheck periódico que detecte "last successful update > X days ago"? No mencionado en docs canónicas — gap.
  • Buscar otros postmortems del mismo failure mode para confirmar que no es un caso aislado.