Difference between revisions of "Arch boot process (Italiano)"

From ArchWiki
Jump to: navigation, search
m (init: Gli script di boot di Arch)
(wikify some external links, use https for archlinux.org)
(34 intermediate revisions by 8 users not shown)
Line 1: Line 1:
 
[[Category:Boot process (Italiano)]]
 
[[Category:Boot process (Italiano)]]
 
[[Category:About Arch (Italiano)]]
 
[[Category:About Arch (Italiano)]]
{{i18n|Arch Boot Process}}
+
[[cs:Arch Boot Process]]
 +
[[en:Arch Boot Process]]
 +
[[es:Arch Boot Process]]
 +
[[fr:Processus de boot]]
 +
[[ru:Arch Boot Process]]
 +
[[zh-CN:Arch Boot Process]]
 +
{{Article summary start|Sommario}}
 +
{{Article summary text|Una panoramica cronologica del processo di boot di Arch.}}
 +
{{Article summary heading|Panoramica}}
 +
{{Article summary text|{{Boot process overview (Italiano)}}}}
 +
{{Article summary heading|Pagine correlate}}
 +
{{Article summary wiki|fstab (Italiano)}}
 +
{{Article summary wiki|rc.conf (Italiano)}}
 +
{{Article summary wiki|Autostarting}}
 +
{{Article summary end}}
 +
{{out of date|systemd }}
  
{{translateme}}
+
Questo articolo intende descrivere l'ordine cronologico del processo di avvio di Arch, ed i file che lo interessano, fornendo link a sezioni del wiki dove necessario. Arch come BSD utilizza init, contrariamente al più diffuso SysV. Ciò implica una lieve distinzione tra i runlevel, dato che il sistema di default usa gli stessi moduli e gli stessi processi in tutti i runlevel. Il vantaggio è che gli utenti potranno configurare in maniera molto semplice il processo di avvio(vedere [[rc.conf (Italiano)|rc.conf]]); lo svantaggio è che alcune configurazioni interessanti che offre SysV vanno perse. Consultare la guida su [[Adding Runlevels|come aggiungere runlevel]] in modo da utilizzare alcune opzioni di SysV in Arch. Consultare [[Wikipedia:init]] per approfondire maggiormente le distinzioni tra SysV ed il metodo BSD.
{{note|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}
+
 
+
Questo articolo intende descrivere l'ordine cronologico del processo di avvio di Arch, ed i file che lo interessano, fornendo link a sezioni del wiki dove necessario. Arch come BSD utilizza init, contrariamente al più diffuso SysV. Ciò implica una lieve distinzione tra i runlevel, dato che il sistema di default usa i soliti moduli ed i soliti processi in tutti gli altri runlevel. Il vantaggio è che gli utenti potranno configurare semplicemente il processo di avvio(vedere [[rc.conf (Italiano)]]; lo svantaggio è che alcune configurazioni interessanti che offre SysV vanno perse. Consultare la guida su [[Adding Runlevels|come aggiungere runlevel]] in modo da utilizzare alcune opzioni di SysV in Arch. Consultare [[Wikipedia:init]] per approfondire maggiormente le distinzioni tra SysV ed il metodo BSD.
+
  
 
== Prima di init ==
 
== Prima di init ==
Dopo che la macchina viene accesa ed il [[Wikipedia:Power-on self-test|POST]] è stato completato, il BIOS identifica la periferica impostata per il boot e passa il controllo al settore di avvio([[Master Boot Record (Italiano)|Master Boot Record]]) della periferica. Su una macchina GNU/Linux, spesso viene installato sul MBR del disco un bootloader come [[GRUB (Italiano)| GRUB]] o [[LILO (Italiano)|LILO]]. Il bootloader offre diverse opzioni di avvio ad esempio come Arch Linux e Windows [[Windows and Arch Dual Boot (italiano)|configurati in dual-boot.]] Una volta che viene selezionata Arch, l'immagine del kernel nella cartella {{Filename|/boot}} (attualmente il nome del file è {{Filename|kernel26.img}}) viene decompressa e caricata in memoria.
+
Dopo che la macchina viene accesa ed il [[Wikipedia:Power-on self-test|POST]] è stato completato, il BIOS identifica la periferica impostata per il boot e passa il controllo al settore di avvio ([[Master Boot Record]]) della periferica. Su una macchina GNU/Linux, spesso viene installato sul MBR del disco un bootloader come [[GRUB Legacy (Italiano)| GRUB Legacy]] o [[LILO]]. Il bootloader offre diverse opzioni di avvio, come Arch Linux e Windows [[Windows and Arch Dual Boot|configurati in dual-boot.]] Una volta che viene selezionata Arch, il bootloader carica il kernel ({{ic|vmlinuz-linux}}) ed Il ramdisk iniziale ({{ic|initramfs-linux.img}}) in memoria e dopo avvia il kernel, passando all'indirizzo di memoria dell'immagine.
  
Il kernel è il cuore di un sistema operativo. Esso lavora a basso livello (''kernelspace'') interagendo tra le periferiche della macchina, ed i programmi che ne richiedono le risorse per funzionare. Per sfruttare la CPU in modo efficiente, il kernel usa un sistema di pianificaizone per decidere a quale processo assegnare la priorità e quando, creando così l'illusione(per l'occhio umano) che i processi vengano eseguiti contemporaneamente.
+
Il kernel è il cuore di un sistema operativo. Esso lavora a basso livello (''kernelspace'') interagendo tra le periferiche della macchina, ed i programmi che ne richiedono le risorse per funzionare. Per sfruttare la CPU in modo efficiente, il kernel usa un sistema di pianificazione per decidere a quale processo assegnare la priorità e quando, creando così l'illusione(per l'occhio umano) che i processi vengano eseguiti contemporaneamente.
  
