Migración de Kirkstone a Scarthgap: La lista de verificación completa

El soporte de Kirkstone 4.0 LTS termina el 27 de abril de 2026. Eso es en semanas.

El próximo LTS, Scarthgap 5.0, está soportado hasta abril de 2028. La migración es inevitable. Pero cuatro versiones se sitúan entre Kirkstone y Scarthgap, cada una con sus propios cambios disruptivos.

Esta guía consolida todos los cambios disruptivos de las cuatro guías de migración oficiales (4.1 Langdale, 4.2 Mickledore, 4.3 Nanbield, 5.0 Scarthgap) en una sola lista de verificación, con ejemplos reales de errores y soluciones.

Por qué migrar a Scarthgap ahora

Cuatro versiones separan Kirkstone de Scarthgap.

Langdale, Mickledore y Nanbield ya están en fin de vida. La migración directa LTS-a-LTS (Kirkstone → Scarthgap) es el camino práctico.

Tres razones para migrar ahora.

1. Los parches de seguridad se detienen

Después del fin de vida, las correcciones de CVE no se retroportarán. Ejecutar un sistema de compilación sin parches en productos embebidos es un riesgo de seguridad.

2. Cumplimiento del CRA de la UE

La Ley de Ciberresiliencia de la UE entra en pleno vigor en diciembre de 2027. La gestión de vulnerabilidades se vuelve obligatoria, pero un sistema de compilación en fin de vida no puede mantener el escaneo de CVE y la generación de SBOM con datos actuales.

3. Soporte del ecosistema

Los proveedores de BSP y las meta-capas de la comunidad centran su atención en el LTS actual. El soporte de Kirkstone disminuirá gradualmente.

Antes de empezar

Configura tu entorno antes de cambiar código.

Registra tu configuración actual de capas

bitbake-layers show-layers

Guarda esta salida. La usarás para verificar que nada se perdió después de la migración.

Verifica el soporte de Scarthgap para cada capa

Busca cada capa en el OpenEmbedded Layer Index, o verifica las ramas remotas directamente.

# Verificar si una capa tiene rama scarthgap
cd meta-custom-bsp
git branch -r | grep scarthgap

Las capas sin rama Scarthgap necesitan ser bifurcadas y portadas, o reemplazadas por alternativas. Si necesitas crear una nueva capa para tus parches personalizados, consulta la guía de creación de capas.

Actualizar LAYERSERIES_COMPAT

Actualiza conf/layer.conf en tus capas personalizadas.

# meta-mylayer/conf/layer.conf
LAYERSERIES_COMPAT_meta-mylayer = "scarthgap"

Sin esto, BitBake se niega a cargar la capa.

Estrategia de ramas Git

Crea una rama de migración para mantener tu compilación de Kirkstone intacta.

git checkout -b migration/scarthgap

Lista de verificación de cambios disruptivos

Cuatro versiones de cambios disruptivos, organizados por impacto. Verifica cada elemento contra tus recetas y configuración.

División del directorio classes (4.1 Langdale)

En Langdale, el directorio classes/ se dividió en tres.

Qué se rompe: Usar INHERIT += con una clase que está en classes-recipe/ causa un error de análisis.

# Esto falla (testimage está en classes-recipe/)
INHERIT += "testimage"

# Correcto
IMAGE_CLASSES += "testimage"

Las clases personalizadas en classes/ siguen funcionando. Sin embargo, moverlas al directorio apropiado es recomendable para compatibilidad futura. Si estás sobreescribiendo clases existentes mediante archivos .bbappend, verifica también la ruta de inherit.

Eliminación de SERIAL_CONSOLE (4.2 Mickledore)

SERIAL_CONSOLE (singular) estaba obsoleto desde la versión 2.6 (Thud, 2018) y fue completamente eliminado en Mickledore.

# Kirkstone (funciona pero obsoleto)
SERIAL_CONSOLE = "115200 ttyS0"

# Scarthgap (obligatorio)
SERIAL_CONSOLES = "115200;ttyS0"

Dos cambios a notar:

• El nombre de la variable ahora es plural (SERIAL_CONSOLES)
• El separador cambió de espacio a punto y coma

Busca en tus archivos de configuración de máquina con grep -r "SERIAL_CONSOLE " y actualiza todas las ocurrencias.

