101.2 Lezione 1

Le procedure eseguite dalle macchine x86 per eseguire il bootloader sono diverse se si utilizza BIOS o UEFI. Il BIOS, abbreviazione di Basic Input/Output System, è un programma memorizzato in un chip di memoria non volatile collegato alla scheda madre, eseguito ad ogni accensione del computer. Questo tipo di programma si chiama firmware e la sua posizione di archiviazione è separata dagli altri dispositivi di archiviazione che il sistema potrebbe avere. Il BIOS presuppone che i primi 440 byte nel primo dispositivo di archiviazione - seguendo l’ordine definito nell’utilità di configurazione del BIOS - siano il primo stadio del bootloader (chiamato anche bootstrap). I primi 512 byte di un dispositivo di archiviazione sono denominati MBR (Master Boot Record) dei dispositivi di archiviazione utilizzando lo schema di partizionamento DOS standard e, oltre alla prima fase del bootloader, contiene la tabella delle partizioni. Se l’MBR non contiene i dati corretti, il sistema non sarà in grado di avviarsi, a meno che non venga utilizzato un metodo alternativo.

In generale, i passaggi pre-operativi per l’avvio di un sistema dotato di BIOS sono:

L’UEFI, abbreviazione di Unified Extensible Firmware Interface, differisce dal BIOS in alcuni punti chiave. Come BIOS, l’UEFI è anche un firmware, ma è in grado di identificare le partizioni e leggere molti filesystem in esse contenuti. L’UEFI non si basa sull’MBR, prendendo in considerazione solo le impostazioni memorizzate nella sua memoria non volatile (NVRAM) collegata alla scheda madre. Queste definizioni indicano la posizione dei programmi compatibili UEFI, chiamati EFI applications che verranno eseguiti automaticamente o richiamati da un menu di avvio. Le applicazioni EFI possono essere bootloader, selettori del sistema operativo, strumenti per la diagnostica e la riparazione del sistema, ecc. Devono trovarsi in una partizione del dispositivo di archiviazione convenzionale e in un file system compatibile. I filesystem compatibili standard sono FAT12, FAT16 e FAT32 per dispositivi a blocchi e ISO-9660 per supporti ottici. Questo approccio consente l’implementazione di strumenti molto più sofisticati di quelli possibili con il BIOS

La partizione contenente le applicazioni EFI è chiamata EFI System Partition o solo ESP. Questa partizione non deve essere condivisa con altri filesystem di sistema, come il filesystem di root o i filesystem dei dati utente. La directory EFI nella partizione ESP contiene le applicazioni indicate dalle voci salvate nella NVRAM.

In generale, i passaggi di avvio su un sistema con UEFI sono:

Lo standard UEFI supporta inoltre una funzione chiamata Secure Boot, che consente solo l’esecuzione di applicazioni EFI firmate, ovvero applicazioni EFI autorizzate dal produttore dell’hardware. Questa funzione aumenta la protezione da software dannoso, ma può rendere difficile l’installazione di sistemi operativi non supportati dal produttore.

Il bootloader più popolare per Linux nell’architettura x86 è GRUB (Grand Unified Bootloader). Non appena viene richiamato dal BIOS o dall’UEFI, GRUB visualizza un elenco di sistemi operativi disponibili per l’avvio. A volte l’elenco non appare automaticamente, ma può essere invocato premendo Shift mentre GRUB viene chiamato dal BIOS. Nei sistemi UEFI, si dovrebbe usare invece il tasto Esc.

Dal menu di GRUB è possibile scegliere quale dei kernel installati deve essere caricato e passarvi nuovi parametri. La maggior parte dei parametri del kernel segue il modello option=value. Alcuni dei parametri del kernel più utili sono:

Di solito modificare i parametri del kernel non è necessario, ma può essere utile per rilevare e risolvere problemi relativi al sistema operativo. I parametri del kernel devono essere aggiunti al file /etc/default/grub nella riga GRUB_CMDLINE_LINUX per renderli persistenti durante i riavvii. Un nuovo file di configurazione per il bootloader deve essere generato ogni volta che cambia / etc/default/grub, il che è realizzato dal comando grub-mkconfig -o /boot/grub/grub.cfg. Una volta che il sistema operativo è in esecuzione, i parametri del kernel usati per caricare la sessione corrente sono disponibili per la lettura nel file /proc/cmdline.

Oltre che dal kernel, il sistema operativo dipende da altri componenti che forniscono le funzionalità previste. Molti di questi componenti vengono caricati durante il processo di inizializzazione del sistema, variando da semplici script di shell a programmi di servizio più complessi. Gli script vengono spesso utilizzati per eseguire attività di breve durata che verranno avviate e terminate durante il processo di inizializzazione del sistema. I servizi, noti anche come daemon, possono essere sempre attivi poiché possono essere responsabili di aspetti fondamentali del sistema operativo.

