1.2. Esame dettagliato del processo di avvio

L'inizio del processo di avvio varia in base alla piattaforma utilizzata. Tuttavia, quando il kernel viene rilevato e caricato dal boot loader, il processo di avvio di default è identico per tutte le architetture. Questo capitolo si dedica principalmente all'architettura x86.

1.2.1. Il BIOS

Quando un computer x86 viene avviato, il processore controlla il BIOS o Basic Input/Output System alla fine della memoria del sistema e lo esegue. Il BIOS controlla non solo la prima fase del processo di avvio, ma fornisce l'interfaccia di livello inferiore alle periferiche. Per questo motivo è scritto in una memoria permanente in sola lettura e può sempre essere utilizzato.

Altre piattaforme utilizzano programmi diversi per eseguire attività di livello inferiore in minima parte equivalenti a quelle del BIOS di un sistema x86. Per esempio i computer con processore Itanium utilizzano la shell EFI (Extensible Firmware Interface, mentre i sistemi Alpha utilizzano la console SRM.

Dopo il caricamento il BIOS esamina il sistema, cerca e controlla le periferiche e cerca un dispositivo valido per avviare il sistema. Di solito controlla le unità floppy e i CD-ROM presenti alla ricerca di supporti avviabili e verifica il disco fisso. Nella maggior parte dei casi, la sequenza delle unità utilizzate per l'avvio è controllata da una particolare configurazione del BIOS. Spesso il primo disco fisso impostato per l'avvio è il disco C o il dispositivo IDE master del bus IDE primario. Il BIOS carica in memoria qualsiasi programma presente nel primo settore di questo dispositivo, denominato MBR o Master Boot Record. L'MBR ha dimensioni pari a soli 512 byte e contiene le istruzioni in codice macchina per l'avvio del computer oltre alla tabella delle partizioni. Al termine dell'operazione il BIOS passa il controllo a qualsiasi programma si trova nell'MBR.

1.2.2. Il boot loader

Questa sezione si dedica in particolare al boot loader per la piattaforma x86. A seconda dell'architettura del sistema, il processo di avvio può differire leggermente. Per ulteriori informazioni sui boot loader diversi da x86, consultate la Sezione 1.2.2.1.

In Red Hat Enterprise Linux sono disponibili due boot loader: GRUB o LILO. GRUB è il boot loader di default, ma LILO è disponibile per coloro che lo richiedono per la propria configurazione hardware o per chi lo preferisce. Per ulteriori informazioni sulla configurazione e l'utilizzo di GRUB o LILO, consultate Capitolo 2.

Entrambi boot loader per la piattaforma x86 sono caratterizzati da almeno due fasi, la prima delle quali è rappresentata da una piccola porzione del codice macchina binario dell'MBR. L'unico obiettivo di questa fase è quello di rilevare il boot loader secondario e caricare la prima parte in memoria.

GRUB è il boot loader più recente, e ha il vantaggio di poter leggere ext2 e ext3. [1]partizioni e carica il file di configurazione — /boot/grub/grub.conf— durante l'avvio. Per ulteriori informazioni consultate la Sezione 2.7.

LILO, il boot loader secondario, utilizza l'informazione sul MBR per determinare quale opzione di avvio è disponibile all'utente. Questo significa che quando viene effettuata una modifica di configurazione oppure il kernel viene aggiornato manualmente, il comando /sbin/lilo -v -v deve essere eseguito per scrivere questa informazione sull'MBR. Per maggiori informazioni su come utilizzare questo comando, consultate la Sezione 2.8.

SuggerimentoSuggerimento
 

Se aggiornate il kernel mediante Red Hat Update Agent, il file di configurazione per il boot loader verrà aggiornato automaticamente. Per ulteriori infomazioni su Red Hat Network fate riferimento all'URL riportato di seguito: https://rhn.redhat.com.

Quando il boot loader secondario è in memoria, viene visualizzata la schermata grafica che mostra i diversi sistemi operativi o i kernel che sono stati configurati per l'avvio. Su questa schermata un utente può usare i tasti direzionali per scegliere quale sistema operativo o kernel vuole avviare e premere [Invio]. Se nessun tasto è premuto, il boot loader carica la selezione di default dopo che sia trascorso un determinato periodo di tempo.

NotaNota Bene
 

Se avete installato il supporto per il kernel SMP (Symmetric Multi-Processor), ci saranno più opzioni al primo avvio del sistema. In questa situazione, LILO mostrerà linux, il kernel di SMP, e linux-up, per singoli processori. GRUB visualizza Red Hat Enterprise Linux (<versione-kernel>-smp), il kernek di SMP, e Red Hat Enterprise Linux (<versione-kernel>), per singoli processori.

Se si verificassero dei problemi con il kernel SMP, provate a selezionare il kernel non-SMP dopo il riavvio.

Quando il boot loader della seconda fase ha determinato quale kernel avviare, esso rileva il kernel binario corrispondente nella directory /boot/. Il kernel binario viene chiamato usando il formato seguente — /boot/vmlinuz-<versione-kernel> file (dove <versione-kernel> corrisponde alla versione del kernel specificata nelle impostazioni del boot loader).

Per instruzioni su come usare il boot loader per fornire argomenti della linea di comando al kernel, consultate Capitolo 2. Per maggiori informazioni su come modificare il runlevel al prompt di GRUB o LILO, consultate la Sezione 2.10.

Il boot loader colloca quindi in memoria l'immagine RAM disk iniziale appropriata, chiamata initrd. initrd è utilizzata dal kernel per caricare tutti i driver necessari per avviare il sistema. Questa operazione è particolarmente importante se disponete di unità SCSI o state utilizzando il filesystem ext3 [2].

AttenzioneAvvertenza
 

Non rimuovete per nessun motivo la directory /initrd/ dal filesystem o il sistema non sarà in grado di avviarsi e verrà visualizzato un messaggio di errore relativo al kernel.

Dopo avere caricato in memoria il kernel e l'immagine initrd, il boot loader trasferisce il controllo del processo di avvio al kernel.

Per una panoramica più dettagliata sui boot loader GRUB e LILO, consultate Capitolo 2.

1.2.2.1. I boot loader ed altre architetture

Dopo il caricamento e il trasferimento del processo di avvio al comando init, la stessa sequenza di eventi si verifica in ogni architettura. La differenza principale tra ogni processo di avvio dell'architettura, consiste nell'applicazione utilizzata per trovare e caricare il kernel.

Per esempio, l'architettura Alpha utilizza il boot loader aboot, l'architettura Itanium usa il boot loader ELILO, la pSeries IBM usa YABOOT, e i sistemi s390 IBM usano il boot loader z/IPL.

Consultate Red Hat Enterprise Linux Installation Guide specifico per queste piattaforme e per informazioni su come configurare i relativi boot loader.

1.2.3. Il kernel

Quando viene caricato il kernel, esso inizializza e configura immediatamente la memoria del computer. Configura quindi i vari elementi hardware collegati al sistema, incluso tutti i processori e i sottosistemi I/O, oltre a tutti i dispositivi di memorizzazione. Cerca quindi l'immagine initrd compressa in una posizione predeterminata della memoria, la decomprime, la monta e carica tutti i driver necessari. Successivamente inizializza i dispositivi virtuali del sistema, come LVM o il software RAID prima di smontare l'immagine disco initrd e liberare tutta la memoria.

Dopo l'inizializzazione di tutti i dispositivi del sistema da parte del kernel, viene creato un dispositivo root, montata la partizione root di sola lettura e liberata la memoria non utilizzata.

Il kernel risulta così caricato in memoria e operativo. Tuttavia, senza alcuna applicazione che consenta all'utente di fornire un input significativo al sistema, il kernel non è molto utile.

Per configurare l'ambiente utente, il kernel esegue il programma /sbin/init.

1.2.4. Il programma /sbin/init

Il programma /sbin/init (chiamato anche init) coordina la fase restante del processo di avvio e configura l'ambiente per l'utente.

Quando il comando init viene eseguito, diventa il padre di tutti i processi che si avviano automaticamente sul sistema. Innanzitutto esegue lo script /etc/rc.d/rc.sysinit che imposta il percorso dell'ambiente, attiva lo swap, controlla i filesystem e si occupa di tutti i processi che vanno eseguiti perl'inizializzazione del sistema. Per esempio, la maggior parte dei sistemi utilizza un orologio, così rc.sysinit legge il file di configurazione /etc/sysconfig/clock per inizializzare l'orologio dell'hardware. Ad esempio, se dovete inizializzare processi speciali per le porte seriali, rc.sysinit può eseguire anche il file /etc/rc.serial.

In seguito il comando init esegue lo script /etc/inittab, che descrive il modo in cui il sistema va impostato in ogni runlevel SysV [3]. Tra le altre cose /etc/inittab imposta il runlevel di default e indica che /sbin/update va eseguito a ogni avvio del runlevel. [4].

Successivamente il comando init imposta la libreria di funzione della fonte, /etc/rc.d/init.d/functions per il sistema il quale configura il modo di avvio o come eliminare e determinare il PID di un programma.

A questo punto il programma init avvia tutti i processi di background cercando nella relativa directory rc il runlevel specificato come predefinito in /etc/inittab. Le directory rc) sono numerate per corrispondere ai runlevel che rappresentano. Per esempio /etc/rc.d/rc5.d/ è la directory per il runlevel cinque.