time_t de 64 bits por defecto (4.3 Nanbield)

En plataformas de 32 bits (ej. ARM32), time_t ahora es 64 bits por defecto para abordar el problema de desbordamiento Y2038.

Qué se rompe:

• La compatibilidad ABI se rompe en objetivos de 32 bits
• Los binarios precompilados con time_t de 32 bits no pueden enlazarse
• OLDEST_KERNEL cambió a "5.15" — los kernels anteriores a 5.15 ya no están soportados

Si apuntas a plataformas de 32 bits, verifica que cualquier binario de terceros (bibliotecas precompiladas, etc.) sea compatible con time_t de 64 bits.

Obsolescencia de CVE_CHECK_IGNORE (5.0 Scarthgap)

El mecanismo de exclusión de CVE cambió.

# Kirkstone
CVE_CHECK_IGNORE += "CVE-2024-12345"

# Scarthgap (recomendado)
CVE_STATUS[CVE-2024-12345] = "not-applicable-platform: Only affects Windows"

CVE_CHECK_IGNORE todavía funciona en Scarthgap pero genera advertencias de obsolescencia. El nuevo CVE_STATUS registra la razón de exclusión, haciéndolo apto para auditorías de gestión de SBOM/CVE.

Cambio de compresión ipk (5.0 Scarthgap)

La compresión de paquetes ipk cambió de xz a zstd.

Qué se rompe: Los paquetes ipk compilados con Scarthgap no pueden instalarse en dispositivos que ejecutan Opkg antiguo sin soporte de zstd.

Esto importa si envías actualizaciones OTA desde compilaciones de Scarthgap a dispositivos con firmware antiguo. O bien actualiza Opkg en el dispositivo a una versión con soporte de zstd, o configura la compilación para usar compresión xz.

Otras eliminaciones y renombramientos de variables

Errores comunes de migración y soluciones

Errores reales que encontrarás durante la migración y cómo resolverlos.

Error de compatibilidad de capa

ERROR: Layer 'meta-custom' is not compatible with the current set of layers

LAYERSERIES_COMPAT no incluye scarthgap. Corrige conf/layer.conf.

# meta-custom/conf/layer.conf
LAYERSERIES_COMPAT_meta-custom = "scarthgap"

Para más técnicas de depuración de errores, consulta la guía de depuración de errores de compilación.

Clase no encontrada

ERROR: ParseError: Could not inherit file classes/testimage.bbclass

La división del directorio classes en la versión 4.1 movió las clases solo para recetas fuera de la ruta de búsqueda predeterminada para INHERIT +=. Cambia a IMAGE_CLASSES o inherit según corresponda.

Error de sintaxis SERIAL_CONSOLE

ERROR: Variable SERIAL_CONSOLE is no longer supported

Reemplaza con SERIAL_CONSOLES (plural) y cambia el separador a punto y coma.

Fallos de compilación por time_t

En objetivos de 32 bits, enlazar contra bibliotecas de terceros puede producir errores de discrepancia de tamaño.

error: size of 'timestamp' changed to 8 bytes (was 4)

Soluciones:

1. Recompila la biblioteca dentro del entorno Scarthgap
2. Como último recurso, establece TIME_T_BITS = "32" a nivel de receta (no recomendado)

Fallo de instalación ipk

opkg install: Unknown compression type 'zstd'

Esto ocurre al desplegar paquetes ipk compilados con Scarthgap en dispositivos más antiguos. La solución recomendada es actualizar Opkg en el dispositivo a una versión con soporte de zstd.

Funcionalidades de Scarthgap que vale la pena usar

Mientras migras, aprovecha lo que Scarthgap ofrece.

Generación de SBOM habilitada por defecto

Scarthgap incluye create-spdx en la configuración predeterminada de Poky. Cada compilación genera automáticamente SBOMs en formato SPDX.

El cumplimiento del CRA de la UE para la generación de SBOM viene sin esfuerzo adicional. Consulta la guía de gestión de SBOM/CVE para flujos de trabajo de producción.

Control de compilación basado en presión

# conf/local.conf
BB_PRESSURE_MAX_CPU = "150"
BB_PRESSURE_MAX_IO = "80"
BB_PRESSURE_MAX_MEMORY = "50"

