Le fasi di boot

13.1 Dal BIOS al Kernel

Tutto cio' che accade quando viene avviato un sistema Linux segue una procedura standard derivato dalla procedura di inizializzazione dei sistemi Unix System V. Vediamo cosa accade quando si avvia un sistema linux partendo dall'accensione del PC. Una volta acceso il PC viene attivato il BIOS, un programma registrato permanentemente all'interno di una memoria EPROM (di sola lettura ma riprogrammabile). Il BIOS come prima cosa effettua alcune verifiche di tipo diagnostico (verifica dei dischi, della memoria etc). Una delle verifiche fondamentali effettuate dal BIOS e' la presenza di un dispositivo valido da cui caricare il sistema operativo. Seguendo la sequenza impostata durante la configurazione del BIOS, viene verificata la presenza di un floppy disk di avvio nel drive; se questo non viene trovato, viene verificata la presenza di un CD-ROM di avvio; se neanche quest'ultimo viene trovato, viene verificata la presenza di un disco fisso di avvio. Quest'ordine puo' essere modificato dall'utente in fase di configurazione del BIOS. Normalmente il CD-ROM non viene controllato e, se non viene trovato ne' il floppy disk ne' l'hard disk, il BIOS manda a video un messaggio di errore e si blocca. Il BIOS, una volta trovato il disco di avvio, se tutto e' a posto, accede al record MBR del primo disco fisso. Il record MBR (Master Boot Record) e' un record lungo solitamente 512 byte che contiene la tabella delle partizioni del disco e delle istruzioni in linguaggio macchina necessarie per caricare il boot loader, cioe' il programma di avvio che si occupa di caricare il sistema operativo nella memoria RAM. Il record MBR viene scritto sul disco durante la fase di installazione del sistema operativo. Una volta caricato il record MBR nella memoria RAM, il BIOS cede il controllo al programma in linguaggio macchina contenuto nel record MBR. Questo programma cerca il boot loader sul disco e se lo trova lo carica in memoria RAM. Su Linux sono presenti vari boot loader, tra i quali LILO, GRUB e Loadlin. LILO (LInux LOader, cioe' caricatore di linux) e' un boot loader molto diffuso. GRUB e' piu' recente di LILO e Loadlin non e' un vero e proprio boot loader, in quanto viene usato per caricare Linux da Windows (una volta avviato Windows, e' possibile lanciare il comando Loadlin per caricare Linux). Una volta copiato in RAM, il boot loader (ad esempio LILO) verifica se il nostro PC e' un sistema multiboot, cioe' se sul PC sono installati piu' di un sistema operativo. Nel caso siano presenti piu' sistemi (ad esempio Linux, Windows e MS-DOS), LILO chiede all'utente quale sistema operativo deve avviare: se l'utente sceglie di usare Linux, LILO si preoccupa di caricare il kernel di Linux (attenzione: installare un sistema operativo ed avviarlo sono due operazioni completamente diverse. Quando si installa un sistema operativo lo si salva su disco copiandolo solitamente da un CD-ROM. In questa fase viene aggiornato il record MBR. Il record MBR presente sul disco puo' far partire un solo sistema operativo. Per avere piu' sistemi operativi occorre usare un boot loader che permetta di scegliere il sistema da avviare di volta in volta. LILO e GRUB permettono questa operazione. L'avvio del sistema operativo invece, e' la fase di caricamento dello stesso nella memoria RAM. Qualsiasi programma per poter essere eseguito deve essere copiato dal disco fisso nella memoria RAM ed un sistema operativo e' composto da programmi). Se l'utente sceglie di avviare un altro sistema operativo come Windows, LILO cede il controllo del sistema a Windows. Se l'utente non risponde affatto, dopo alcuni secondi LILO carica il sistema operativo di default, cioe' il sistema preimpostato precedentemente dall'utente. L'utente puo' specificare sia il sistema di default sia il numero di secondi che LILO deve aspettare prima di caricare il sistema operativo di default. Le impostazioni per LILO vengono definite all'interno del file /etc/lilo.conf. Ecco un esempio di /etc/lilo.conf:

boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
lba32
default=linux

image=/boot/vmlinuz-2.4.0-0.43.6
label=linux
initrd=/boot/initrd-2.4.0-0.43.6.img
read-only
root=/dev/hda5

other=/dev/hda1
label=windows

In questo esempio e' possibile scegliere tra il sistema operativo Linux ed il sistema Windows. E' impostato un timeout di 50 decimi di secondo (LILO aspetta 50 decimi di secondo prima di avviare il sistema operativo di default). Per maggiori informazioni sul file di configurazione lilo.conf consultare la pagina di manuale relativa (man lilo.conf). Per modificare il file lilo.conf occorre loggarsi come root, modificare il file e rieseguire lilo. Attenzione: delle modifiche errate potrebbero compromettere l'avvio di Linux, percio' non cambiare questo file a meno che non si sappia esattamente quello che si sta facendo. Una copia di backup del file lilo.conf ed un dischetto di avvio funzionante sono delle precauzioni fondamentali in questo genere di operazioni. Ad ogni modo, tornando alla fase di avvio del sistema, quando l'utente sceglie di avviare Linux, LILO carica il kernel di Linux in memoria. Il kernel e' un file presente nella directory /boot che si chiamaa vmlinuz- (per esempio: vmlinuz-2.4.0-xx). Oltre al kernel, viene caricata in memoria anche l'immagine RAM disk iniziale. Tale immagine si chiama initrd ed e' utilizzata dal kernel per caricare in memoria tutti i driver non compilati all'interno del kernel stesso che sono necessari per avviare il sistema. Una volta caricati in memoria RAM il kernel e l'immagine RAM disk initrd, il controllo della macchina passa al kernel. Una delle prime cose che fa il kernel di Linux e' quella di commutare il processore da modalita' reale a modalita' protetta. Quando e' in azione il BIOS il sistema e' in modalita' reale. Con alcuni sistemi operativi vecchi come l' MS-DOS il processore rimane commutato in modalita' reale. Ma con i moderni sistemi operativi come Linux o Windows, il processore viene portato immediatamente in modalita' protetta. In questa modalita' non e' possibile accedere direttamente alla memoria e all'hardware del PC ma occorre passare attraverso delle chiamate al sistema operativo. In modalita' protetta un programma utente non puo' accedere direttamente al disco ad esempio, ma deve farlo chiamando alcuni servizi forniti dal sistema operativo. Il sistema operativo accedera' al disco per conto del programma utente. Il kernel configura tutti i dispositivi hardware del sistema come la memoria, i dischi, il processore, il coprocessore etc. Il kernel crea delle tabelle per la gestione della modalita' protetta, del multitasking, delle interruzioni e della memoria virtuale, decomprime l'immagine initrd la monta e carica tutti i driver necessari. Una volta configurati tutti i dispositivi, il kernel smonta l'immagine del disco initrd, crea il dispositivo root, monta la partizione di root in sola lettura e libera la memoria. Durante questa fase di verifiche e di configurazioni, il kernel controlla quanti e quali dischi fissi sono presenti, se e' presente un mouse USB, se e' presente una scheda di rete, una scheda video etc. Il kernel non puo' ricordarsi tutte queste informazioni tra un avvio e l'altro (oltretutto la configurazione potrebbe anche cambiare) percio' scandaglia il PC alla ricerca delle varie periferiche presenti. Quando ne incontra una cominciano le presentazioni. Il disco fisso dira': 'salve, sono un disco IBM modello xyz a 7200 rpm, tot cilindri, tot settori' etc, il mouse dira': 'salve, sono un mouse USB con 2 tasti ed una rotella centrale'...e via dicendo. Tutte queste informazioni vengono visualizzate sul video. Si tratta di quella serie interminabile di righe di messaggi stampate su sfondo nero. La visualizzazione di questi messaggi puo' essere messa in pausa temporaneamente per leggere piu' facilmente cio' che viene scritto a video premendo i tasti CTRL-S. Per scorrere la pagine in alto ed in basso si possono premere i tasti Shift-PageUp (Maiusc-Pag Su) e Shift-PageDown (Maiusc-Pag giu). Per uscire dalla pausa occorre premere i tasti CTRL-Q. Ad ogni modo e' sempre possibile riesaminare questi messaggi successivamente, usando il comando dmesg.

13.2 Dal Kernel a Init

Una volta effettuate tutte queste verifiche il kernel carica in memoria RAM un altro programma e gli cede il controllo del sistema. Il kernel (il cuore del sistema operativo) e' operativo, pero' occorre ancora configurare l'ambiente utente. Per far cio' il kernel carica un altro programma in memoria. Tale programma si chiama /sbin/init. Il programma init e', come si intuisce dal nome, il programma che si occupa di inizializzare il sistema operativo vero e proprio (INITialize significa inizializza). Tutto cio' che e' stato fatto fino ad ora infatti, e' stata solamente una preparazione dell'ambiente hardware (memoria, processore, dischi etc). Init e' il padre di tutti i processi di un sistema operativo Unix/Linux. Poiche' init e' il primo processo che viene attivato, il suo PID e' uguale a 1 (il PID, cioe' Process IDentifier e' il numero progressivo assegnato ad ogni processo). Le prime operazioni eseguite da init sono solitamente standard, ma le directory interessate possono variare leggermente da distribuzione a distribuzione. Secondo alcune scuole di pensiero infatti, la directory /etc dovrebbe contenere solo file di configurazione e nessuno script eseguibile, secondo altre alcuni script sono pur sempre inerenti alla configurazione del sistema e possono risiedere nella directory /etc. Ad esempio, su un sistema Red Hat, init esegue lo script /etc/rc.d/rc.sysinit che tra le altre cose imposta lo swapping e controlla il filesystem. Questo script in sostanza si occupa di tutti quei processi che devono essere eseguiti in fase di inizializzazione del sistema (come ad esempio l'impostazione dell'orologio). Successivamente init esamina il file /etc/inittab e lo esegue. Prima di analizzare cio' che e' contenuto all'interno di questo file, occorre definire il concetto di runlevel. Il runlevel (livello di esecuzione) e' uno stato, una modalita' del sistema. Esistono solitamente 6 runlevel o stati del sistema: il runlevel 0 corrisponde all'arresto del sistema, il runlevel 6 corrisponde al riavvio del sistema, il runlevel 1 corrisponde alla modalita' utente singolo (usato di solito per operazioni di manutenzione del sistema), il runlevel 3 corrisponde alla modalita' multiutente da console (cioe' con terminale testuale e senza grafica), il runlevel 5 corrisponde alla modalita' multiutente con ambiente grafico (ad esempio xdm, gdm, kdm etc). I runlevel 2 e 4 non sono predefiniti e possono essere personalizzati dall'utente. E' sempre possibile passare da un runlevel all'altro usando il programma init, ad esempio:

init 0 (arresta il sistema)
init 6 (riavvia il sistema)

Detto cio' esaminiamo il contenuto del file /etc/inittab:

id:runlevel:azione:processo

id identifica la linea del file
runlevel identifica il runlevel per cui va considerata la linea. I runlevel vengono indicati da una sola cifra, senza delimitatori
azione identifica l'azione che deve corrispondere alla linea, ad esempio fare riavviare a respawn il comando nel campo successivo, quando esiste, o a once una volta sola
processo identifica Il comando da avviare
Tra le altre cose nel file inittab viene impostato il runlevel predefinito (ad esempio, con la riga 'id:5:initdefault:' viene dichiarato come predefinito il runlevel 5). A seconda del runlevel predefinito che viene trovato in questo file, il processo init attiva o meno determinati processi. Come fa init a sapere quali processi avviare? E' semplice, li legge all'interno della directory specificata dal runlevel predefinito. Infatti all'interno della directory /etc/rc.d sono presenti tante sottodirectory quanti sono i runlevel. Esiste la directory rc1.d per il runlevel 1, la directory rc2.d per il runlevel 2, la directory rc3.d per il runlevel 3 e cosi' via. All'interno della distribuzione Mandrake, il runlevel predefinito e' il numero 5. Questo significa che il processo init, una volta appreso che 5 e' il numero del runlevel di default (letto dal file inittab), accede alla directory /etc/rc.d/rc5.d. All'interno di questa directory sono presenti gli script relativi ai servizi da avviare. Ad esempio troviamo lo script syslog per gestire il log di sistema, lo script xfs per gestire i font e via dicendo. In realta' all'interno di questa directory non troviamo dei veri e propri script ma piuttosto dei link simbolici agli script veri e propri. Ciascuna delle directory numerate contiene dei link agli script veri e propri. Volendo aggiungere un servizio per un determinato runlevel si potrebbe ad esempio creare un link simbolico allo script relativo al servizio da avviare all'interno della directory del runlevel in questione. Per convenzione i nomi dei link simbolici contenuti in queste directory iniziano con una 'S' o con una 'K'. S sta per Start (avvio) e K per kill (uccisione). Per ogni servizio infatti e' previsto uno script di avvio (il nome del link inizia per S) ed uno script di terminazione (il nome del link inizia per K). Questi link simbolici puntano agli script veri e propri che si trovano all'interno della directory /etc/rc.d/init.d. Una volta avviato il sistema e' possibile attivare o terminare manualmente un servizio tramite il comando '/etc/rc.d/init.d/nomecomando start' oppure '/etc/rc.d/init.d/nomecomando stop', dove nomecomando e' il servizio da attivare o terminare. Ciascuno dei link simbolici e' inoltre numerato progressivamente, in modo da stabilire un ordine di attivazione. E' possibile modificare l'ordine di avvio dei servizi semplicemente cambiando la numerazione dei relativi link simbolici. Infine il processo init avvia tutti i servizi contenuti all'interno della directory /etc/rc.d/rc.local (servizi specifici per quell' host). Una volta attivati i vari servizi, vengono avviati i processi /sbin/mingetty. Vengono creati tanti processi /sbin/mingetty per quante sono le console virtuali. Ad ogni runlevel corrisponde un numero predefinito di console virtuali: i runlevel 0 e 6 non dispongono di console, il runlevel 1 dispone di 1 console ed i runlevel da 2 a 5 dispongono di ben 6 console virtuali. Una console virtuale e' un terminale virtuale dal quale poter effettuare il login al sistema. Nel runlevel 5 (modalita' multiutente con grafica) viene eseguito lo script /etc/X11/prefdm. Tale script esegue il display manager predefinito (xdm, gdm o kdm) in base al contenuto della directory /etc/sysconfig/desktop.

