Saltar a contenido

Failure mode: hardware support cutoff

Segunda entrada del catálogo de failure modes. Cuando HAOS deja de soportar una arquitectura o un perfil de hardware en una versión nueva, aplicar el upgrade convierte el sistema en algo inutilizable. La protección principal es conocer el hardware support matrix antes del upgrade; la recuperación es restore + permanecer en la última versión soportada o cambiar de hardware.

Contexto

A diferencia del primer failure mode catalogado (la UI no ofrece upgrade path), este modo es el opuesto: el sistema sí aplica el upgrade, pero el resultado no funciona porque la nueva versión retiró soporte para tu hardware. El usuario se entera post-mortem.

Esta entrada todavía es provisional — la afirmación del cutoff específico (generic-x86-64 = 2026.4.1) no está confirmada con source oficial. Promover a "confirmado" cuando se valide contra docs.

Contenido

Cómo se manifiesta

  • HA aplica el upgrade aparentemente sin error.
  • Post-restart, el sistema no arranca o falla de manera severa (servicios core no inician, UI no responde, etc.).
  • No hay error message obvio que diga "tu hardware ya no es soportado" — el usuario tiene que inferirlo.
  • El restore desde backup pre-upgrade funciona, lo que confirma indirectamente que el upgrade en sí fue el causante.

Caso documentado

Cómo se detecta proactivamente

Pre-upgrade, no post-mortem.

  1. Consultar hardware support matrix oficial antes de cada upgrade. HA debería publicar una matriz de "arquitectura/hardware → última versión soportada".
  2. Suscribirse a deprecation announcements (similares a ../sources/ha-deprecating-core-supervised-2025-05 pero para hardware).
  3. Agente / script de pre-upgrade que cruza tu hardware actual contra el hardware support matrix de la versión target. Parte del ../concepts/ha-pre-update-checklist (paso 0 propuesto: "validar hardware support").

Cómo se recupera

  1. Restore desde backup pre-upgrade. Funcionó en el caso documentado.
  2. Decidir entre dos opciones:
  3. Permanecer en la última versión soportada del hardware actual, asumiendo el costo de seguridad / features perdidas.
  4. Cambiar de hardware a uno todavía supported (HA Green, HA Yellow mientras tenga updates, RPi 5, mini-PC compatible).
  5. Si se decide cambiar de hardware: backup → restore en el nuevo hardware (HA Backup es cross-architecture según ../sources/ha-deprecating-core-supervised-2025-05).

Cómo se previene

  • Antes del upgrade: validar hardware contra matriz oficial. Aplica especialmente a setups que llevan años con el mismo box.
  • Monitorear anuncios de deprecation de architectures (HA hizo uno explícito en 2025-05 para 32-bit).
  • Capacidad reservada en el setup: tener un plan de migración a hardware más nuevo si tu hardware actual está cerca del cutoff esperado (heurística: si tu CPU tiene > 10 años, asumí que algún cutoff te va a pegar).

Contraste con el primer failure mode

Dimensión failure-mode-stuck-haos-update-mechanism failure-mode-hardware-support-cutoff
Detección UI no ofrece upgrades Upgrade aparenta éxito; sistema queda roto
Recovery Forzar versión vía ha os update --version Restore desde backup
Causa Gap demasiado grande HAOS vs latest Versión target retiró soporte de tu arquitectura
Quién tiene que actuar El usuario fuerza con CLI El usuario revierte y luego elige: stay vs migrar hardware
Prevención Aplicar updates puntualmente Validar hardware support matrix pre-upgrade

Relaciones

Citas / evidencia

Abierto / gaps

  • Confirmar o desmentir el cutoff generic-x86-64 = 2026.4.1 contra docs oficiales o changelog.
  • Construir página analysis/ha-hardware-support-matrix-2026.md con el listado completo de arquitecturas y sus cutoffs declarados.
  • Buscar el equivalente al anuncio de 2025-05 (deprecación de install methods) pero para hardware — ¿existe uno por arquitectura?
  • Validar que el HA Yellow (hardware del usuario) no esté cerca de un cutoff anunciado.