Desde Linux Darkcrizt  

Systemd tendrá soporte para el arranque desde imágenes remotas

systemd

Hace pocos días, Lennart Poettering (creador y desarrollador de systemd) presento una nueva propuesta para el administrador de sistemas systemd, con la intención de mejorar la flexibilidad y en el arranque en Linux.

Sobre la propuesta, se menciona que busca permitir que un sistema pueda iniciar directamente desde una imagen del sistema de archivos raíz descargada desde un host externo a través de HTTP. Con ello, se busca que esta funcionalidad ayude a ampliar las capacidades actuales de systemd, facilitando escenarios como pruebas de sistemas inmutables y despliegues rápidos en entornos de red.

¿En qué consiste el arranque remoto en systemd?

El cambio propuesto se basa en extender systemd para que, en la fase inicial del arranque, sea capaz de:

  • Descargar una imagen de disco vía HTTP.
  • Descomprimir la imagen obtenida.
  • Asociarla a un dispositivo de bloque en modo loopback.
  • Montar el dispositivo de bloque en /sysroot.
  • Continuar el arranque del sistema desde esa imagen.

Estado actual del desarrollo

Actualmente, systemd en su versión 257 ya incorpora soporte para descargar imágenes de disco en la fase de arranque mediante el módulo systemd-import-generator. Sin embargo, la funcionalidad completa aún se encuentra en una etapa de prototipo funcional, y todavía no es capaz de completar el ciclo completo de arranque.

Post by @pid_eins@mastodon.social
View on Mastodon

Entre los planes a futuro, se contempla ampliar la compatibilidad para que esta funcionalidad pueda trabajar en conjunto con imágenes de kernel universales UKI (Unified Kernel Image). Estas imágenes combinan, en un solo archivo:

  • Un gestor de arranque UEFI (UEFI boot stub).
  • Una imagen del kernel de Linux.
  • Un entorno de sistema initrd precargado en la memoria.
    Implementación y Flujo de Trabajo

La propuesta sugiere que la URL de la imagen del sistema se genere automáticamente a partir de la URL especificada en la configuración de arranque HTTP de UEFI, ya con ello, el controlador initrd de UKI buscaría automáticamente la imagen del sistema.

Además del protocolo HTTP, se planea incorporar compatibilidad con NVMe-over-TCP, una tecnología que permite el acceso remoto a unidades NVMe a través de redes, utilizando el protocolo NVM Express over Fabrics sobre TCP. Esto facilitaría entornos donde se requiere alta velocidad de acceso a los datos sin depender exclusivamente de discos locales.

Esto extiende systemd-import-generator no solo para descargar una imagen de disco en el arranque, sino también para adjuntarla a un dispositivo de bucle invertido, de modo que podamos arrancar desde él.

Ya tenemos la mayoría de las piezas en su lugar, esto solo pulir algunas cosas, para hacer esta ronda…

Este es un proyecto en proceso, ya que le falta documentación y quiero pulirlo un poco más, pero funciona muy bien. El objetivo final es proporcionar una solución completa para que también podamos realizar el arranque UEFI http para ukis.

Este nuevo método de arranque podría simplificar y mejorar varios escenarios, como por ejemplo pruebas de sistemas operativos inmutables en hardware real. Un desarrollador podría generar una imagen de su sistema utilizando mkosi y compartirla rápidamente mediante HTTP con el comando «mkosi -f serve». En la máquina de pruebas, bastaría con activar el arranque HTTP en EFI y proporcionar la URL de la imagen.

Una vez configurado el sistema para arrancar desde una imagen remota, el proceso es simple: basta con reiniciar la computadora, y esta cargará automáticamente la imagen de kernel UKI estándar. A partir de ahí, el kernel descargará la imagen del sistema de archivos raíz previamente preparada por el desarrollador y procederá con el arranque normal.

Un aspecto clave de esta propuesta, es que el arranque HTTP en EFI permanece activo hasta que se deshabilite manualmente. Esto significa que, en cada reinicio posterior, el sistema descargará y ejecutará la última versión disponible de la imagen remota, permitiendo realizar pruebas continuas sin intervención adicional.

Dado que todo el proceso ocurre en memoria y no requiere modificar los discos locales, esta técnica representa una forma segura y eficiente de evaluar diferentes versiones de un sistema sin riesgo de afectar la configuración o los datos almacenados en la máquina.

Finalmente, si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

Leave A Comment

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.