Funzionamento del sistema

18 / 100
()

All’accensione del computer viene eseguito il programma del BIOS; questo dopo aver fatto i suoi controlli interni esegue la procedura di avvio del sistema.

Nei PC tutto ciò viene effettuato caricando dal dispositivo indicato nelle impostazioni del BIOS un apposito programma, il bootloader, che a sua volta recupera (in genere dal disco) una immagine del kernel che viene caricata in memoria ed eseguita.

Una volta che il controllo e passato al kernel, questo, terminata la fase di inizializzazione in cui ad esempio si esegue una scansione delle periferiche disponibili, e si leggono le tabelle delle partizioni dei vari dischi si incaricherà di montare il filesystem su cui e situata la directory radice e far partire il primo processo. Tradizionalmente questo processo si chiama init, ed è il programma di inizializzazione che a sua volta si cura di far partire tutti gli altri processi che permettono di usare il sistema. Fra questi processi ci saranno ad esempio quelli che forniscono i vari servizi di rete, quelli che eseguono vari compiti di amministrazione, cosi come quelli che si occupano di chiedere nome e password dell’utente che si vuole collegare. Tutti i programmi funzionano allo stesso modo: vengono eseguiti dal kernel come processi ed eseguono le loro operazioni attraverso le opportune system call che esso mette a disposizione.

Tutte le operazioni di normale amministrazione di un sistema GNU/Linux sono sempre realizzate tramite degli opportuni programmi. Tutto ciò ci dice anche che,il kernel, benchè esso costituisca il cuore del sistema, da solo sarebbe assolutamente inutile, cosi come sarebbe inutile da solo il motore di una automobile, senza avere le ruote, lo sterzo, la carrozzeria, e tutto il resto.Per avere un sistema funzionante dal punto di vista di un utente normale infatti occorre avere, oltre al kernel, anche tutti i programmi che gli permettano di eseguire le varie operazioni con i dischi, i file, le periferiche.

Si tenga presente infine che anche se il kernel tratta tutti i programmi allo stesso modo, non tutti hanno la stessa importanza.

Nella precedente descrizione dell’avvio del sistema abbiamo accennato ad un programma particolare, init, che ha un ruolo privilegiato in quanto e quello che si occupa dell’inizializzazione del sistema.

La sua peculiarità e quella di essere lanciato per primo direttamente dal kernel e dover gestire il lancio di tutti gli altri programmi, per cui non puo essere mai terminato. Ma anche init alla fine non è che un programma che usa le system call e viene eseguito dal kernel, come un qualunque altro programma, ed infatti esistono alternative rispetto alla implementazione classica, come systemd o upstart.

Un’altra caratteristica fondamentale dell’architettura dei sistemi unix-like è quella per cui qualunque processo puo’ a sua volta lanciarne di nuovi, per cui si dice che il primo processo e il padre degli altri, che a loro volta sono chiamati figli.

Benchè Linux stia diventando il piu di uso, esistono parecchi altri kernel unix-like, sia liberi che proprietari, nati nella tumultuosa e complessa evoluzione che dallo Unix originario della AT/T ha portato alla nascita di una miriade di sistemi derivati che si innestano tutti in due rami principali, quelli derivati dal sistema sviluppato dalla AT/T, detto SysV (da System V, l’ultima versione ufficiale) e quelli derivati dal codice sviluppato all’università di Berkeley, detto BSD (da Berkeley Software Distribution).

La prima caratteristica distintiva di Linux è che esso e stato riscritto da zero, per cui non è classificabile in nessuno di questi due rami e prende invece, a seconda dei casi, quelle che sono state ritenute le migliori caratteristiche di ciascuno di essi. Un’altra delle caratteristiche peculiari di Linux rispetto agli altri kernel unix-like è quella di essere modulare; Linux cioè può essere esteso inserendo a sistema attivo degli ulteriori “pezzi”, i moduli, che permettono di ampliare le capacità del sistema (ad esempio fargli riconoscere una nuova periferica). In realtà e sempre possibile costruire un kernel Linux comprensivo di tutti i moduli che servono, ottenendo quello che viene chiamato un kernel monolitico (come sono i kernel tradizionale degli altri Unix) Questo permette di evitare il ritardo nel caricamento dei moduli al momento della richiesta, ma comporta un maggiore consumo di memoria, dovendo tenere dentro il kernel anche codice non utilizzato