Quando si esegue l'avvio dal runlevel 5, il programma init cerca nella directory /etc/rc.d/rc5.d/ per determinare quali processi iniziare e arrestare.

Di seguito è riportato un esempio che illustra un runlevel 5, la directory /etc/rc.d/rc5.d/:

K05innd -> ../init.d/innd
K05saslauthd -> ../init.d/saslauthd
K10psacct -> ../init.d/psacct
K10radiusd -> ../init.d/radiusd
K12mysqld -> ../init.d/mysqld
K15httpd -> ../init.d/httpd
K15postgresql -> ../init.d/postgresql
K16rarpd -> ../init.d/rarpd
K20iscsi -> ../init.d/iscsi
K20netdump-server -> ../init.d/netdump-server
K20nfs -> ../init.d/nfs
K20tomcat -> ../init.d/tomcat
K24irda -> ../init.d/irda
K25squid -> ../init.d/squid
K28amd -> ../init.d/amd
K34dhcrelay -> ../init.d/dhcrelay
K34yppasswdd -> ../init.d/yppasswdd
K35dhcpd -> ../init.d/dhcpd
K35smb -> ../init.d/smb
K35vncserver -> ../init.d/vncserver
K35winbind -> ../init.d/winbind
K36lisa -> ../init.d/lisa
K45arpwatch -> ../init.d/arpwatch
K45named -> ../init.d/named
K45smartd -> ../init.d/smartd
K46radvd -> ../init.d/radvd
K50netdump -> ../init.d/netdump
K50snmpd -> ../init.d/snmpd
K50snmptrapd -> ../init.d/snmptrapd
K50tux -> ../init.d/tux
K50vsftpd -> ../init.d/vsftpd
K54pxe -> ../init.d/pxe
K61ldap -> ../init.d/ldap
K65kadmin -> ../init.d/kadmin
K65kprop -> ../init.d/kprop
K65krb524 -> ../init.d/krb524
K65krb5kdc -> ../init.d/krb5kdc
K70aep1000 -> ../init.d/aep1000
K70bcm5820 -> ../init.d/bcm5820
K74ntpd -> ../init.d/ntpd
K74ypserv -> ../init.d/ypserv
K74ypxfrd -> ../init.d/ypxfrd
K84bgpd -> ../init.d/bgpd
K84ospf6d -> ../init.d/ospf6d
K84ospfd -> ../init.d/ospfd
K84ripd -> ../init.d/ripd
K84ripngd -> ../init.d/ripngd
K85zebra -> ../init.d/zebra
K92ipvsadm -> ../init.d/ipvsadm
K95firstboot -> ../init.d/firstboot
S00microcode_ctl -> ../init.d/microcode_ctl
S08ip6tables -> ../init.d/ip6tables
S08iptables -> ../init.d/iptables
S09isdn -> ../init.d/isdn
S10network -> ../init.d/network
S12syslog -> ../init.d/syslog
S13irqbalance -> ../init.d/irqbalance
S13portmap -> ../init.d/portmap
S14nfslock -> ../init.d/nfslock
S17keytable -> ../init.d/keytable
S20random -> ../init.d/random
S24pcmcia -> ../init.d/pcmcia
S25netfs -> ../init.d/netfs
S26apmd -> ../init.d/apmd
S28autofs -> ../init.d/autofs
S44acpid -> ../init.d/acpid
S55sshd -> ../init.d/sshd
S56rawdevices -> ../init.d/rawdevices
S56xinetd -> ../init.d/xinetd
S59hpoj -> ../init.d/hpoj
S80sendmail -> ../init.d/sendmail
S85gpm -> ../init.d/gpm
S90canna -> ../init.d/canna
S90crond -> ../init.d/crond
S90cups -> ../init.d/cups
S90FreeWnn -> ../init.d/FreeWnn
S90xfs -> ../init.d/xfs
S95atd -> ../init.d/atd
S97rhnsd -> ../init.d/rhnsd
S99local -> ../rc.local
S99mdmonitor -> ../init.d/mdmonitor