Usa /proc/pressure/ de Linux para ajustar dinámicamente el paralelismo de tareas de BitBake basado en la presión de CPU, E/S y memoria en tiempo real. Más flexible que valores fijos de BB_NUMBER_THREADS. Consulta la guía de optimización de velocidad de compilación para más detalles.

CVE_STATUS_GROUPS

Agrupa exclusiones de CVE por razón para una gestión más fácil.

# conf/local.conf
CVE_STATUS_GROUPS = "CVE_STATUS_WIN"
CVE_STATUS_WIN = "CVE-2024-11111 CVE-2024-22222"
CVE_STATUS_WIN[status] = "not-applicable-platform: Windows-only"

Mucho más limpio que entradas individuales de CVE_STATUS cuando tienes docenas de exclusiones.

Preguntas frecuentes

¿Puedo saltar las versiones intermedias e ir directo de Kirkstone a Scarthgap?

Sí. La migración directa LTS-a-LTS es el enfoque recomendado. Langdale, Mickledore y Nanbield ya están en fin de vida, así que no hay beneficio en pasar por ellas. Simplemente aplica todos los cambios disruptivos de las cuatro versiones a la vez usando esta lista de verificación.

¿Cuánto tiempo toma una migración típica de Kirkstone a Scarthgap?

Depende del número de capas personalizadas y dependencias de terceros. Un proyecto con 2-3 capas personalizadas y soporte BSP estándar normalmente toma de unos días a una semana. Proyectos con muchas recetas personalizadas, binarios precompilados u objetivos de 32 bits (cambios ABI de time_t) pueden tomar más.

¿Qué pasa si sigo usando Kirkstone después de abril de 2026?

No más parches de seguridad del Yocto Project. Las correcciones de CVE no se retroportarán, y las meta-capas de la comunidad dejarán de mantener ramas de Kirkstone. Serías responsable de todos los parches de seguridad por tu cuenta.

¿Necesito actualizar mi capa BSP por separado?

Sí. Tu proveedor de BSP (ej. NXP, TI, Raspberry Pi Foundation) necesita proporcionar una rama compatible con Scarthgap. Verifica en el OpenEmbedded Layer Index o en el repositorio del proveedor. Si no existe una rama Scarthgap, contacta al proveedor o bifurca la capa BSP y pórtala tú mismo.

¿Funcionará mi sstate-cache existente después de la migración?

No. El sstate-cache de Kirkstone no es compatible con Scarthgap. Necesitarás una recompilación completa. La primera compilación tomará tanto como una compilación limpia, pero las siguientes poblarán el nuevo sstate-cache.

¿El cambio de time_t de 64 bits es relevante si solo apunto a plataformas de 64 bits?

No. El cambio de time_t de 64 bits solo afecta a objetivos de 32 bits (ARM32, MIPS32, etc.). En plataformas de 64 bits, time_t siempre ha sido de 64 bits, así que el cambio Y2038 no tiene impacto.

¿Debería habilitar cve-check durante la migración o después?

Durante. Scarthgap tiene create-spdx habilitado por defecto, y agregar cve-check durante la migración significa que empiezas con una línea base de vulnerabilidades limpia. Esperar hasta después de la migración implica auditar retroactivamente tu compilación.

Conclusión

La migración de Kirkstone a Scarthgap abarca cuatro versiones de cambios, pero los elementos de alto impacto son manejables.

El flujo de trabajo de migración:

1. Verificar disponibilidad de la rama Scarthgap para todas las capas
2. Actualizar LAYERSERIES_COMPAT
3. Recorrer la lista de verificación con grep -r
4. Compilar → corregir errores → repetir
5. Habilitar cve-check e iniciar la gestión de vulnerabilidades

El fin de vida de Kirkstone es inminente. Usa esta lista de verificación para tomar el camino más corto hacia Scarthgap.

Artículos relacionados:

• Primeros pasos con Yocto: Compila tu primera imagen Linux
• Errores de compilación en Yocto: Guía de depuración por tarea
• Raspberry Pi 5 con Yocto Scarthgap: Guía práctica
• SBOM y gestión de CVE en Yocto: Guía práctica para Scarthgap
• Inicio automático con systemd en Yocto: Guía con 7 errores comunes
• Guía de creación de capas en Yocto
• Actualización OTA en Yocto: Comparación de SWUpdate, RAUC y Mender