Dopo che il kernel è stato caricato, viene letto l'[[initramfs]](initial RAM filesystem). L'obbiettivo di initramfs è di effettuare il bootstrap del sistema dalla periferica in cui si trova il filesystem di root(vedi [[FHS (Italiano)| FHS]] per maggiori informazioni). Ciò significa che ogni modulo richiesto dalle periferiche come dischi IDE, SCSI, o SATA (oppure USB/FireWire, se si effettua il boot da una di queste periferiche) deve essere caricato. Una volta che initramfs carica i moduli necessari, sia manualmente che tramite [[udev (Italiano)| udev]], il controllo passa di nuovo al kernel ed il processo di avvio continua. Per questa ragione l'initrd può contenere solo i moduli strettamente necessari per l'accesso al filesystem di root(/); non è quindi necessario che contenga tutti i moduli che servono al completo funzionamento della macchina. La maggior parte dei moduli sarà caricata in seguito da udev, durante la fase di init.
+
Dopo essere stato caricato, il kernel decomprime l'[[initramfs]] (initial RAM filesystem), che diventa il file system di root iniziale. Il kernel successivamente esegue {{ic|/init}} come primo processo. La fase ''early userspace'' inizia.
  
Il kernel successivamente richiama il programma {{Codeline|init}} che si trova in {{Filename|/sbin/init}}. {{Codeline|init}} fa riferimento a {{Codeline|glibc}}, la libreria standard del C del progetto GNU. Le librerie sono un insieme di programmi e routine utilizzate frequentemente e sono facilmente identificabili dalla loro esetensione {{Filename|*.so}}. Sono essenziali per il funzionamento base del sistema. Questa fase del processo di avvio è definita ''early userspace''.
+
L'obiettivo di initramfs è di effettuare il bootstrap del sistema fino a che quest'ultimo non sia in gradi di accedere al filesystem di root (vedi [[FHS]] per maggiori informazioni). Ciò significa che ogni modulo richiesto dalle periferiche come dischi IDE, SCSI, o SATA (oppure USB/FireWire, se si effettua il boot da una di queste periferiche) deve essere caricabile dall'initramfs se non è stato compilato all'interno del kernel; Una volta sono caricati i moduli necessari, (sia da un programma, sia con uno script che tramite [[udev (Italiano)| udev]]), il processo di boot continua. Per questa ragione nell'initramfs è necessaria la sola presenza dei moduli assolutamente indispensabili per l'accesso al filesystem di root(/); non è quindi necessario che contenga tutti i moduli che servono al completo funzionamento della macchina. La maggior parte dei moduli sarà caricata in seguito da udev, durante la fase di init.
  
== init: Gli script di boot di Arch ==
+
Alla fase finale della ''early userspace'', la vera root è stata montata, e si sostituisce al file system di root iniziale. {{ic|/sbin/init}} è eseguito, sostituendo il processo {{ic|/init}}.
Il principale processo di avvio di Arch è inizializzato da {{Codeline|init}}, il quale genera tutti gli altri processi. L'obbiettivo di {{Codeline|init}} è di portare il sistema ad uno stato in cui possa essere utilizzato, servendosi degli script di avvio. Come detto in precedenza Arch utilizza degli script di avvio simili a quelli di BSD. {{Codeline|init}} legge il file {{Filename|/etc/inittab}}; il file {{Filename|inittab}} di default comincia così:
+
  
