Le fasi che caratterizzano il caricamento in memoria di un sistema operativo hanno una logica simile su piattaforme diverse.
Nei sistemi Unix, in particolare, sono identificabili 4 fasi comuni e ben identificabili:
- L'esecuzione del Bios residente su ROM all'accensione del sistema;
- Il caricamento e l'esecuzione di un boot loader, che permette di accedere ai dispositivi disponibili e caricare il kernel;
- Il caricamento e l'esecuzione del kernel e dei suoi moduli;
- L'avvio di INIT e il conseguente startup dei suoi processi figli, che portano il sistema allo stato di normale funzionalità.
Su sistemi Sun Solaris le quattro fasi sono così descritte:
Boot PROM phase
Alimentazione al sistema. Mentre LED si accendono e ventole si attivano, il firmware (OpenBoot sulle SUN meno vecchie) della PROM onboad esegue un Power On Self Test di basso livello (POST) e legge da un modulo rimuovibile di RAM non volatile (NVRAM) dati mutabili quali: date e ora, ethernet address e hostid della macchina, device di boot e altri parametri configurabili dall'utente.
Qui si può SKIPpare il POST premendo il tasto Stop
della tastiera mentre si accende il sistema o attivare il diagnostic mode premendo contemporaneamente i tasti Stop + d
.
Un riavvio di una macchina complessa con livello di debug settato al massimo può durare anche svariati minuti.
Dopo il POST, OpenBoot mette a disposizione una command line che permette di scegliere come procedere nel boot, se eseguire ulteriori test diagnostici e se caricare driver di basso livello di dispositivi di terze parti.
Al prompt di OpenBoot ok è possibile digitare vari comandi tra cui:
banner
- Visualizza informazioni sul sistema tra cui HostID, mac address, modello.
boot [device] - opzioni
- Permette di decidere da dove e come caricare il sistema:
boot
Carica il sistema e lo porta in multiuser mode
boot -s
Carica il sistema in single user mode (maintenance mode) e chiede la password di root
boot cdrom -s
Carica il sistema in maintenance mode direttamente dal cdrom di installazione (senza richiesta di password). A volte è l'unico metodo per recuperare un sistema inaccessibile (password persa, shell di root mancante ecc., disco di boot danneggiato...)
boot -a
Carica in modo interattivo, chiedendo informazioni su quali device e in quali directory cercare kernel, moduli e file di configurazione del kernel
boot -r
Esegue un boot di riconfigurazione, utile per identificare nuovi device attaccati al sistema
boot -V
(o anche boot -rV, boot -sV) Visualizza informazioni di debugging
boot net - install
Procede all'installazione del sistema operativo tramite un Jumpstart server in rete
printenv
Visualizza i parametri salvati nella NVRAM con i valori correnti e quelli di default.
setenv
Modifica i alcuni parametri contenuti in NVRAM, tra cui alcuni fondamentali per gestire da dove e come fare il boot
setenv boot-device disk|net|cdrom ...
Imposta il device da cui eseguire il boot.
setenv auto-boot? true|false
Definisce se caricare automaticamente il sistema operativo ad un reset e arrestare il boot al prompt ok
setenv diag-level max|low
Imposta il livello di debug nel POST
setenv diag-switch? true|false
Definisce se eseguire il debug al POST
reset
Registra e resetta il sistema e ripetendo le sequenze di boot con i nuovi parametri settati
set-default parametro
Reimposta il parametro specificato, presente in NVRAM, al suo valore di default
set-defaults
Reimposta tutti i parametri in NVRAM ai loro valori di default
devalias
Visualizza gli alias dati ai device (es: disk, net, cdrom) e i relativi dispositivi hardware (nel formato Sun dei device tree (es: /pci@1f,0/pci@1,1/ide@3/[email protected]:f ).
Notare che i parametri settati in NVRAM possono essere modificati con il comando shell /usr/sbin/eeprom
.
Una caratteristica distintiva e particolarmente utile si sitemi Sun rispetto ad architetture Intel è la possibilità di accedere in qualsiasi momento al prompt OpenBoot, anche quando la macchina è in standby (halt) o durante il suo normale funzionamento (si può congelare ogni operazione in esecuzione e accedere da console al prompt con i tasti Stop + a
o, su terminali ASCII, mandando una seguenza BREAK
).
Sia che il boot proceda automaticamente, sia che venga arrestato al prompt di OpenBoot e poi lanciato col comando boot, viene successivamente eseguito il Primary Boot Program: bootblk
che si trova in una posizione fissa dei primi 15 blocchi del device di boot.
Boot Program Phase
bootblk entra nella sua seconda fase, in cui, viene caricato ufsboot
direttamente da una partizione UFS del sistema. Tramite l'utility Solaris installboot è possibile settare il path in cui si trova ufsboot
, il cui compito è quello di caricare ed eseguire i due file di cui è composto il kernel Solaris è composto che si trovano nella directory /platform/'uname -m'/kernel
(per sistemi a 32 bit) o /platform/'uname -m'/kernel/sparcv9
(per sistemi a 64 bit).
Il nome della piattaforma è l'output del comando uname -m. Per esempio, su una Ultra 10 è sun4u.
Kernel inizialization phase
Il kernel di Solaris è diviso in più parti:
- Un core generico, indipendente dalla piattaforma utilizzata, chiamato genunix;
- Un core platform specific, chiamato semplicemente unix, diverso a seconda dell'hardware Sun a disposizione.
- Moduli caricabili dinamicamente con driver per il supporto di hardware vario, file system diversi, classi e componenti aggiuntive del kernel.
I moduli si possono trovare nelle directory /kernel, /usr/kernel, /platform/'uname -m'/kernel, /platform/'uname -i'/kernel
in sottodirectory diverse a seconda del tipo di modulo (es: sys, misc, fs, sched, exec...).
Il kernel legge il suo file di configurazione /etc/system
in cui si possono definire:
- il PATH dove cercare i moduli (sezione moddir)
- settaggi relativi al root file system e al root device (rootfs e rootdev)
- se ci sono moduli da non caricare automaticamente (exclude)
- se ci sono moduli per cui forzare il caricamento (forceload)
- parametri da passare al kernel per modificarne il comportamento (set seguito da coppie parametro=valore)
Prima di modificare /etc/system
è raccomandabile crearne copie di backup (es: /etc/system.orig
) che possono, in caso di maldestre modifiche dell'/etc/system originale, essere richiamate dal PROM digitando boot -a
).
Init phase
Caricato il kernel, le operazioni passano a init
che basandosi sul file di configurazione /etc/inittab
esegue diversi script e lancia tutti gli altri processi necessari per il completamento del caricamento.
A seconda del run-level impostato come default in inittab vengono eseguiti i relativi run control (rc) scripts.
La sintassi del file di configurazione di Init su Solaris è uguale a quella di Init su Linux e altri Unix, quello che cambia sono i singoli script di inizializzazione eseguiti e le loro operazioni.
Notare le righe in /etc/inittab impostate con action sysinit: definiscono quali script vengono sempre lanciati, nella sequenza indicata, a prescindere dal run level.
Agli script rc (/sbin/rc0, /sbin/rc1, /sbin/rc2 ...
) corrispondono le directory in cui sono contenuti i symlink che gestiscono l'avvio o lo stop dei singoli servizi (/etc/rc0.d, /etc/rc1.d, /etc/rc2.d ...
puntando agli script di gestione che si trovano in /etc/init.d/
.
Descrizione del processo di boot su sistemi Intel: ROM BIOS - LINUX LOADER - KERNEL LOADING - INIT
Guida a SOLARIS (per Sysadm Linux)Guida all'uso e alla logica di Sun Solaris per system administrator Unix / Linux.
bug
set-default non è corretto ci vuole set-defaults
Molto utile davvero questo articolo visto che era la prima volta che accedevo ad una macchina sun non funzionante
RC scripts
In realta' quelli che si trovano sotto /etc/rcX.d non dovrebbero essere dei symlinks, ma degli hardlink agli script che si trovano in /etc/init.d, nonostante dal punto di vista funzionale vanno bene anche i symlink