Nessuno degli script che avvia e arresta realmente i servizi si trova nella directory /etc/rc.d/rc5.d/. Tutti i file in /etc/rc.d/rc5.d/ sono link simbolici diretti a script che si trovano nella directory /etc/rc.d/init.d/. I link simbolici sono utilizzati in ciascuna delle directory rc per fare in modo che i runlevel possano essere riconfigurati creando, modificando ed eliminando i link simbolici senza influire sugli script a cui fanno riferimento.

Il nome di ciascun link simbolico inizia con K o S. I link K sono processi che vengono terminati, mentre quelli che iniziano con S vengono avviati.

Il comando init arresta innanzi tutto i link simbolici K della directory eseguendo il comando /etc/rc.d/init.d/<comando> stop, in cui <comando> è il processo da terminare. Avvia quindi tutti i link simbolici S eseguendo il comando /etc/rc.d/init.d/<comando> start.

SuggerimentoSuggerimento
 

Al termine dell'avvio del sistema, è possibile accedere come root ed eseguire gli stessi script per avviare e interrompere i servizi. Per esempio il comando /etc/rc.d/init.d/httpd stop interrompe Server HTTP Apache.

Ciascuno dei link simbolici è numerato per stabilire l'ordine di avvio. Potete modificare l'ordine in cui i servizi vengono avviati o interrotti cambiando questo numero. I link simbolici con lo stesso numero sono avviati in base a un ordine alfabetico.