Per contro in certi casi l’uso dei moduli puo’ degradare leggermente le prestazioni, quasi sempre in maniera non avvertibile, e puo dar luogo a conflitti inaspettati che con un kernel monolitico avrebbero bloccato il sistema all’avvio, ma questi problemi oggi sono sempre piu rari. In ogni caso non e possibile utilizzare i moduli nel caso in cui le funzionalità da essi fornite siano necessarie ad avviare il sistema.

Una terza peculiarità di Linux e quella del Virtual File System (o VFS). Un concetto generale presente in tutti i sistemi Unix (e non solo) è che lo spazio su disco su cui vengono tenuti i file di dati e organizzato in quello che viene chiamato un filesystem.

Lo spazio disco grezzo è normalmente suddiviso in settori contigui di dimensione fissa, ma all’interno del sistema questo viene organizzato in maniera tale da permettere il rapido reperimento delle informazioni memorizzate su questi settori, anche quando queste sono sparse qua e là sul disco; si ha così quello che l’utente vede come un singolo file. Quello che contraddistingue Linux e che l’interfaccia per la lettura del contenuto di un file-system e stata completamente virtualizzata, per cui inserendo gli opportuni moduli nel sistema diventa possibile accedere con la stessa interfaccia e, salvo limitazioni della realizzazione, in maniera completamente trasparente all’utente ai piu svariati tipi di filesystem, a partire da quelli usati da Windows e dal DOS, dal MacOS, e da tutte le altre versioni di Unix.

Avviare il Sistema

Per controllare la macchina, il componente principale del sistema operativo — il kernel — deve essere caricato da un programma chiamato bootloader, che a sua volta viene caricato da un firmware preinstallato come il BIOS o l’UEFI. Il bootloader può essere personalizzato per passare parametri al kernel, come per esempio quale partizione contiene il root filesystem o in quale modalità deve essere eseguito il sistema operativo.

Una volta caricato, il kernel continua il processo di avvio identificando e configurando l’hardware. Infine, il kernel richiama l’utilità responsabile dell’avvio e della gestione dei servizi del sistema.

NoteSu alcune distribuzioni Linux, i comandi eseguiti in questa lezione potrebbero richiedere privilegi di root.

BIOS o UEFI

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:

  1. Il processo POST (power-on self-test) viene eseguito per identificare semplici guasti hardware non appena la macchina viene accesa.
  2. Il BIOS attiva i componenti di base per caricare il sistema, come l’output video, la tastiera e i supporti di archiviazione.
  3. Il BIOS carica il primo stadio del bootloader dall’MBR (i primi 440 byte del primo dispositivo, come definito nell’utilità di configurazione del BIOS).
  4. Il primo stadio del bootloader richiama il secondo stadio, responsabile della presentazione delle opzioni di avvio e del caricamento del kernel.

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:

  1. Il processo POST (power-on self-test) viene eseguito per identificare semplici guasti hardware non appena la macchina viene accesa.
  2. L’UEFI attiva i componenti di base per caricare il sistema, come l’output video, la tastiera e i supporti di archiviazione.
  3. Il firmware UEFI legge le definizioni archiviate in NVRAM per eseguire l’applicazione EFI predefinita memorizzata nel filesystem della partizione ESP. Di solito, l’applicazione EFI predefinita è un bootloader.
  4. Se l’applicazione EFI predefinita è un bootloader, caricherà il kernel per avviare il sistema operativo.

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

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:acpi

Abilita/disabilita il supporto ACPI. acpi=off disabiliterà il supporto per ACPI.init

Imposta un iniziatore di sistema alternativo.

Per esempio, init=/bin/bash imposterà la shell Bash come iniziatore.

Ciò significa che una sessione di shell inizierà subito dopo il processo di avvio del kernel.

