Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux Reference Guide - Esame dettagliato del processo di avvio

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, eseguendolo in un secodno momento. 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 Extensible Firmware Interface (EFI).

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 ed i CD-ROM presenti alla ricerca di supporti avviabili, se non riesce ad eseguire tale operazione, verifica il disco fisso. Nella maggior parte dei casi, la sequenza delle unit� utilizzate per l'avvio, � controllata da una particolare configurazione del BIOS, eseguendo una ricerca sul dispositivo master IDE sul 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 che si trova nell'MBR.

1.2.2. Il boot loader

Questa sezione si dedica in particolare al boot loader di default per la piattaforma x86, GRUB. 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. Per maggiori informazioni sulla configurazione e sull'uso di GRUB, controllare il Capitolo 2.

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

GRUB ha il vantaggio di poter leggere ext2 e ext3 [1] e carica il file di configurazione — /boot/grub/grub.conf— al momento dell'avvio. Per ulteriori informazioni su come modificare questo file, consultate la Sezione 2.7.

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 un determinato periodo di tempo.

NotaNota Bene
 

Se avete installato il supporto per il kernel (SMP) Symmetric Multi-Processor, numerose opzioni saranno disponibili al primo avvio del sistema. In questa situazione GRUB visualizza Red Hat Enterprise Linux (<versione-kernel>-smp), il kernel 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> (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 il Capitolo 2. Per maggiori informazioni su come modificare il runlevel al prompt del boot loader, consultate la Sezione 2.8.

Il boot loader colloca quindi in memoria una o pi� immagini initramfs. Successivamente il kernel decomprime etrasferisce queste immagini dalla memoria a /boot/, un file system virtuale basato sulla RAM tramite il comando cpio. initramfs viene usato dal kernel per caricare tutti i driver ed i moduli necessari per avviare il sistema. Questa operazione � particolarmente importante se disponete di unit� SCSI o se i sistemi utilizzano il file system ext3.

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

Per una panoramica pi� dettagliata sul boot loader GRUB, 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, consiste nell'applicazione utilizzata per trovare e caricare il kernel.

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

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

1.2.3. Il kernel

Una volta caricato, il kernel inizializza e configura immediatamente la memoria del computer e 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 initramfs compressa in una posizione predeterminata della memoria, la decomprime direttamente su /sysroot/, e carica tutti i driver necessari. Successivamente inizializza i dispositivi virtuali relativi al file system, come LVM o il software RAID prima di completare i processi initramfs e liberare tutta la memoria occupata.

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 genitore 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 per l'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. Un altro esempio potrebbe essere quello con il quale � necessario inizializzare processi speciali per le porte seriali, rc.sysinit pu� eseguire anche il file /etc/rc.serial.

Il comando init esegue lo script /etc/inittab, il quale descrive il modo attraverso il quale il sistema dovrebbe esssere impostato in ogni SysV init runlevel.I runlevel sono degli stati, o modalit�, definiti dai servizi elencati nella directory di SysV /etc/rc.d/rc<x>.d/, dove <x> � il numero del runlevel. Per maggiori informazioni sui runlevel SysV init, consultate la Sezione 1.4.

Successivamente il comando init imposta la libreria di funzione della fonte, /etc/rc.d/init.d/functions, per il sistema il quale a sua volta 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 in modo da corrispondere ai runlevel che rappresentano. Per esempio /etc/rc.d/rc5.d/ � la directory per il runlevel 5.

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
K10dc_server -> ../init.d/dc_server
K10psacct -> ../init.d/psacct
K10radiusd -> ../init.d/radiusd
K12dc_client -> ../init.d/dc_client
K12FreeWnn -> ../init.d/FreeWnn
K12mailman -> ../init.d/mailman
K12mysqld -> ../init.d/mysqld
K15httpd -> ../init.d/httpd
K20netdump-server -> ../init.d/netdump-server
K20rstatd -> ../init.d/rstatd
K20rusersd -> ../init.d/rusersd
K20rwhod -> ../init.d/rwhod
K24irda -> ../init.d/irda
K25squid -> ../init.d/squid
K28amd -> ../init.d/amd
K30spamassassin -> ../init.d/spamassassin
K34dhcrelay -> ../init.d/dhcrelay
K34yppasswdd -> ../init.d/yppasswdd
K35dhcpd -> ../init.d/dhcpd
K35smb -> ../init.d/smb
K35vncserver -> ../init.d/vncserver
K36lisa -> ../init.d/lisa
K45arpwatch -> ../init.d/arpwatch
K45named -> ../init.d/named
K46radvd -> ../init.d/radvd
K50netdump -> ../init.d/netdump
K50snmpd -> ../init.d/snmpd
K50snmptrapd -> ../init.d/snmptrapd
K50tux -> ../init.d/tux
K50vsftpd -> ../init.d/vsftpd
K54dovecot -> ../init.d/dovecot
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
K74ypserv -> ../init.d/ypserv
K74ypxfrd -> ../init.d/ypxfrd
K85mdmpd -> ../init.d/mdmpd
K89netplugd -> ../init.d/netplugd
K99microcode_ctl -> ../init.d/microcode_ctl
S04readahead_early -> ../init.d/readahead_early
S05kudzu -> ../init.d/kudzu
S06cpuspeed -> ../init.d/cpuspeed
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
S15mdmonitor -> ../init.d/mdmonitor
S15zebra -> ../init.d/zebra
S16bgpd -> ../init.d/bgpd
S16ospf6d -> ../init.d/ospf6d
S16ospfd -> ../init.d/ospfd
S16ripd -> ../init.d/ripd
S16ripngd -> ../init.d/ripngd
S20random -> ../init.d/random
S24pcmcia -> ../init.d/pcmcia
S25netfs -> ../init.d/netfs
S26apmd -> ../init.d/apmd
S27ypbind -> ../init.d/ypbind
S28autofs -> ../init.d/autofs
S40smartd -> ../init.d/smartd
S44acpid -> ../init.d/acpid
S54hpoj -> ../init.d/hpoj
S55cups -> ../init.d/cups
S55sshd -> ../init.d/sshd
S56rawdevices -> ../init.d/rawdevices
S56xinetd -> ../init.d/xinetd
S58ntpd -> ../init.d/ntpd
S75postgresql -> ../init.d/postgresql
S80sendmail -> ../init.d/sendmail
S85gpm -> ../init.d/gpm
S87iiim -> ../init.d/iiim
S90canna -> ../init.d/canna
S90crond -> ../init.d/crond
S90xfs -> ../init.d/xfs
S95atd -> ../init.d/atd
S96readahead -> ../init.d/readahead
S97messagebus -> ../init.d/messagebus
S97rhnsd -> ../init.d/rhnsd
S99local -> ../rc.local

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 innanzitutto 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 in modo da stabilire l'ordine di avvio. Potete modificare l'ordine in cui i servizi vengono avviati o interrotti cambiando questo numero. Pi� il numero � basso, prima il servizio corrispondente viene avviato. I link simbolici che presentano lo stesso numero, vengono avviati in base ad 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� 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 [2], 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[3]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 file system ext3, consultate il capitolo intitolato Il File System ext3 nella Red Hat Enterprise Linux System Administration Guide.

[2]

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

[3]

Consultare la Sezione 7.5.2 per maggiori informazioni sui display manager.

 
 
  Published under the terms of the GNU General Public License Design by Interspire