La diversità dei modi in cui gli script di avvio e i daemon con le più svariate caratteristiche possono essere incorporate in una distribuzione Linux è enorme, un fatto che storicamente ha ostacolato lo sviluppo di un’unica soluzione che soddisfi le aspettative dei manutentori e degli utenti di tutte le distribuzioni Linux. Tuttavia, qualsiasi strumento scelto dai manutentori della distribuzione per eseguire questa funzione sarà almeno in grado di avviare, arrestare e riavviare i servizi di sistema. Queste azioni vengono spesso eseguite dal sistema stesso dopo un aggiornamento del software in automatico, ma l’amministratore di sistema invece dovrà quasi sempre riavviare manualmente il servizio dopo aver apportato modifiche al relativo file di configurazione.

È altresì conveniente per un amministratore di sistema essere in grado di attivare, a seconda delle circostanze, un particolare set di demoni. Dovrebbe essere possibile, per esempio, eseguire solo un set minimo di servizi per eseguire attività di manutenzione di sistema.

L’inizializzazione del sistema operativo inizia quando il bootloader carica il kernel nella RAM. Quindi, il kernel prenderà in carico la/le CPU e inizierà a rilevare e configurare gli aspetti fondamentali del sistema operativo, come la configurazione hardware di base e l’indirizzamento della memoria.

Il kernel aprirà quindi l'initramfs (initial RAM filesystem). Initramfs è un archivio contenente un filesystem usato come filesystem root temporaneo durante il processo di avvio. Lo scopo principale di un file initramfs è quello di fornire i moduli richiesti in modo che il kernel possa accedere al filesystem di root “reale” del sistema operativo.

Non appena il filesystem di root è disponibile, il kernel monterà tutti i filesystem configurati in /etc/fstab e quindi eseguirà il primo programma, un’utilità chiamata init. Il programma init è responsabile dell’esecuzione di tutti gli script di inizializzazione e dei demoni di sistema. Esistono implementazioni distinte di tali iniziatori di sistema oltre all'init tradizionale, come systemd e Upstart. Una volta caricato il programma init, initramfs viene rimosso dalla RAM.

Possono verificarsi errori durante il processo di avvio, ma potrebbero non essere così critici da arrestare completamente il sistema operativo. Nonostante ciò, questi errori possono compromettere il comportamento previsto del sistema. Tutti gli errori generano messaggi che possono essere utilizzati per future indagini, in quanto contengono informazioni preziose su quando e come si è verificato un errore. Anche quando non vengono generati messaggi di errore, le informazioni raccolte durante il processo di avvio possono essere utili ai fini della regolazione e della configurazione.

Lo spazio di memoria in cui il kernel memorizza i suoi messaggi, inclusi i messaggi di avvio, è chiamato kernel ring buffer. I messaggi vengono conservati nel buffer di memoria del kernel anche se non mostrati durante il processo di inizializzazione a causa di immagini e/o animazioni che ne impediscono la visione. Tuttavia il buffer di memoria del kernel perde tutti i dati quando il sistema è spento o eseguendo il comando dmesg --clear. Senza opzioni, il comando dmesg mostra i messaggi nel buffer di memoria del kernel corrente:

L’output di dmesg può essere lungo centinaia di righe, quindi la lista precedente contiene solo un piccolo estratto che mostra il kernel che chiama il systemd service manager. I valori all’inizio delle righe sono la quantità di secondi dall’inizio del caricamento del kernel.

Nei sistemi basati su systemd, il comando journalctl mostrerà i messaggi di inizializzazione con le opzioni` -b`, --boot, -k o --dmesg. Il comando journalctl --list-boots mostra un elenco di avvii precedenti a quello corrente, un loro numero di identificazione, data e ora di avvio e primo e ultimo messaggio corrispondente:

I log di inizializzazione precedenti vengono mantenuti anche nei sistemi basati su systemd, quindi è ancora possibile controllare i messaggi delle precedenti sessioni del sistema operativo. Se vengono fornite le opzioni -b 0 o --boot = 0, verranno mostrati i messaggi per l’avvio corrente. Le opzioni -b -1 o --boot = -1 mostreranno i messaggi della precedente inizializzazione. Le opzioni -b -2 o --boot = -2 mostreranno i messaggi dall’inizializzazione prima di quello e così via. Il seguente estratto mostra il kernel che richiama il gestore del servizio systemd nell’ultimo avvio di sistema:

L’inizializzazione e altri messaggi emessi dal sistema operativo sono memorizzati in file all’interno della directory /var/log/. Se si verifica un errore critico e il sistema operativo non è in grado di continuare il processo di inizializzazione dopo aver caricato il kernel e initramfs, è possibile utilizzare un supporto di avvio alternativo per avviare il sistema e accedere al file system corrispondente. Quindi, i file in /var/log/ possono essere controllati per scoprire i motivi che causano l’interruzione del processo di avvio. Le opzioni -D o --directory del comando journalctl possono essere usate per leggere i messaggi di registro in directory diverse da /var/log/journal/ `, che è la posizione predefinita per i messaggi di registro di systemd. Poiché i messaggi di log di systemd non sono memorizzati in formato testo, per leggerli è necessario il comando `journalctl.