Abbiamo raccontato da poco di systemd-homed (e della difficoltà nel trovarne un senso) e nella chiusura dello stesso articolo abbiamo nominato systemd-boot (che scriveremo in seguito sd-boot). Ora è il momento di raccontarvene di più.

Durante “All Systems Go” – la stessa conferenza in cui annunciava systemd-homed – Lennart Poettering ha presentato lo stato di sviluppo di questo boot loader, presentando anche il Boot Loader Specification (BLS – specifiche per i boot loader). Qui trovate il video dell’intervento.

BLS è una serie di specifiche per rendere standard la definizione dei sistemi operativi da poter caricare, indipendente dal boot loader usato, slegando il particolare boot loader usato dalla sua particolare configurazione.

sd-boot è un’implementazione di boot loader che supporta BLS.
Come di sovente per systemd, sd-boot è solo un suo componente: presente di default, non è necessaria al suo funzionamento. Nasce da un altro progetto, gummiboot, che voleva porsi come alternativa minimale a GRUB ed invece è stato poi integrato nel progetto systemd (come successo con dbus, per esempio), circa 4 anni fa. Di fatto, il compito principale di sd-boot è creare un menù per la scelta all’avvio del OS, usando systemd per l’avvio di Linux o lasciare il controllo ad un altro boot loader, magari quello specifico di un (altro) sistema operativo.

Chi usa (o ha usato) sistemi dual boot, in particolare Windows/Linux, sa bene che l’uso di GRUB (o LILO, ai tempi) è essenziale per poter avviare Linux e lasciare che anche Windows lo sia. L’uso del solo bootldr (il boot loader di Windows), nella migliore delle ipotesi, riesce ad avviare solo Windows, ma negli altri casi rende inutilizzabile il sistema.
BLS descrive la presenza e l’uso di una partizione dedicata (che può essere la ESP di EFI), nonché la struttura delle directory; singoli file di testo o binari (magari firmati) EFI possono descrivere/permettere un OS da avviare.

Se per quanto riguarda BLS non ci sono dubbi che sia necessario, continuiamo ad avere più incertezze per sd-boot: perché un sistema di init possa (o debba) occuparsi anche del boot della macchina ci rimane oscuro. Soprattutto in considerazione del fatto che GRUB è da qualche tempo capace di usare BLS.
D’altro canto l’uso di (e l’integrazione in) un solo strumento di varie funzioni ha dei vantaggi:

• Sintassi simili per operazioni diverse: come (oramai) systemctl, timedatectl e hostnamectl permettono di gestire vari aspetti sistemistici con sintassi simili, esiste anche bootctl per gestire BLS – e sd-boot;
• Semplificazione dell’installazione: in sistemi con solo Linux – come moltissimi server – sd-boot è sufficiente, e permette di dover gestire un software in meno;
• Metriche disponibili: systemd-analyze fornisce indicazioni sul tempo impiegato al boot per avviare le varie componenti, ma ha visibilità solo dopo l’avvio del Kernel. sd-boot permetterebbe di avere statistiche anche della prima fase, quella di caricamento del boot loader.

A nostro parere, i vantaggi non sono così determinanti. Ma il semplice fatto di avere un’alternativa ci rende (come sempre) felici… Anche se si tratta di systemd!

Marco Bonfiglio

Ho coltivato la mia passione per l’informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.