NotaNota Bene
 

Una delle ultime cose che il programma init esegue, è il file /etc/rc.d/rc.local. Questo file è utile per la personalizzazione del sistema. Per uteriori informazioni sulla personalizzazione del sistema usando il file rc.local consultate la Sezione 1.3.

Dopo che il comando init è andato avanti attraverso la directory appropriata rc per la ricerca del runlevel, lo script /etc/inittab crea un processo /sbin/mingetty per ciascuna console virtuale (prompt di login) di ogni runlevel. I runlevel da 2 a 5 hanno le sei console virtuali, mentre il runlevel 1, (in modalità a utente singolo), dispone di una sola console virtuale e i runlevel 0 e 6 non ne hanno alcuna. Il processo /sbin/mingetty apre delle linee di comunicazione per i dispositivi tty [5], ne imposta la modalità, visualizza il prompt di login, riceve il nome dell'utente e inizializza il processo di login per quell'utente.

Nel runlevel 5 /etc/inittab esegue uno script chiamato /etc/X11/prefdm. Lo script prefdm esegue il display manager X preferito[6]gdm, kdm,o xdm, in base al contenuto del file /etc/sysconfig/desktop/.

Una volta terminato, il sistema è operativo sul runlevel 5, mostrando anche una schermata di login.

Note

[1]

GRUB legge i filesystem ext3 come ext2, non facendo caso al file journal. Per ulteriori informazioni sul filesystem ext3 consultate il capitolo intitolato Il Filesystem ext3 nella Red Hat Enterprise Linux System Administration Guide.

[2]

Per maggiori informazioni su come creare una initrd, consultate la sezione sulla conversione di un filesystem ext3 nella Red Hat Enterprise Linux System Administration Guide.

[3]

Per maggiori informazioni sui runlevel SysV init, consultate la Sezione 1.4.

[4]

Il comando update viene utilizzato per ripulire i buffer difettosi su disco.

[5]

Per maggiori informazioni sui dispositivi tty, consultate la Sezione 5.3.11.

[6]

Consultare la Sezione 7.5.2 per maggiori informazioni sui display manager.