{{File
+
Vedi anche:[http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]
|name=/etc/inittab
+
 
|content=<nowiki>
+
== init e gli script di boot di Arch ==
 +
Il principale processo di avvio di Arch è inizializzato da {{ic|init}}, il quale genera tutti gli altri processi. L'obbiettivo di {{ic|init}} è di portare il sistema ad uno stato in cui possa essere utilizzato, servendosi degli script di avvio. Come detto in precedenza Arch utilizza degli script di avvio simili a quelli di BSD. {{ic|init}} legge il file {{ic|/etc/inittab}}; il file {{ic|inittab}} di default comincia così:
 +
 
 +
{{hc
 +
|/etc/inittab
 +
|output=<nowiki>
 
...
 
...
  
Line 41: Line 57:
 
La prima linea non commentata definisce il runlevel di default del sistema(3). Cosa succede quando il kernel richiama init:
 
La prima linea non commentata definisce il runlevel di default del sistema(3). Cosa succede quando il kernel richiama init:
  
* Prima lo script di inizializzazione viene lanciato, {{Filename|/etc/rc.sysinit}} (uno script [[Bash (Italiano)|Bash]]).
+
* Per prima cosa vine eseguito lo script di inizializzazione, {{ic|/etc/rc.sysinit}} (uno script [[Bash (Italiano)|Bash]]).
* Se si avvia in single user mode(runlevel 1 o S), lo script {{Filename|/etc/rc.single}} verrà lanciato.
+
* Se si avvia in single user mode(runlevel 1 o S), verrà eseguito lo script {{ic|/etc/rc.single}}.
* Se viene avviato un altro runlevel(2-5), verrà lanciato invece lo script {{Filename|/etc/rc.multi}}.
+
* Se viene avviato un altro runlevel(2-5), verrà lanciato invece lo script {{ic|/etc/rc.multi}}.
* L'ultimo script ad essere eseguito sarà {{Filename|/etc/rc.local}}, che di defaul è vuoto.
+
* L'ultimo script ad essere eseguito sarà {{ic|/etc/rc.local}} (tramite {{ic|/etc/rc.multi}}) che di default è vuoto.
  
=== {{Filename|/etc/rc.sysinit}} ===
+
{{Nota|Se si possono ottenere maggiori informazioni riguardo a [[Init and inittab (Italiano)|Init e inittab]].}}
Il file {{Filename|/etc/rc.sysinit}} è un grande script che si occupa di tutta la configurazione dell'hardware, ed alcuni compiti di inizializzazione. Può essere identificato dal suo primo compito, inviare al video le linee:
+
=== /etc/rc.sysinit ===
 +
Il file {{ic|/etc/rc.sysinit}} è un grande script che si occupa di tutta la configurazione dell'hardware, e di alcuni compiti di inizializzazione. Può essere identificato da uno dei suoi primi compiti, inviare al video le linee:
  
 
  Arch Linux
 
  Arch Linux
  http://www.archlinux.org
+
  https://www.archlinux.org
Copyright 2002-2007 Judd Vinet
+
Copyright 2007-2009 Aaron Griffin
+
Distributed under the GNU General Public License (GPL)
+
  
Una veloce visione di alcuni suoi compiti:
+
I compiti di {{ic|rc.sysinit}} sono:
* Includere il file {{Filename|/etc/rc.conf}}.
+
# Includere il file {{ic|/etc/rc.conf}}.
* Includere il file {{Filename|/etc/rc.d/functions}}.
+
# Includere il file {{ic|/etc/rc.d/functions}}.
* Visualizzare un messaggio di benvenuto.
+
# Visualizzare un messaggio di benvenuto.
* Montare vari filesystem virtuali.
+
# Montare vari filesystem virtuali.
* Creare i file per le periferiche.
+
# Assicurarsi che rootfs sia montato in sola lettura (se è richiesto).
* Avviare [[minilogd (Italiano)]].
+
# Avviare [[bootlogd]].
* Inviare i messaggi a [[dmesg (Italiano)]].
+
# Visualizzare avvisi di deprecazioni.
* Configura l'orologio del bios.
+
# Configurare l'orologio del bios.
* Svuota il file {{Filename|/proc/sys/kernel/hotplug}}.
+
# Avviare [[udev]], caricare i moduli dall'array {{Ic|MODULES}} definito in [[rc.conf]] ed attendere che udev finisca di processare gli eventi coldplug.
* Avvia [[udev (Italiano)]] e controlla la presenza degli eventi di udev(udev events).
+
# Avviare l'interfaccia di [[loopback]].
* Avvia l'interfaccia di [[loopback (Italiano)]].
+
# Configurare RAID, btrfs e le mappature dei file system criptati.
* Carica i moduli presenti all'interno dell'array {{Codeline|MODULES}} dal file [[rc.conf (Italiano)|/etc/rc.conf]].
+
# Controllare le partizioni ([[fsck]]).
* Configura eventuali array RAID, file system criptati o LVM.
+
# Rimontare rootfs al fine di applicare le opzioni di [[fstab|/etc/fstab]].
* Effettua controlli forzati dei filesystem ([[fsck (Italiano)]]) delle partizioni secondo le impostazioni di [[fstab (Italiano)|/etc/fstab]].
+
# Montare i file system locali (le condivisioni di rete non verranno montate fino a che un profilo di rete non sarà attivo).
* Monta le partizioni locali e la swap(le condivisioni di rete non verranno montate fino a che un profilo di rete non sarà attivo).
+
# Avviare il monitoraggio dei gruppi di volumi LVM.
* Attiva la [[swap (italiano)]].
+
# Attivare la [[swap]].
* Imposta il nome macchina(hostname), la lingua(locale) e l'orologio di sistema secondo le imostazioni di {{Filename|/etc/rc.conf}}.
+
# Impostare il fuso orario locale.
* Rimuove vari residui dei file temporanei come {{Filename|/tmp/*}}.
+
# Inizializzare il seme random.
* Configura la [[locale (Italiano)|linugua]], la console e la mappatura della tastiera.
+
# Rimuovere vari residui dei file temporanei come {{ic|/tmp/*}}.
* Imposta i caratteri per la console.
+
# Impostare il nome macchina (hostname), la lingua (locale) e l'orologio di sistema secondo le impostazioni di {{ic|/etc/rc.conf}}.
* Scrive gli output dei comandi in {{Filename|/var/log/dmesg.log}}.
+
# Configurare la [[locale|lingua]], la console e la mappatura della tastiera.
 +
# Impostare i caratteri per la console.
 +
# Scrivere gli output dei comandi in {{ic|/var/log/dmesg.log}}.
  
{{Filename|/etc/rc.sysinit}} è uno script e non un file di configurazione. Esso include (quindi ottiene le variabili da) [[rc.conf (Italiano)]] per le configurazioni e {{Filename|/etc/rc.d/functions}} per le fuznioni che producono l'output grafico(colori allineamento ad esempio il passaggio dei demoni da 'busy' a 'done' ecc.). Non c'è bisogno di modificare questo file, salvo non si vogla farlo per provare a velocizzare il processo di boot(a proprio rischio e pericolo).
+
{{ic|/etc/rc.sysinit}} è uno script e non un file di configurazione. Esso include (quindi ottiene le variabili da) [[rc.conf (Italiano)|rc.conf]] per le configurazioni e {{ic|/etc/rc.d/functions}} per le funzioni che producono l'output grafico (colori, allineamento, ad esempio il passaggio dei demoni da 'busy' a 'done' ecc.). Questo file non dovrebbe essere modificato manualmente dato che viene sovrascritto con gli upgrade di {{pkg|initscripts}}. Per aggiungere personalizzazioni è consigliato usare gli hook come descritto più sotto.
  
=== {{Filename|/etc/rc.single}} ===
+
=== /etc/rc.single ===
La modalità a singolo utente(single-user mode) si avvierà come utente root, e dovrebbe essere usata se il sistema non riesce ad avviarsi normalmente o in caso di manutenzione del sistema. Questo script assicura che non siano in esecuzione altri demoni se non quelli essenziali: syslog-ng ed udev. La modalità single-user è utile per la manutenzione del sistema essa infatti impedisce agli utenti di connettersi da remoto evitando quindi che vengano effettuate operazioni che possano portare a perdite di dati o danneggiamenti. Dalla modalità single-user gli utenti possono tornare ad effettuare l'accesso alla normale sessione (multi-user) digitando 'exit' nel prompt dei comandi.
+
La modalità a singolo utente(single-user mode) si avvierà come utente root, e dovrebbe essere usata se il sistema non riesce ad avviarsi normalmente o in caso di manutenzione del sistema. Questo script assicura che non siano in esecuzione altri demoni se non quelli essenziali: syslog-ng ed udev. La modalità single-user è utile per la manutenzione del sistema essa infatti impedisce agli utenti di connettersi da remoto evitando quindi che vengano effettuate operazioni che possano portare a perdite di dati o danneggiamenti. Dalla modalità single-user gli utenti possono tornare ad effettuare l'accesso alla normale sessione (multi-user) digitando "exit" nel prompt dei comandi.
  
=== {{Filename|/etc/rc.multi}} ===
+
=== /etc/rc.multi ===
{{Filename|/etc/rc.multi}} viene eseguito a tutti i runlevel multiutente(es.2,3,4 e 5), cioè ad ogni normale avvio. Normalmente, gli utenti non si accorgono del passaggio da {{Filename|rc.sysinit}} a {{Filename|rc.multi}} perché anche esso usa le stesse funzioni per mandare messaggi a video. Questo script ha tre compiti:
+
{{ic|/etc/rc.multi}} viene eseguito per tutti i runlevel multiutente (es. 2, 3, 4 e 5), cioè ad ogni normale avvio. Normalmente, gli utenti non si accorgono del passaggio da {{ic|rc.sysinit}} a {{ic|rc.multi}} perché anche esso usa {{ic|/etc/rc.d/functions}} per mandare messaggi a video. Questo script ha tre compiti:
  
* Primo, essegue {{Codeline|sysctl}}(per modificare i parametri del kernel a runtime) facendo riferimento alle configurazioni presenti in {{Filename|/etc/sysctl.conf}}. Arch prevede già alcune opzioni all'interno del file; principalmente si tratta di opzioni di rete.
+
# Innanzitutto, esegue [[sysctl]] (per modificare i parametri del kernel a runtime) facendo riferimento alle configurazioni presenti in {{ic|/etc/sysctl.conf}}. Arch prevede già alcune opzioni all'interno del file; principalmente si tratta di opzioni di rete.
* Secondo, e più importante, si occupa di avviare i [[daemons (Italiano)|demoni]], secondo la disposizione nell'array {{Codeline|DAEMONS}} in {{Filename|rc.conf}}.
+
# Si occupa di avviare i [[daemon (Italiano)|demoni]], secondo la disposizione nell'array {{ic|DAEMONS}} in {{ic|rc.conf}}.
* Infine, esegue {{Filename|/etc/rc.local}}.
+
# Infine, esegue {{ic|/etc/rc.local}}.
  
=== {{Filename|/etc/rc.local}} ===
+
=== /etc/rc.local ===
{{Filename|/etc/rc.local}} è lo script di avvio locale per le sessioni multiutente. Esso è vuoto di default, è un ottimo posto dove inserire eventuali comandi che devono essere eseguiti alla fine del processo di boot. Alcune configurazioni (caricamento di moduli, cambiamenti nei font della console, accensione di periferiche) solitamente hanno un apposito file dove essere inserite. Per evitare confusione, assicurarsi che qualsiasi comando si voglia aggiungere al file {{Filename|rc.local}} non si trovi in {{Filename|/etc/profile.d}}, o in qualsiasi altro file di configurazione.
+
{{ic|/etc/rc.local}} è lo script di avvio locale per le sessioni multiutente. È vuoto di default, è un ottimo posto dove inserire eventuali comandi che devono essere eseguiti alla fine del processo di boot. Alcune configurazioni (caricamento di moduli, cambiamenti nei font della console, accensione di periferiche) solitamente hanno un apposito file dove poter essere inserite. Per evitare confusione, assicurarsi che qualsiasi comando si voglia aggiungere al file {{ic|rc.local}} non sia possibile inserirlo in {{ic|/etc/profile.d}}, o in qualsiasi altro file di configurazione.
  
Mentre si modifica questo file, tenere presente che verrà eseguito '''dopo''' il setup di base (moduli/demoni), verrà eseguito come utente '''root''', e '''sia che il server grafico (X) sia avviato o meno'''. Ecco un esempio di come togliere il muto ad alcuni canali audio di ALSA:
+
Mentre si modifica questo file, tenere presente che verrà eseguito '''dopo''' il setup di base (moduli/demoni), verrà eseguito come utente '''root''', e '''sia che il server grafico (X) sia avviato o meno'''. In questo esempio viene utilizzato per togliere il muto ad alcuni canali audio di ALSA:
  
{{File
+
{{hc|/etc/rc.local
|name=/etc/rc.local
+
|output=<nowiki>
|content=<nowiki>
+
 
#!/bin/bash
 
#!/bin/bash
  
Line 107: Line 122:
 
</nowiki>}}
 
</nowiki>}}
  
Un altro modo di usare {{Filename|rc.local}} e di applicare varie modifiche per risolvere problemi che non possono essere risolti con i metodi convenzionali.
+
== Hook personalizzati ==
 +
Gli HOOK possono essere utilizzati per inserire del codice personalizzato in varie parti degli script rc.*.
 +
{| class="wikitable"
 +
|-
 +
! scope="col" | Nome Hook
 +
! scope="col" | Tempi di esecuzione degli hook
 +
|-
 +
| sysinit_start
 +
| All'inizio di rc.sysinit
 +
|-
 +
| sysinit_udevlaunched
 +
| Dopo che udev è stato lanciato in rc.sysinit
 +
|-
 +
| sysinit_udevsettled
 +
| Dopo che uevent si è stabilito in rc.sysinit
 +
|-
 +
| sysinit_prefsck
 +
| Prima che fsck sia eseguito in rc.sysinit
 +
|-
 +
| sysinit_postfsck
 +
| Dopo che fsck viene eseguito in rc.sysinit
 +
|-
 +
| sysinit_premount
 +
| Prima che i file system locali siano montati, ma dopo che root venga montato in modalità lettura-scrittura in rc.sysinit
 +
|-
 +
| sysinit_end
 +
| Alla fine di rc.sysinit
 +
|-
 +
| multi_start
 +
| All'inizio di rc.multi
 +
|-
 +
| multi_end
 +
| Alla fine di rc.multi
 +
|-
 +
| single_start
 +
| All'inizio di rc.single
 +
|-
 +
| single_prekillall
 +
| Prima che tutti i processi vengano uccisi in rc.single
 +
|-
 +
| single_postkillall
 +
| Prima che tutti i processi vengano uccisi in rc.single
 +
|-
 +
| single_udevlaunched
 +
| Dopo che udev è stato lanciato in rc.single
 +
|-
 +
| single_udevsettled
 +
| Dopo che uevents si è stabilito in rc.single
 +
|-
 +
| single_end
 +
| Alla fine di rc.single
 +
|-
 +
| shutdown_start
 +
| All'inizio di rc.shutdown
 +
|-
 +
| shutdown_prekillall
 +
| Prima che tutti i processi vengano uccisi in rc.shutdown
 +
|-
 +
| shutdown_postkillall
 +
| Dopo che tutti i processi vengano uccisi in rc.shutdown
 +
|-
 +
| shutdown_preumount
 +
| Dopo l'ultima scrittura sul filesystem (i demoni sono stati terminati), prima di smontare il filesystem
 +
|-
 +
| shutdown_postumount
 +
| Dopo che i filesystem sono stati smontati
 +
|-
 +
| shutdown_poweroff
 +
| Direttamente prima del powering off in rc.shutdown
 +
|}
 +
 
 +
Per definire una funzione hook, creare un file in /etc/rc.d/functions.d usando:
 +
{{bc|1=function_name() {
 +
  ...
 +
}
 +
add_hook hook_name function_name}}
 +
 
 +
I file in /etc/rc.d/functions.d sono originati da {{ic|/etc/rc.d/functions}}.
 +
È possibile registrare funzioni hook multiple per lo stesso hook, così come registrare la stessa funzione hook per hook multipli. Non definire funzioni chiamate add_hook o run_hook in questi file, dal momento che sono definiti in {{ic|/etc/rc.d/functions}}.
 +
 
 +
==== Esempio ====
 +
Aggiungendo il seguente file si consente la disattivazione della cache write-back su un hard drive <i>prima</i> che tutti i demoni vengano avviati (utile per drives contenenti file MySQL InnoDB).
 +
{{hc|/etc/rc.d/functions.d/hd_settings|output=<nowiki>hd_settings() {
 +
    /sbin/hdparm -W0 /dev/sdb
 +
}
 +
add_hook sysinit_udevsettled hd_settings
 +
add_hook single_udevsettled  hd_settings</nowiki>}}
 +
 
 +
Prima di tutto definisce la funzione hd_settings, e poi la registra per gli hook '''single_udevsettled''' e '''sysinit_udevsettled'''. La funzione viene quindi richiamata immediatamente dopo che uvents si è stabilito in {{ic|/etc/rc.d/rc.sysinit}} o {{ic|/etc/rc.d/rc.single}}.
  
 
== init: Login ==
 
== init: Login ==
Di default, dopo che gli script di boot di Arch sono stati eseguiti, il programma {{Codeline|agetty}} che richiede il nome utente. Dopo che il nome utente è stato digitato, {{Codeline|agetty}} richiama {{Codeline|login}} il quale richide la password.
+
Di default, dopo che gli script di boot di Arch sono stati eseguiti, il programma {{ic|/sbin/agetty}} richiede all'utente il nome di login. Dopo che il nome utente è stato digitato, {{ic|/sbin/agetty}} richiama {{ic|/bin/login}} il quale richiede la password.
  
Infine, una volta effettuato l'accesso, {{Codeline|login}} avvierà la shell di default dell'utente. La shell di default e le variabili di ambiente possono essere definite nel file {{Filename|/etc/profile}}. Tutte le variabili dichiarate all'interno della cartella utente andranno a sostituire quelle definite in {{Filename|/etc}}. Ad esempio se definiamo la stessa variabile sia in {{Filename|/etc/profile}} che in {{Filename|~/.bashrc}} quella che prevarrà sarà quella definita in {{Filename|~/.bashrc}}.
+
Infine, una volta effettuato l'accesso, {{ic|/bin/login}} avvierà la shell di default dell'utente. La shell di default e le variabili di ambiente possono essere definite nel file {{ic|/etc/profile}}. Tutte le variabili dichiarate all'interno della cartella utente andranno a sostituire quelle definite in {{ic|/etc}}. Ad esempio se definiamo la stessa variabile sia in {{ic|/etc/profile}} che in {{ic|~/.bashrc}} quella che prevarrà sarà quella definita in {{ic|~/.bashrc}}.
  
Altre alternative sono [[Automatic login to virtual console (Italiano)|mingetty]] che permette di effettuare l'auto-login oppure [[rungetty (Italiano)]] che anch'essa permette l'auto-login ed inoltre permette di lanciare comandi e programmi in automatico, esempio {{Codeline|htop}}.
+
Altre alternative sono [[Automatic login to virtual console|mingetty]] che permette di effettuare l'auto-login (agetty ha l'opzione per l'auto-login a partire dalla versione 2.20 di {{Pkg|util-linux}})  oppure [[rungetty]] che anch'essa permette l'auto-login ed inoltre permette di lanciare comandi e programmi in automatico, esempio {{ic|htop}}.
  
La maggior parte degli utenti vorrà avviare un server [[Xorg (Italiano)|X (server grafico)]] durante la fase di boot, e dovrranno quindi installare un display manager per effettuare l'accesso, consultare [[Display Manager (Italiano)]] per maggiori dettagli. Alternativamente, [[Start X at boot (Italiano)|questo articolo]] spiega come sia possibile fare a meno di un display manager.
+
La maggior parte degli utenti vorrà avviare un server [[Xorg (Italiano)|X (server grafico)]] durante la fase di boot, e dovranno quindi installare un display manager per effettuare l'accesso, consultare [[Display Manager (Italiano)|Display Manager]] per maggiori dettagli. Alternativamente, [[Start X at boot (Italiano)|questo articolo]] spiega come sia possibile fare a meno di un display manager.
  
== Risorse ==
+
== Altre risorse ==
 +
* [[Improve Boot Performance]]
 +
* [[Runlevels]]
 
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Avviare Linux da Grub in Single User Mode]
 
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Avviare Linux da Grub in Single User Mode]
 
* [http://www.linuxjournal.com/article/4622 Avvio con GRUB]
 
* [http://www.linuxjournal.com/article/4622 Avvio con GRUB]
 
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Il processo di boot]
 
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Il processo di boot]
 
* [http://linux.about.com/library/cmd/blcmdl5_sysctl.conf.htm Linux / Unix Command: sysctl.conf]
 
* [http://linux.about.com/library/cmd/blcmdl5_sysctl.conf.htm Linux / Unix Command: sysctl.conf]
* [http://bbs.archlinux.org/search.php?action=search&keywords=rc.local&search_in=topic&sort_dir=DESC&show_as=topics Cercare nei foum alcuni esempi del file rc.local]
+
* [https://bbs.archlinux.org/search.php?action=search&keywords=rc.local&search_in=topic&sort_dir=DESC&show_as=topics Cercare nei foum alcuni esempi del file rc.local]
 
* [[Wikipedia:Linux startup process]]
 
* [[Wikipedia:Linux startup process]]
 
* [[Wikipedia:initrd]]
 
* [[Wikipedia:initrd]]

Revision as of 04:48, 3 December 2012

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: systemd (Discuss in Talk:Arch boot process (Italiano)#)

Questo articolo intende descrivere l'ordine cronologico del processo di avvio di Arch, ed i file che lo interessano, fornendo link a sezioni del wiki dove necessario. Arch come BSD utilizza init, contrariamente al più diffuso SysV. Ciò implica una lieve distinzione tra i runlevel, dato che il sistema di default usa gli stessi moduli e gli stessi processi in tutti i runlevel. Il vantaggio è che gli utenti potranno configurare in maniera molto semplice il processo di avvio(vedere rc.conf); lo svantaggio è che alcune configurazioni interessanti che offre SysV vanno perse. Consultare la guida su come aggiungere runlevel in modo da utilizzare alcune opzioni di SysV in Arch. Consultare Wikipedia:init per approfondire maggiormente le distinzioni tra SysV ed il metodo BSD.

Prima di init

Dopo che la macchina viene accesa ed il POST è stato completato, il BIOS identifica la periferica impostata per il boot e passa il controllo al settore di avvio (Master Boot Record) della periferica. Su una macchina GNU/Linux, spesso viene installato sul MBR del disco un bootloader come GRUB Legacy o LILO. Il bootloader offre diverse opzioni di avvio, come Arch Linux e Windows configurati in dual-boot. Una volta che viene selezionata Arch, il bootloader carica il kernel (vmlinuz-linux) ed Il ramdisk iniziale (initramfs-linux.img) in memoria e dopo avvia il kernel, passando all'indirizzo di memoria dell'immagine.

Il kernel è il cuore di un sistema operativo. Esso lavora a basso livello (kernelspace) interagendo tra le periferiche della macchina, ed i programmi che ne richiedono le risorse per funzionare. Per sfruttare la CPU in modo efficiente, il kernel usa un sistema di pianificazione per decidere a quale processo assegnare la priorità e quando, creando così l'illusione(per l'occhio umano) che i processi vengano eseguiti contemporaneamente.

Dopo essere stato caricato, il kernel decomprime l'initramfs (initial RAM filesystem), che diventa il file system di root iniziale. Il kernel successivamente esegue /init come primo processo. La fase early userspace inizia.

L'obiettivo di initramfs è di effettuare il bootstrap del sistema fino a che quest'ultimo non sia in gradi di accedere al filesystem di root (vedi FHS per maggiori informazioni). Ciò significa che ogni modulo richiesto dalle periferiche come dischi IDE, SCSI, o SATA (oppure USB/FireWire, se si effettua il boot da una di queste periferiche) deve essere caricabile dall'initramfs se non è stato compilato all'interno del kernel; Una volta sono caricati i moduli necessari, (sia da un programma, sia con uno script che tramite udev), il processo di boot continua. Per questa ragione nell'initramfs è necessaria la sola presenza dei moduli assolutamente indispensabili per l'accesso al filesystem di root(/); non è quindi necessario che contenga tutti i moduli che servono al completo funzionamento della macchina. La maggior parte dei moduli sarà caricata in seguito da udev, durante la fase di init.

Alla fase finale della early userspace, la vera root è stata montata, e si sostituisce al file system di root iniziale. /sbin/init è eseguito, sostituendo il processo /init.

Vedi anche:Early Userspace in Arch Linux

init e gli script di boot di Arch

Il principale processo di avvio di Arch è inizializzato da init, il quale genera tutti gli altri processi. L'obbiettivo di init è di portare il sistema ad uno stato in cui possa essere utilizzato, servendosi degli script di avvio. Come detto in precedenza Arch utilizza degli script di avvio simili a quelli di BSD. init legge il file /etc/inittab; il file inittab di default comincia così:

/etc/inittab
...

# Boot to console
id:3:initdefault:
# Boot to X11
#id:5:initdefault:

rc::sysinit:/etc/rc.sysinit
rs:S1:wait:/etc/rc.single
rm:2345:wait:/etc/rc.multi
rh:06:wait:/etc/rc.shutdown
su:S:wait:/sbin/sulogin

...

La prima linea non commentata definisce il runlevel di default del sistema(3). Cosa succede quando il kernel richiama init:

  • Per prima cosa vine eseguito lo script di inizializzazione, /etc/rc.sysinit (uno script Bash).
  • Se si avvia in single user mode(runlevel 1 o S), verrà eseguito lo script /etc/rc.single.
  • Se viene avviato un altro runlevel(2-5), verrà lanciato invece lo script /etc/rc.multi.
  • L'ultimo script ad essere eseguito sarà /etc/rc.local (tramite /etc/rc.multi) che di default è vuoto.
Nota: Se si possono ottenere maggiori informazioni riguardo a Init e inittab.

/etc/rc.sysinit

Il file /etc/rc.sysinit è un grande script che si occupa di tutta la configurazione dell'hardware, e di alcuni compiti di inizializzazione. Può essere identificato da uno dei suoi primi compiti, inviare al video le linee:

Arch Linux
https://www.archlinux.org

I compiti di rc.sysinit sono:

  1. Includere il file /etc/rc.conf.
  2. Includere il file /etc/rc.d/functions.
  3. Visualizzare un messaggio di benvenuto.
  4. Montare vari filesystem virtuali.
  5. Assicurarsi che rootfs sia montato in sola lettura (se è richiesto).
  6. Avviare bootlogd.
  7. Visualizzare avvisi di deprecazioni.
  8. Configurare l'orologio del bios.
  9. Avviare udev, caricare i moduli dall'array MODULES definito in rc.conf ed attendere che udev finisca di processare gli eventi coldplug.
  10. Avviare l'interfaccia di loopback.
  11. Configurare RAID, btrfs e le mappature dei file system criptati.
  12. Controllare le partizioni (fsck).
  13. Rimontare rootfs al fine di applicare le opzioni di /etc/fstab.
  14. Montare i file system locali (le condivisioni di rete non verranno montate fino a che un profilo di rete non sarà attivo).
  15. Avviare il monitoraggio dei gruppi di volumi LVM.
  16. Attivare la swap.
  17. Impostare il fuso orario locale.
  18. Inizializzare il seme random.
  19. Rimuovere vari residui dei file temporanei come /tmp/*.
  20. Impostare il nome macchina (hostname), la lingua (locale) e l'orologio di sistema secondo le impostazioni di /etc/rc.conf.
  21. Configurare la lingua, la console e la mappatura della tastiera.
  22. Impostare i caratteri per la console.
  23. Scrivere gli output dei comandi in /var/log/dmesg.log.

/etc/rc.sysinit è uno script e non un file di configurazione. Esso include (quindi ottiene le variabili da) rc.conf per le configurazioni e /etc/rc.d/functions per le funzioni che producono l'output grafico (colori, allineamento, ad esempio il passaggio dei demoni da 'busy' a 'done' ecc.). Questo file non dovrebbe essere modificato manualmente dato che viene sovrascritto con gli upgrade di initscripts. Per aggiungere personalizzazioni è consigliato usare gli hook come descritto più sotto.

/etc/rc.single

La modalità a singolo utente(single-user mode) si avvierà come utente root, e dovrebbe essere usata se il sistema non riesce ad avviarsi normalmente o in caso di manutenzione del sistema. Questo script assicura che non siano in esecuzione altri demoni se non quelli essenziali: syslog-ng ed udev. La modalità single-user è utile per la manutenzione del sistema essa infatti impedisce agli utenti di connettersi da remoto evitando quindi che vengano effettuate operazioni che possano portare a perdite di dati o danneggiamenti. Dalla modalità single-user gli utenti possono tornare ad effettuare l'accesso alla normale sessione (multi-user) digitando "exit" nel prompt dei comandi.

/etc/rc.multi

/etc/rc.multi viene eseguito per tutti i runlevel multiutente (es. 2, 3, 4 e 5), cioè ad ogni normale avvio. Normalmente, gli utenti non si accorgono del passaggio da rc.sysinit a rc.multi perché anche esso usa /etc/rc.d/functions per mandare messaggi a video. Questo script ha tre compiti:

  1. Innanzitutto, esegue sysctl (per modificare i parametri del kernel a runtime) facendo riferimento alle configurazioni presenti in /etc/sysctl.conf. Arch prevede già alcune opzioni all'interno del file; principalmente si tratta di opzioni di rete.
  2. Si occupa di avviare i demoni, secondo la disposizione nell'array DAEMONS in rc.conf.
  3. Infine, esegue /etc/rc.local.

/etc/rc.local

/etc/rc.local è lo script di avvio locale per le sessioni multiutente. È vuoto di default, è un ottimo posto dove inserire eventuali comandi che devono essere eseguiti alla fine del processo di boot. Alcune configurazioni (caricamento di moduli, cambiamenti nei font della console, accensione di periferiche) solitamente hanno un apposito file dove poter essere inserite. Per evitare confusione, assicurarsi che qualsiasi comando si voglia aggiungere al file rc.local non sia possibile inserirlo in /etc/profile.d, o in qualsiasi altro file di configurazione.

Mentre si modifica questo file, tenere presente che verrà eseguito dopo il setup di base (moduli/demoni), verrà eseguito come utente root, e sia che il server grafico (X) sia avviato o meno. In questo esempio viene utilizzato per togliere il muto ad alcuni canali audio di ALSA:

/etc/rc.local
#!/bin/bash

# /etc/rc.local: Local multi-user startup script.

amixer sset 'Master Mono' 50% unmute &> /dev/null
amixer sset 'Master' 50% unmute &> /dev/null
amixer sset 'PCM' 75% unmute &> /dev/null

Hook personalizzati

Gli HOOK possono essere utilizzati per inserire del codice personalizzato in varie parti degli script rc.*.

Nome Hook Tempi di esecuzione degli hook
sysinit_start All'inizio di rc.sysinit
sysinit_udevlaunched Dopo che udev è stato lanciato in rc.sysinit
sysinit_udevsettled Dopo che uevent si è stabilito in rc.sysinit
sysinit_prefsck Prima che fsck sia eseguito in rc.sysinit
sysinit_postfsck Dopo che fsck viene eseguito in rc.sysinit
sysinit_premount Prima che i file system locali siano montati, ma dopo che root venga montato in modalità lettura-scrittura in rc.sysinit
sysinit_end Alla fine di rc.sysinit
multi_start All'inizio di rc.multi
multi_end Alla fine di rc.multi
single_start All'inizio di rc.single
single_prekillall Prima che tutti i processi vengano uccisi in rc.single
single_postkillall Prima che tutti i processi vengano uccisi in rc.single
single_udevlaunched Dopo che udev è stato lanciato in rc.single
single_udevsettled Dopo che uevents si è stabilito in rc.single
single_end Alla fine di rc.single
shutdown_start All'inizio di rc.shutdown
shutdown_prekillall Prima che tutti i processi vengano uccisi in rc.shutdown
shutdown_postkillall Dopo che tutti i processi vengano uccisi in rc.shutdown
shutdown_preumount Dopo l'ultima scrittura sul filesystem (i demoni sono stati terminati), prima di smontare il filesystem
shutdown_postumount Dopo che i filesystem sono stati smontati
shutdown_poweroff Direttamente prima del powering off in rc.shutdown

Per definire una funzione hook, creare un file in /etc/rc.d/functions.d usando:

function_name() {
   ...
}
add_hook hook_name function_name

I file in /etc/rc.d/functions.d sono originati da /etc/rc.d/functions. È possibile registrare funzioni hook multiple per lo stesso hook, così come registrare la stessa funzione hook per hook multipli. Non definire funzioni chiamate add_hook o run_hook in questi file, dal momento che sono definiti in /etc/rc.d/functions.

Esempio

Aggiungendo il seguente file si consente la disattivazione della cache write-back su un hard drive prima che tutti i demoni vengano avviati (utile per drives contenenti file MySQL InnoDB).

/etc/rc.d/functions.d/hd_settings
hd_settings() {
    /sbin/hdparm -W0 /dev/sdb
}
add_hook sysinit_udevsettled hd_settings
add_hook single_udevsettled  hd_settings

Prima di tutto definisce la funzione hd_settings, e poi la registra per gli hook single_udevsettled e sysinit_udevsettled. La funzione viene quindi richiamata immediatamente dopo che uvents si è stabilito in /etc/rc.d/rc.sysinit o /etc/rc.d/rc.single.

init: Login

Di default, dopo che gli script di boot di Arch sono stati eseguiti, il programma /sbin/agetty richiede all'utente il nome di login. Dopo che il nome utente è stato digitato, /sbin/agetty richiama /bin/login il quale richiede la password.

Infine, una volta effettuato l'accesso, /bin/login avvierà la shell di default dell'utente. La shell di default e le variabili di ambiente possono essere definite nel file /etc/profile. Tutte le variabili dichiarate all'interno della cartella utente andranno a sostituire quelle definite in /etc. Ad esempio se definiamo la stessa variabile sia in /etc/profile che in ~/.bashrc quella che prevarrà sarà quella definita in ~/.bashrc.

Altre alternative sono mingetty che permette di effettuare l'auto-login (agetty ha l'opzione per l'auto-login a partire dalla versione 2.20 di util-linux) oppure rungetty che anch'essa permette l'auto-login ed inoltre permette di lanciare comandi e programmi in automatico, esempio htop.

La maggior parte degli utenti vorrà avviare un server X (server grafico) durante la fase di boot, e dovranno quindi installare un display manager per effettuare l'accesso, consultare Display Manager per maggiori dettagli. Alternativamente, questo articolo spiega come sia possibile fare a meno di un display manager.

Altre risorse