13.3 DMESG e i messaggi del Kernel

I messaggi che scorrono a video durante la fase di boot di Linux sono scritti dal kernel. Spesso scorrono cosi' velocemente da non permetterne una attenta analisi. E' possibile ovviamente mettere in pausa la visualizzazione dei messaggi per poterli scorrere con comodita' mediante i tasti pagina su/giu', ma risulta piu' comodo esaminare i messaggi del kernel successivamente, mediante i comando dmesg. Dmesg visualizza i messaggi leggendoli dal log scritto dal kernel. Un file di log e' solitamente un file di testo dove un demone (in questo caso il kernel) annota tutto cio' che accade e che e' di sua competenza. E' possibile usare il comando: dmesg|more (o less) per visualizzare con calma le varie righe del log. A dire il vero e' possibile eliminare la visualizzazione dei messaggi prodotti a video dal kernel in fase di boot usando dei programmi particolari. Questi programmi permettono di visualizzare una barra di progressione in modalita' grafica. Ad ogni modo l'analisi dei messaggi del kernel e' importante in quanto puo' rivelare problemi o anomalie segnalate dal kernel. Comunque nella maggioranza dei casi i messaggi del kernel sono semplicemente delle segnalazioni di tipo diagnostico e non necessariamente degli errori. Vediamo un output tipico prodotto dal comando dmesg:

