La llegada de fwupd 2.0.19 puede parecer, a simple vista, una actualización menor, pero en realidad encaja dentro de un panorama bastante más amplio de cambios en el ecosistema Linux: cambios en servicios críticos y algún que otro quebradero de cabeza con actualizaciones de paquetes. Si usas Linux en el día a día, tanto en equipos personales como en entornos profesionales, te interesa tener claro qué aporta esta versión y qué está pasando alrededor.

A lo largo de este artículo vamos a ver en detalle qué novedades introduce fwupd 2.0.19 y qué problemas resuelve. Todo ello explicado con un lenguaje lo más claro posible, pero sin escatimar en detalles técnicos para quien quiera profundizar un poco más.

Novedades principales de fwupd 2.0.19

La nueva versión fwupd 2.0.19, desarrollada por Richard Hughes, se presenta como la decimonovena actualización de mantenimiento de la rama 2.0 de este conocido servicio de actualización de firmware en Linux, tras entregas como fwupd 2.0.16. Aunque no es una versión “rompedora”, incorpora cambios muy concretos que mejoran compatibilidad, seguridad y fiabilidad en distintos tipos de hardware.

En esta edición se añade soporte específico para actualizar el firmware del teclado Lenovo Sapphire Folio, un periférico que hasta ahora no estaba cubierto por fwupd. Esto es importante porque muchos dispositivos modernos dependen de firmware propietario y disponer de una vía centralizada, estándar y abierta para mantenerlos al día reduce riesgos de seguridad y problemas de compatibilidad, especialmente en portátiles y equipos híbridos.

Otra adición clave es la inclusión de dos nuevos subcomandos en la herramienta fwupdtool orientados al trabajo con CRC (Cyclic Redundancy Check). Estos nuevos comandos permiten calcular y localizar CRCs, facilitando la verificación de integridad de imágenes y datos asociados al firmware. Para administradores y desarrolladores, esto supone una forma más directa de diagnosticar corrupciones o manipulaciones en binarios relacionados con actualizaciones.

Un cambio muy relevante a nivel de integración del sistema es que fwupd 2.0.19 ahora permite que los sistemas empleen la fuente de eventos udev sin depender de systemd. Esto abre la puerta a un uso más flexible en entornos que no emplean systemd como PID 1, o en configuraciones más minimalistas donde se quiere tener fwupd sin asumir todas las dependencias habituales de una distribución mainstream.

Mejoras en comandos y flujo de actualización

Dentro de las mejoras de usabilidad, la nueva versión revisa el comportamiento del comando fwupdmgr get-history. A partir de fwupd 2.0.19, el historial de actualizaciones de firmware mostrará siempre de forma correcta la versión nueva que se ha instalado, evitando confusiones a la hora de auditar qué se ha actualizado, cuándo y a qué versión concreta.

Además, el equipo de desarrollo ha ajustado la lógica interna para que se respete de manera adecuada el parámetro –force de fwupdmgr cuando se instalan firmwares. Esto garantiza que, en situaciones donde el usuario o el administrador decide forzar una actualización (por ejemplo, ante un downgrade o un firmware con metadatos problemáticos), la herramienta actúe conforme a esa orden de forma consistente.

En el apartado de hardware gráfico, se han incluido mejoras específicas en el proceso de actualización de la sección FWDATA de las GPU de Intel. Esta zona de datos asociada al firmware puede ser crítica para el rendimiento y la estabilidad del subsistema gráfico, de modo que una actualización más robusta ayuda a reducir posibles fallos en equipos que dependen de las integradas o de GPUs Intel dedicadas.

Corrección de fallos y mejoras de seguridad en fwupd 2.0.19

Más allá de las nuevas funciones, una parte importante de esta versión se centra en la corrección de errores que afectaban a la estabilidad y seguridad de fwupd. Entre los problemas resueltos destaca un underflow de entero que podía producirse al analizar un archivo PE malicioso. Aunque no se describe un exploit concreto, este tipo de fallos son especialmente sensibles porque pueden derivar en comportamientos indefinidos o en vectores de ataque si se explotan adecuadamente.

También se aborda una regresión que se producía al enumerar el componente de estado de ciertos docks de Dell. Este bug podía provocar que la información de estado de la base no se mostrara correctamente o que se dieran errores al intentar gestionar su firmware. La corrección devuelve la funcionalidad normal a quienes dependan de estos docks para estaciones de trabajo más complejas.

Otro de los problemas corregidos afecta al sistema de fuzzing empleado para mejorar la robustez del análisis de contenedores de firmware. En concreto, se solucionan los tiempos de espera excesivos al procesar contenedores Synaptics-RMI SBL. Reducir estos bloqueos y cuelgues es clave para seguir encontrando errores de forma automática sin que las herramientas se queden “atascadas” con determinados formatos de firmware.

Para detalles finos, el proyecto mantiene sus notas de lanzamiento en GitHub, donde se pueden consultar todos los cambios, commits y discusión asociada a fwupd 2.0.19. Desde allí también se puede descargar el código fuente en forma de tarball, aunque en la mayoría de los casos lo más sensato es instalar o actualizar fwupd directamente desde los repositorios estables de cada distribución, aprovechando el empaquetado y las pruebas que realizan los mantenedores.

