Crea sito
2 Ottobre 2020

Officine Informatiche Roma

ICT SERVICES ROMA – BAZAAR

LINUX LEZ 7- Avviare il sistema

15 min read

Questa lezione tratta la sequenza di avvio in un sistema Linux standard. La corretta conoscenza di come funziona il processo di avvio di un sistema Linux aiuta a prevenire errori che possono rendere inaccessibile il sistema. La lezione affronta le seguenti aree tematiche:

  • In che modo differiscono i metodi di avvio BIOS e UEFI.

  • Tipiche fasi di inizializzazione del sistema.

  • Ripristino dei messaggi di avvio.

I comandi e le procedure indirizzate erano:

  • Parametri del kernel comuni.

  • Comandi per leggere i messaggi di avvio: dmesgjournalctl.

BIOS o UEFI

Le procedure eseguite dalle macchine x86 per eseguire il bootloader sono diverse se 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 è chiamato 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) di dispositivi di archiviazione che utilizzano lo schema di partizione 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 output video, tastiera e 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 chiama il secondo stadio del bootloader, responsabile della presentazione delle opzioni di avvio e del caricamento del kernel.

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 applicazioni EFI, che verrà eseguito automaticamente o richiamato da un menu di avvio. Le applicazioni EFI possono essere bootloader, selettori di sistemi operativi, strumenti per la diagnostica e la riparazione del sistema, ecc. Devono trovarsi in una partizione di 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 si chiama 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 di dati utente. La directory EFI nella partizione ESP contiene le applicazioni indicate dalle voci salvate nella NVRAM.

In generale, i passaggi di avvio del sistema pre-operativo 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 output video, tastiera e 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 anche una funzionalità 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 coperti dalla garanzia del produttore.

Il bootloader

Il bootloader più popolare per Linux nell’architettura x86 è GRUB ( Grand Unified Bootloader ). Non appena viene chiamato dal BIOS o dall’UEFI, GRUB visualizza un elenco di sistemi operativi disponibili per l’avvio. A volte l’elenco non viene visualizzato automaticamente, ma può essere richiamato premendo Shiftmentre GRUB viene chiamato dal BIOS. Nei sistemi UEFI, invece, è Escnecessario utilizzare la chiave.

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=offdisabiliterà il supporto per ACPI.

init

Imposta un iniziatore di sistema alternativo. Ad esempio, init=/bin/bashimposterà 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 bersaglio per essere attivato. Ad esempio systemd.unit=graphical.target,. Systemd accetta anche i runlevel numerici definiti per SysV . Per attivare il runlevel 1, ad esempio, è necessario includere solo il numero 1o 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’utilizzo mem=512Mlimiterà a 512 megabyte la quantità di RAM disponibile per un determinato 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 0disattiva il supporto per macchine multiprocessore e ha lo stesso effetto del parametro kernel nosmp. Il parametro maxcpus=2limita il numero di processori disponibili per il sistema operativo a due.

quiet

Nasconde la maggior parte dei messaggi di avvio.

vga

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

root

Imposta la partizione root, diversa da quella preconfigurata nel bootloader. Ad esempio root=/dev/sda3,.

rootflags

Opzioni di mount per il filesystem di root.

ro

Rende il montaggio iniziale del filesystem di root di sola lettura.

rw

Consente la scrittura nel filesystem di root durante il montaggio iniziale.

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

Nota

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

Inizializzazione del sistema

Oltre al 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 eseguite e terminate durante il processo di inizializzazione del sistema. I servizi, noti anche come demoni , possono essere attivi in ​​qualsiasi momento in quanto possono essere responsabili di aspetti intrinseci del sistema operativo.

La diversità dei modi in cui script di avvio e demoni con le più diverse caratteristiche che possono essere incorporate in una distribuzione Linux è enorme, un fatto che ha storicamente ostacolato lo sviluppo di un’unica soluzione che soddisfa 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, ad esempio, ma l’amministratore di sistema dovrà quasi sempre riavviare manualmente il servizio dopo aver apportato modifiche al suo file di configurazione.

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

Nota

A rigor di termini, il sistema operativo è solo il kernel e i suoi componenti che controllano l’hardware e gestiscono tutti i processi. È comune, tuttavia, utilizzare 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à computazionali di base.