[1] Linux version 2.4.19-16mdk (quintela@bi.mandrakesoft.com) (gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk)) #1 Fri Sep 20 18:15:05 CEST 2002
[2] BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000027ff0000 (usable)
BIOS-e820: 0000000027ff0000 - 0000000027ff3000 (ACPI NVS)
BIOS-e820: 0000000027ff3000 - 0000000028000000 (ACPI data)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
[3] 639MB LOWMEM available.
[4] Advanced speculative caching feature not present
[5] On node 0 totalpages: 163824
zone(0): 4096 pages.
zone(1): 159728 pages.
zone(2): 0 pages.
[3] Kernel command line: auto BOOT_IMAGE=linux ro root=301 devfs=mount hdb=ide-scsi
ide_setup: hdb=ide-scsi
[4] Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
[5] Initializing CPU#0
Detected 551.268 MHz processor.
[6] Console: colour VGA 80x25
[7] Calibrating delay loop... 1097.72 BogoMIPS
[8] Memory: 645652k/655296k available (1176k kernel code, 9260k reserved, 444k data, 136k init, 0k highmem)
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
CPU: Before vendor init, caps: 0387fbff 00000000 00000000, vendor = 0
[9] CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After vendor init, caps: 0387fbff 00000000 00000000 00000000
[10] CPU serial number disabled.
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff 00000000 00000000 00000000
CPU: Common caps: 0383fbff 00000000 00000000 00000000
CPU: Intel Pentium III (Coppermine) stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
[11] Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 551.2615 MHz.
..... host bus clock speed is 100.2291 MHz.
cpu: 0, clocks: 1002291, slice: 501145
CPU0
[12] mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
[13] PCI: PCI BIOS revision 2.10 entry at 0xfb350, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
PCI: Disabling Via external APIC routing
[14] isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16)
Starting kswapd
VFS: Diskquotas version dquot_6.5.0 initialized
[] devfs: v1.12a (20020514) Richard Gooch (rgooch@atnf.csiro.au)
[] devfs: boot_options: 0x1
[] Detected PS/2 Mouse Port.
[] pty: 256 Unix98 ptys configured
[] Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
[] ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
[] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a (rev 21) IDE UDMA66 controller on pci00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
[] hda: IC35L040AVER07-0, ATA DISK drive
[] hdb: LITE-ON LTR-24102B, ATAPI CD/DVD-ROM drive
[] hdc: QUANTUM FIREBALLP LM15, ATA DISK drive
[] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 78165360 sectors (40021 MB) w/1916KiB Cache, CHS=4865/255/63, UDMA(33)
hdc: 29336832 sectors (15020 MB) w/1900KiB Cache, CHS=29104/16/63, UDMA(33)
[] Partition check:
/dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 p9 p10 >
/dev/ide/host0/bus1/target0/lun0:<6> [PTBL] [1826/255/63] p1
[] RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 blocksize
[] md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
[] NET4: Linux TCP/IP 1.0 for NET4.0
[] IP Protocols: ICMP, UDP, TCP, IGMP
[] IP: routing cache hash table of 8192 buckets, 64Kbytes
[] TCP: Hash tables configured (established 262144 bind 65536)
[] Linux IP multicast router 0.06 plus PIM-SM
[] NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
[] RAMDISK: Compressed image found at block 0
[] Freeing initrd memory: 145k freed
[] VFS: Mounted root (ext2 filesystem).
[] Mounted devfs on /dev
[] reiserfs: checking transaction log (device 03:01) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
[] Mounted devfs on /dev
[] Freeing unused kernel memory: 136k freed
[] Real Time Clock Driver v1.10e
[] usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.275 $ time 18:49:04 Sep 20 2002
usb-uhci.c: High bandwidth mode enabled
[] PCI: Found IRQ 9 for device 00:07.2
PCI: Sharing IRQ 9 with 00:07.3
usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 9
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 9 for device 00:07.3
PCI: Sharing IRQ 9 with 00:07.2
usb-uhci.c: USB UHCI at I/O 0xd800, IRQ 9
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
usbdevfs: remount parameter error
hub.c: USB new device connect on bus1/1, assigned device number 2
[] Adding Swap: 401584k swap-space (priority -1)
usb.c: USB device 2 (vend/prod 0x5fe/0x11) is not claimed by any active driver.
[] SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
Vendor: LITE-ON Model: LTR-24102B Rev: 5S57
Type: CD-ROM ANSI SCSI revision: 02
[] reiserfs: checking transaction log (device 03:0a) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
reiserfs: checking transaction log (device 03:07) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
reiserfs: checking transaction log (device 03:09) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
reiserfs: checking transaction log (device 03:06) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
usb.c: registered new driver usb_mouse
[] input0: Cypress Semi. Cypress Ultra Mouse on usb1:2.0
usbmouse.c: v1.6:USB HID Boot Protocol mouse driver
reiserfs: checking transaction log (device 03:08) ...
usb.c: registered new driver hiddev
usb.c: registered new driver hid
[] hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik
hid-core.c: USB HID support drivers
Using r5 hash to sort names
ReiserFS version 3.6.25
[] mice: PS/2 mouse device common for all mice
[] hdb: DMA disabled
[] 8139too Fast Ethernet driver 0.9.25
PCI: Found IRQ 11 for device 00:0b.0
eth0: RealTek RTL8139 Fast Ethernet at 0xe8ce9000, 00:50:fc:28:5f:ac, IRQ 11
eth0: Identified 8139 chip type 'RTL-8139C'
eth0: Setting half-duplex based on auto-negotiated partner ability 0000.
[] es1371: version v0.30 time 18:46:14 Sep 20 2002
PCI: Found IRQ 12 for device 00:0d.0
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
es1371: found es1371 rev 8 at io 0xe000 irq 12
es1371: features: joystick 0x0
[] ac97_codec: AC97 Audio codec, id: 0x4352:0x5913 (Cirrus Logic CS4297A rev A)
[] Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 564M
agpgart: Detected Via Apollo Pro chipset
agpgart: AGP aperture is 128M @ 0xd0000000
[] drm AGP 0.99 on VIA Apollo Pro @ 0xd0000000 128MB
[] drm Initialized mga 3.0.2 20010321 on minor 0
[] parport0: PC-style at 0x378 [PCSPP,EPP]
parport0: only read 126 of 1000 ID bytes
parport0: device reported incorrect length field (34950, should be 127)
parport0 (addr 0): Legacy device
parport_pc: Via 686A parallel port: io=0x378
[] lp0: using parport0 (polling).
[] inserting floppy driver for 2.4.19-16mdk
Floppy drive(s): fd0 is 1.44M
[] FDC 0 is a post-1991 82077
[] Attached scsi CD-ROM sr0 at scsi0, channel 0, id 1, lun 0
sr0: scsi3-mmc drive: 127x/40x writer cd/rw xa/form2 cdda tray
[] Uniform CD-ROM driver Revision: 3.12