Actualizaciones delicadas en Arch Linux: .NET 9.0 a 10.0

En paralelo a estas novedades de firmware, el ecosistema Linux también se está moviendo en otras capas. En el caso de Arch Linux, la actualización de la pila .NET desde la versión 9.0 a la 10.0 está causando algunos escenarios que requieren intervención manual. Paquetes como aspnet-runtime, aspnet-targeting-pack, dotnet-runtime, dotnet-sdk, dotnet-source-built-artifacts y dotnet-targeting-pack pueden verse afectados.

Durante la actualización, pacman puede mostrar el error «failed to prepare transaction (could not satisfy dependencies)» para estos paquetes. Esto suele ocurrir cuando hay dependencias cruzadas entre las versiones 9.0 y 10.0 y el sistema no consigue resolver correctamente qué debe instalarse o eliminarse primero.

Conflictos de archivos sin propietario en Waydroid

Otro caso curioso en Arch Linux afecta al paquete waydroid. Las versiones anteriores a la 1.5.4-2 (incluida la variante de AUR) generaban en tiempo de ejecución archivos de bytecode de Python (.pyc) que no quedaban registrados por pacman, al crearse dinámicamente cuando se ejecutaban los scripts.

Con la versión 1.5.4-3 se ha corregido este comportamiento y ahora la compilación de estos .pyc se realiza en el propio proceso de empaquetado, por lo que ya están controlados por el gestor de paquetes. El problema es que, durante la actualización, esos ficheros antiguos sin propietario pueden chocar con los nuevos ficheros que sí están bajo control de pacman.

Si te aparece un mensaje del estilo «error: failed to commit transaction (conflicting files)» con rutas como /usr/lib/waydroid/tools/__pycache__/__init__.cpython-313.pyc o similares, se trata precisamente de ese conflicto entre archivos generados previamente y los nuevos archivos empaquetados.

En este escenario, puedes sobrescribir esos ficheros con seguridad, ya que el contenido nuevo es el mismo tipo de archivo pero gestionado correctamente por el gestor de paquetes. El objetivo de este cambio es que futuras actualizaciones no vuelvan a tropezar con ficheros “huérfanos” en el sistema de archivos.

Cambios importantes en Dovecot 2.4 y migración de configuración

La rama 2.4 de Dovecot, muy utilizada como servidor IMAP/POP3 en numerosos entornos, introduce cambios incompatibles con los archivos de configuración de versiones anteriores o iguales a la 2.3. Esto implica que, tras la actualización, el servicio no podrá arrancar hasta que la configuración haya sido migrada y adaptada al nuevo formato y a los nuevos parámetros.

Para realizar esta transición, los desarrolladores de Dovecot proporcionan documentación oficial de migración de 2.3 a 2.4, donde se detallan los ajustes que hay que aplicar en los ficheros de configuración, qué opciones se han modificado y qué directivas han desaparecido o han cambiado de comportamiento.

Además, la rama 2.4 elimina la funcionalidad de replicación que estaba disponible en versiones anteriores. Para quienes dependen de esta característica —típicamente en escenarios de alta disponibilidad o redundancia entre servidores de correo—, esto es un cambio muy relevante. En algunos repositorios se están dando alternativas para usuarios que necesitan seguir usando la replicación o que no pueden migrar aún a 2.4, por ejemplo manteniendo ramas anteriores o proporcionando paquetes específicos.

fwupd 2.0.19 unifica lascuentas de sistema en Zabbix

Otro cambio relevante en el ecosistema de paquetes es el que afecta a Zabbix en Arch Linux a partir de la versión 7.4.1-2. Hasta ahora, distintos componentes de Zabbix (zabbix-server, zabbix-proxy, zabbix-agent —compartido también por zabbix-agent2— y zabbix-web-service) utilizaban cuentas de sistema diferenciadas, cada una emparejada con su paquete correspondiente.

A partir de esta versión, todas estas piezas pasan a utilizar una única cuenta de sistema compartida llamada «zabbix», en línea con lo que recomienda el propio proyecto upstream y lo que hacen otras distribuciones. Esta cuenta unificada la proporciona un nuevo paquete dividido (split package) llamado zabbix-common, que se convierte en dependencia para todos los paquetes zabbix-* relevantes.

El cambio está diseñado para que la migración a la nueva cuenta sea automática durante la actualización de paquetes, sin que el administrador tenga que intervenir manualmente. Aun así, siempre es recomendable revisar permisos, archivos de configuración y servicios tras cambios de este tipo, sobre todo en entornos de producción donde se gestionan muchos hosts y agentes.

Todo este movimiento —fwupd 2.0.19 reforzando las actualizaciones de firmware, las distribuciones como Fedora 41 y Ubuntu 24.04.1 consolidando sus stacks, y los cambios de paquetes y servicios críticos en Arch Linux— muestra cómo el ecosistema Linux evoluciona a varias capas a la vez: desde el firmware de un teclado Lenovo o una GPU Intel hasta la forma de gestionar paquetes con DNF5, integrar Active Directory en Ubuntu o mantener un servidor de correo Dovecot sin sobresaltos. Mantenerse al día ya no es solo una cuestión de instalar la última ISO, sino de entender cómo cada una de estas piezas encaja en tu sistema y en tu forma de trabajar.