L’inizializzazione del sistema operativo inizia quando il bootloader carica il kernel nella RAM. Quindi, il kernel prenderà in carico la 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 initramfs ( filesystem RAM iniziale ). Initramfs è un archivio contenente un filesystem usato come filesystem root temporaneo durante il processo di avvio. Lo scopo principale di un file initramfs è 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 /etc/fstabe quindi eseguirà il primo programma, un’utilità denominata init. Il initprogramma è 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.

Standard SysV

Un gestore di servizi basato sullo standard SysVinit controlla quali demoni e risorse saranno disponibili impiegando il concetto di runlevel . 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 del servizio, l’esecuzione del daemon su richiesta, il monitoraggio dei processi con cgroups , il supporto di snapshot , il ripristino della sessione di sistema, il controllo del punto di montaggio e un controllo del servizio basato sulla dipendenza. Negli ultimi anni la maggior parte delle principali distribuzioni Linux ha gradualmente adottato systemd come gestore di sistema predefinito.

parvenu

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 nelle versioni precedenti, ma oggi ha lasciato il posto a systemd.

Ispezione di inizializzazione

Possono verificarsi errori durante il processo di avvio, ma potrebbero non essere così importanti 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 l’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 buffer dell’anello del kernel . I messaggi vengono conservati nel buffer dell’anello del kernel anche quando non vengono visualizzati durante il processo di inizializzazione, come quando invece viene visualizzata un’animazione. Tuttavia, il buffer dell’anello del kernel perde tutti i messaggi quando il sistema è spento o eseguendo il comando dmesg --clear. Senza opzioni, il comando dmesgvisualizza i messaggi correnti nel buffer dell’anello del kernel:

$ dmesg
[5.262389] EXT4-fs (sda1): filesystem montato con modalità dati ordinata. Opts: (null)
[5.449712] ip_tables: (C) 2000-2006 Netfilter Core Team
[5.460286] systemd [1]: systemd 237 in esecuzione in modalità sistema.
[5.480138] systemd [1]: architettura rilevata x86-64.
[5.481767] systemd [1]: imposta il nome host su <torre>.
[5.636607] systemd [1]: Raggiunte ricerche di nomi utente e di gruppo di destinazione.
[5.636866] systemd [1]: slice creata System Slice.
[5.637000] systemd [1]: ascolto su socket di controllo journal.
[5.637085] systemd [1]: ascolto sul socket del journal.
[5.637827] systemd [1]: montaggio del file system di coda messaggi POSIX ...
[5.638639] systemd [1]: Avviato Leggi i file richiesti in anticipo.
[5.641661] systemd [1]: Avvio dei moduli di caricamento del kernel ...
[5.661672] EXT4-fs (sda1): rimontato. Opts: errori = remount-ro
[5.694322] lp: driver caricato ma nessun dispositivo trovato
[5.702609] ppdev: driver della porta parallela dello spazio utente
[5.705384] parport_pc 00:02: segnalato da Plug and Play ACPI
[5.705468] parport0: stile PC a 0x378 (0x778), irq 7, dma 3 [PCSPP, TRISTATE, COMPAT, EPP, ECP, DMA]
[5.800146] lp0: usando parport0 (guidato dall'interruzione).
[5.897421] systemd-journald [352]: Ricevuta richiesta di svuotamento del journal di runtime dal PID 1

L’output di dmesgpuò essere lungo centinaia di righe, quindi l’elenco precedente contiene solo l’estratto che mostra il kernel che chiama il gestore del servizio systemd. I valori all’inizio delle righe sono la quantità di secondi relativa all’inizio del caricamento del kernel.

Nei sistemi basati su systemd, il comando journalctlmostrerà i messaggi di inizializzazione con le opzioni -b--boot-k--dmesg. Il comando journalctl --list-bootsmostra un elenco di numeri di avvio relativi all’avvio corrente, all’hash di identificazione e ai timestamp del primo e dell’ultimo messaggio corrispondente:

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

I registri 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 opzioni -b 0--boot=0, verranno visualizzati i messaggi per l’avvio corrente. Opzioni -b -1--boot=-1verranno visualizzati i messaggi dall’inizializzazione precedente. Opzioni -b -2--boot=-2mostrerà i messaggi dall’inizializzazione prima di così e così via. Il seguente estratto mostra il kernel che chiama il gestore del servizio systemd per l’ultimo processo di inizializzazione:

$ journalctl -b 0
ott 04 00:31:01 kernel ubuntu-host: EXT4-fs (sda1): filesystem montato con modalità dati ordinata. Opts: (null)
04 00:31:01 kernel ubuntu-host: ip_tables: (C) 2000-2006 Netfilter Core Team
ott 04 00:31:01 ubuntu-host systemd [1]: systemd 237 in esecuzione in modalità sistema.
ott 04 00:31:01 ubuntu-host systemd [1]: rilevata architettura x86-64.
ott 04 00:31:01 ubuntu-host systemd [1]: imposta il nome host su <torre>.
ott 04 00:31:01 ubuntu-host systemd [1]: Raggiunte ricerche di nomi utente e di gruppo di destinazione.
ott 04 00:31:01 ubuntu-host systemd [1]: creato slice System Slice.
ott 04 00:31:01 ubuntu-host systemd [1]: ascolto su Journal Audit Socket.
ott 04 00:31:01 ubuntu-host systemd [1]: ascolto su Journal Socket.
ott 04 00:31:01 ubuntu-host systemd [1]: montaggio del file system di coda messaggi POSIX ...
ott 04 00:31:01 ubuntu-host systemd [1]: Avviato Leggi i file richiesti in anticipo.
ott 04 00:31:01 ubuntu-host systemd [1]: avvio del caricamento dei moduli del kernel ...
ott 04 00:31:01 kernel ubuntu-host: EXT4-fs (sda1): rimontato. Opts: commit = 300, barriera = 0, errori = remount-ro
ott 04 00:31:01 kernel ubuntu-host: lp: driver caricato ma nessun dispositivo trovato
ott 04 00:31:01 kernel ubuntu-host: ppdev: driver della porta parallela spazio utente
ott 04 00:31:01 kernel ubuntu-host: parport_pc 00:02: segnalato da Plug and Play ACPI
ott 04 00:31:01 kernel ubuntu-host: parport0: stile PC a 0x378 (0x778), irq 7, dma 3 [PCSPP, TRISTATE, COMPAT, EPP, ECP, DMA]
ott 04 00:31:01 kernel ubuntu-host: lp0: using parport0 (interrupt-driven).
ott 04 00:31:01 ubuntu-host systemd-journald [352]: Diario avviato
04 00:31:01 ubuntu-host systemd-journald [352]: Il journal di runtime (/ run / log / journal / abb765408f3741ae9519ab3b96063a15) è 4,9 M, max 39,4 M, 34,5 M gratuito.
ott 04 00:31:01 ubuntu-host systemd-modules-load [335]: modulo inserito 'lp'
ott 04 00:31:01 ubuntu-host systemd-modules-load [335]: modulo inserito 'ppdev'
ott 04 00:31:01 ubuntu-host systemd-modules-load [335]: modulo inserito 'parport_pc'
ott 04 00:31:01 ubuntu-host systemd [1]: Avvio di Flush Journal in Archiviazione permanente ...

L’inizializzazione e altri messaggi emessi dal sistema operativo sono archiviati 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, è /var/log/possibile cercare i file sottostanti per possibili motivi che causano l’interruzione del processo di avvio. Opzioni -D--directorycomandi journalctlpossono essere utilizzati per leggere i messaggi di registro in directory diverse da /var/log/journal/, che è la posizione predefinita per i messaggi di registro di sistema. Poiché i messaggi di registro di systemd non sono memorizzati in testo non journalctlelaborato , è necessario il comando per leggerli.

Esercitazioni guidate

  1. Su una macchina dotata di un firmware BIOS, dove si trova il binario bootstrap?

  2. Il firmware UEFI supporta funzionalità estese fornite da programmi esterni, chiamati applicazioni EFI. Queste applicazioni, tuttavia, hanno la loro posizione speciale. In quale parte del sistema si troverebbero le applicazioni EFI?

  3. I bootloader consentono il passaggio di parametri del kernel personalizzati prima di caricarlo. Supponiamo che il sistema non sia in grado di avviarsi a causa di una posizione errata del filesystem di root. Come verrebbe /dev/sda3fornito il kernel filesystem root corretto, come parametro, al kernel?

  4. Il processo di avvio di una macchina Linux termina con il seguente messaggio:

    METTERE IN GUARDIA! / dev / sda3 non esiste. Cadere in un guscio!

    Qual è la probabile causa di questo problema?

Esercizi esplorativi

  1. Il bootloader presenterà un elenco di sistemi operativi tra cui scegliere quando sul sistema è installato più di un sistema operativo. Tuttavia, un sistema operativo appena installato può sovrascrivere l’MBR del disco rigido, cancellando il primo stadio del bootloader e rendendo inaccessibile l’altro sistema operativo. Perché ciò non dovrebbe accadere su una macchina dotata di un firmware UEFI?

  2. Qual è una conseguenza comune dell’installazione di un kernel personalizzato senza fornire un’immagine initramfs appropriata?

  3. Il registro di inizializzazione è lungo centinaia di righe, quindi l’output del dmesgcomando viene spesso reindirizzato a un comando cercapersone, come un comando less , per facilitare la lettura. Quale dmesgopzione impaginerà automaticamente il suo output, eliminando la necessità di utilizzare esplicitamente un comando cercapersone?

  4. Un disco rigido contenente l’intero filesystem di una macchina offline è stato rimosso e collegato a una macchina funzionante come unità secondaria. Supponendo che il suo punto di montaggio sia /mnt/hd, come verrebbe journalctlutilizzato per ispezionare il contenuto dei file journal situati in /mnt/hd/var/log/journal/?

Risposte agli esercizi guidati

  1. Su una macchina dotata di un firmware BIOS, dove si trova il binario bootstrap?

    Nell’MBR del primo dispositivo di archiviazione, come definito nell’utilità di configurazione del BIOS.

  2. Il firmware UEFI supporta funzionalità estese fornite da programmi esterni, chiamati applicazioni EFI. Queste applicazioni, tuttavia, hanno la loro posizione speciale. In quale parte del sistema si troverebbero le applicazioni EFI?

    Le applicazioni EFI sono archiviate nella partizione di sistema EFI (ESP), situata in qualsiasi blocco di archiviazione disponibile con un file system compatibile (di solito un file system FAT32).

  3. I bootloader consentono il passaggio di parametri del kernel personalizzati prima di caricarlo. Supponiamo che il sistema non sia in grado di avviarsi a causa di una posizione errata del filesystem di root. Come verrebbe /dev/sda3fornito il kernel filesystem root corretto, come parametro, al kernel?

    Il rootparametro deve essere utilizzato, come in root=/dev/sda3.

  4. Il processo di avvio di una macchina Linux termina con il seguente messaggio:

    METTERE IN GUARDIA! / dev / sda3 non esiste. Cadere in un guscio!

    Qual è la probabile causa di questo problema?

    Il kernel non è stato in grado di trovare il dispositivo /dev/sda3, informato come filesystem di root.

Risposte ad esercizi esplorativi

  1. Il bootloader presenterà un elenco di sistemi operativi tra cui scegliere quando sul sistema è installato più di un sistema operativo. Tuttavia, un sistema operativo appena installato può sovrascrivere l’MBR del disco rigido, cancellando il primo stadio del bootloader e rendendo inaccessibile l’altro sistema operativo. Perché ciò non dovrebbe accadere su una macchina dotata di un firmware UEFI?

    I computer UEFI non utilizzano l’MBR del disco rigido per archiviare il primo stadio del bootloader.

  2. Qual è una conseguenza comune dell’installazione di un kernel personalizzato senza fornire un’immagine initramfs appropriata?

    Il filesystem di root potrebbe essere inaccessibile se il suo tipo è stato compilato come modulo kernel esterno.

  3. Il registro di inizializzazione è lungo centinaia di righe, quindi l’output del dmesgcomando viene spesso reindirizzato a un comando cercapersone, come un comando less , per facilitare la lettura. Quale dmesgopzione impaginerà automaticamente il suo output, eliminando la necessità di utilizzare esplicitamente un comando cercapersone?

    Comandi dmesg -Hdmesg --humanabilita il cercapersone per impostazione predefinita.

  4. Un disco rigido contenente l’intero filesystem di una macchina offline è stato rimosso e collegato a una macchina funzionante come unità secondaria. Supponendo che il suo punto di montaggio sia /mnt/hd, come journalctlpuò essere utilizzato il comando per ispezionare il contenuto dei file journal situati in /mnt/hd/var/log/journal/?

    Con comandi journalctl -D /mnt/hd/var/log/journalojournalctl --directory=/mnt/hd/var/log/journal

Copyright © All rights reserved. | Newsphere by AF themes.
Translate »