[1] = versione del kernel 2.4.19-16mdk; compilatore con il quale e' stato compilato il kernel gcc version 3.2; distro Mandrake 9.0; numero di ricompilazioni del kernel 1; data di compilazione Fri Sep 20 18:15:05 CEST 2002
[2] = mappa della memoria RAM fisica cosi' come fornita dal BIOS
[3] = 639 Megabyte di memoria bassa disponibile
[4] = tecnologia advanced speculative caching non presente (l'advanced speculative caching e' un tipo di gestione della cache dei microprocessori AMD)
[5] = inizializzazione della CPU numero 1 (Linux gestisce anche sistemi multiprocessore), frequenza di clock della CPU riscontrata: 551.268 MHz
[6] = la console e' un terminale VGA a colori con 25 righe e 80 colonne
[7] = durata del loop di ritardo: 1097.72 BogoMIPS
[8] = dimensioni della memoria
[9] = CPU con 16 Kbyte di cache di primo livello e 256 Kbyte di cache di secondo livello
[10] = numero seriale della CPU disabilitato (una delle novita' dei microprocessori Intel Pentium III e' stato il numero seriale sul microprocessore. Adottato per identificare univocamente un PC in rete, secondo la Intel sarebbe servito a garantire una maggiore sicurezza nelle transazioni di commercio elettronico. Successivamente in seguito a varie polemiche in materia di privacy, tale numero venne reso disabilitato di default dalla Intel, pero' qualcuno riusci' ad abilitare tale numero in modo invisibile all'utente. Qui Linux lo disabilita). Seguono controlli ed impostazioni varie della CPU
[11] = APIC sta per Advanced Programmable Interrupt Controller (PIC avanzato, controller avanzato delgli interrupt che gestisce i sistemi multiprocessore)
[12] = Memory Type Range Registers, driver per controllare l'accesso della CPU alle zone di memoria
[13] = verifiche dei bus PCI
[14] = verifiche dei bus ISA

Inizio della guida Tipologia di comandi Indice Le fasi di boot