systemd.unit

Imposta il systemd target da attivare.

Per esempio, systemd.unit=graphical.target. Systemd accetta anche i runlevel numerici definiti per SysV. Per attivare il runlevel 1, per esempio, è necessario includere solo il numero 1 o la lettera S (abbreviazione di “single”) come parametro del kernel.

mem

Imposta la quantità di RAM disponibile per il sistema. Questo parametro è utile per le macchine virtuali in modo da limitare la quantità di RAM disponibile per ciascun guest. L’uso di mem=512M limiterà a 512 megabyte la quantità di RAM disponibile per un particolare sistema guest.

maxcpus

Limita il numero di processori (o core del processore) visibili al sistema nelle macchine multiprocessore simmetriche. È utile anche per macchine virtuali. Un valore di 0 disattiva il supporto per macchine multiprocessore e ha lo stesso effetto del parametro del kernel 

nosmp.

Il parametro maxcpus=2 limiterà il numero di processori disponibili al sistema operativo a due.quiet

Nasconde la maggior parte dei messaggi di avvio.

vga

Seleziona una modalità video. Il parametro vga=ask mostrerà un elenco delle modalità disponibili tra cui scegliere.root

Imposta la partizione root, distinta da quella preconfigurata nel bootloader. Per esempio, root=/dev/sda3.rootflags

Opzioni di mount per il filesystem di root.

ro

Rende il montaggio iniziale del root filesystem di sola lettura.

rw

Consente la scrittura nel root filesystem durante il montaggio iniziale.

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.

NoteLa configurazione di GRUB verrà discussa ulteriormente in una lezione successiva.

Inizializzazione del Sistema

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.

NoteIn senso stretto, il sistema operativo è solo il kernel e i suoi componenti che controllano l’hardware e gestiscono tutti i processi. È comune, tuttavia, usare il termine “sistema operativo” più liberamente, per designare un intero gruppo di programmi distinti che compongono l’ambiente software in cui l’utente può eseguire le attività di calcolo di base.

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.SysV standard

Un gestore di servizi basato sullo standard SysVinit controlla quali demoni e risorse saranno disponibili impiegando il concetto di runlevels. I runlevel sono numerati da 0 a 6 e sono progettati dai manutentori della distribuzione per soddisfare scopi specifici.

Le uniche definizioni di runlevel condivise tra tutte le distribuzioni sono i runlevel 0, 1 e 6.systemd

systemd è un moderno gestore di sistemi e servizi con un livello di compatibilità per i comandi e i runlevel di SysV.

systemd ha una struttura concorrente, impiega socket e D-Bus per l’attivazione dei servizi, esecuzione dei demoni su richiesta, monitoraggio dei processi con cgroup, supporto alle snapshot, ripristino della sessione di sistema, controllo dei punti di montaggio e controllo dei servizi basato sulle relative dipendenze.

Negli ultimi anni la maggior parte delle principali distribuzioni Linux ha gradualmente adottato systemd come gestore di sistema predefinito..Upstart

Come systemd, Upstart è un sostituto di init. L’obiettivo di Upstart è accelerare il processo di avvio parallelizzando il processo di caricamento dei servizi di sistema. Upstart è stato utilizzato dalle distribuzioni basate su Ubuntu in precedenti versioni alle attuali, ma oggi ha lasciato il posto a systemd..

Ispezionare l’inizializzazione

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:

$ dmesg
[    5.262389] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[    5.449712] ip_tables: (C) 2000-2006 Netfilter Core Team
[    5.460286] systemd[1]: systemd 237 running in system mode.
[    5.480138] systemd[1]: Detected architecture x86-64.
[    5.481767] systemd[1]: Set hostname to <torre>.
[    5.636607] systemd[1]: Reached target User and Group Name Lookups.
[    5.636866] systemd[1]: Created slice System Slice.
[    5.637000] systemd[1]: Listening on Journal Audit Socket.
[    5.637085] systemd[1]: Listening on Journal Socket.
[    5.637827] systemd[1]: Mounting POSIX Message Queue File System...
[    5.638639] systemd[1]: Started Read required files in advance.
[    5.641661] systemd[1]: Starting Load Kernel Modules...
[    5.661672] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[    5.694322] lp: driver loaded but no devices found
[    5.702609] ppdev: user-space parallel port driver
[    5.705384] parport_pc 00:02: reported by Plug and Play ACPI
[    5.705468] parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
[    5.800146] lp0: using parport0 (interrupt-driven).
[    5.897421] systemd-journald[352]: Received request to flush runtime journal from PID 1

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:

$ journalctl --list-boots
 -4 9e5b3eb4952845208b841ad4dbefa1a6 Thu 2019-10-03 13:39:23 -03—Thu 2019-10-03 13:40:30 -03
 -3 9e3d79955535430aa43baa17758f40fa Thu 2019-10-03 13:41:15 -03—Thu 2019-10-03 14:56:19 -03
 -2 17672d8851694e6c9bb102df7355452c Thu 2019-10-03 14:56:57 -03—Thu 2019-10-03 19:27:16 -03
 -1 55c0d9439bfb4e85a20a62776d0dbb4d Thu 2019-10-03 19:27:53 -03—Fri 2019-10-04 00:28:47 -03
  0 08fbbebd9f964a74b8a02bb27b200622 Fri 2019-10-04 00:31:01 -03—Fri 2019-10-04 10:17:01 -03

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:

$ journalctl -b 0
oct 04 00:31:01 ubuntu-host kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
oct 04 00:31:01 ubuntu-host kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
oct 04 00:31:01 ubuntu-host systemd[1]: systemd 237 running in system mode.
oct 04 00:31:01 ubuntu-host systemd[1]: Detected architecture x86-64.
oct 04 00:31:01 ubuntu-host systemd[1]: Set hostname to <torre>.
oct 04 00:31:01 ubuntu-host systemd[1]: Reached target User and Group Name Lookups.
oct 04 00:31:01 ubuntu-host systemd[1]: Created slice System Slice.
oct 04 00:31:01 ubuntu-host systemd[1]: Listening on Journal Audit Socket.
oct 04 00:31:01 ubuntu-host systemd[1]: Listening on Journal Socket.
oct 04 00:31:01 ubuntu-host systemd[1]: Mounting POSIX Message Queue File System...
oct 04 00:31:01 ubuntu-host systemd[1]: Started Read required files in advance.
oct 04 00:31:01 ubuntu-host systemd[1]: Starting Load Kernel Modules...
oct 04 00:31:01 ubuntu-host kernel: EXT4-fs (sda1): re-mounted. Opts: commit=300,barrier=0,errors=remount-ro
oct 04 00:31:01 ubuntu-host kernel: lp: driver loaded but no devices found
oct 04 00:31:01 ubuntu-host kernel: ppdev: user-space parallel port driver
oct 04 00:31:01 ubuntu-host kernel: parport_pc 00:02: reported by Plug and Play ACPI
oct 04 00:31:01 ubuntu-host kernel: parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
oct 04 00:31:01 ubuntu-host kernel: lp0: using parport0 (interrupt-driven).
oct 04 00:31:01 ubuntu-host systemd-journald[352]: Journal started
oct 04 00:31:01 ubuntu-host systemd-journald[352]: Runtime journal (/run/log/journal/abb765408f3741ae9519ab3b96063a15) is 4.9M, max 39.4M, 34.5M free.
oct 04 00:31:01 ubuntu-host systemd-modules-load[335]: Inserted module 'lp'
oct 04 00:31:01 ubuntu-host systemd-modules-load[335]: Inserted module 'ppdev'
oct 04 00:31:01 ubuntu-host systemd-modules-load[335]: Inserted module 'parport_pc'
oct 04 00:31:01 ubuntu-host systemd[1]: Starting Flush Journal to Persistent Storage...

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.

How useful was this post?

Click on a star to rate it!

Average rating / 5. Vote count:

No votes so far! Be the first to rate this post.

As you found this post useful...

Follow us on social media!

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?