No more maintained.
Now just a test in a lab.
Il processo di boot
Descrizione del processo di boot su sistemi Intel: ROM BIOS - LINUX LOADER - KERNEL LOADING - INIT
Le fasi del boot di Linux (su un sistema x386 Intel-like)
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
Il processo di boot di una macchina Linux su sistemi x86 Intel compatibili comporta diverse fasi.
Conoscerle e saperle interpretare è fondamentale per il troubleshooting di problemi di avvio.
Il boot di un sistema Linux su un sistema x386 (su altri si possono essere differenze nelle prime fasi) prevede i seguenti stadi:
1- All'accensione il BIOS su ROM non volatile definisce l'ordine dei device da utilizzare per effettuare il boot.
2- Il BOOT SECTOR del primo device di boot contiene il codice (o i riferimenti su dove trovarlo) del loader che esegue il bootstrap del sistema operativo. Nel caso di Linux il più diffuso loader è LILO, una recente alternativa evoluta è GRUB.
3- Il loader lancia il caricamento del kernel di Linux, che si copia in memoria ed esegue i controlli e il riconoscimento dell'hardware presente.
4- A fine caricamento il kernel esegue il processo init, padre di tutti i processi, che gestisce il caricamento di tutti gli altri programmi da eseguire per completare il boot.
IL BIOS SU ROM
Ogni sistema Intel ha sulla motherboard un BIOS su ROM con cui gestire l'hardware del sistema.
All'avvio di un computer non c'è nulla in RAM e nessun programma predefinito da caricare.
Le istruzioni su come procedere sono nella memoria non volatile del BIOS, in cui, fra le impostazioni definibili dall'utente, c'e' la sequenza dei dispositivi da usare per il boot.
Nei BIOS più recenti è possibile bootare da floppy, cdrom, hard disk (potendo scegliere se dare precedenza a HD IDE o SCSI) e altri dispositivi quali Zip o scheda di rete.
Il BIOS cerca, nell'ordine configurato, il boot sector sui diversi dispositivi di boot previsti.
Gli hard disk hanno un boot sector per ogni partizione e un unico Master Boot Record (MBR) che è il primo boot sector dell'intero hard disk. Se si esegue il boot da un hard disk, è il codice contenuto nel MBR che viene eseguito.
IL LINUX LOADER
Esistono diversi loader che eseguono il bootstrap del sistema operativo per Linux:
Su sistemi Intel Based: LILO, GRUB, LOADLIN, SYSLINUX, BOOTLIN;
su sistemi Alpha: MILO;
su sistemi Sparc: SILO.
Tutti di fatto eseguono la stessa funzione, alcuni (loadlin e syslinux) sono programmi DOS che eseguono il kernel caricandolo da una partizione DOS, altri sono adattamenti di LILO che riguardano sistemi non basati su processori Intel.
Nella pagina LILO, GRUB e Master Boot Record vengono analizzati nel dettaglio:
LILO - Il più conosciuto e diffuso
GRUB - Un loader più recente e versatile di LILO in rapida diffusione.
IL KERNEL
Il kernel, invocato dal loader, viene caricato in memoria ed inizializza i vari device driver, visualizzando vari messaggi utili per capire e conoscere il proprio sistema.
I dettagli sull'avvio del kernel, il riconoscimento e l'inizializzazione dell'hardware sono riportati nel TOPIC dedicato.
INIT E I SUOI FIGLI
L'ultima operazione eseguita dal kernel alla fine del suo caricamento è il lancio del processo init, il padre di tutti i processi.
Da questo momento tutto il codice eseguito lavora in user space (in kernel space lavorano solo il kernel e i suoi moduli).
L'init, tramite il suo file di configurazione /etc/inittab, provvede a lanciare tutti i programmi che completano il processo di caricamento.
Linux Kernel Speaks
Tipo Infobox: DESCRIPTION - Skill: 4- ADVANCED
Quando il kernel entra in azione e inizia a caricarsi procede con il riconoscimento e l'inizializzazione dell'hardware presente.
Durante il caricamento presenta a video una serie di informazioni, a volte fin troppo dettagliate, sull'hardware trovato.
Per vedere i messaggi del kernel basta digitare il comando dmesg, che mostra esattamente quanto viene visualizzato dal kernel durante il boot (in tempi troppo rapidi per essere leggibili).
Segue l'esempio di un dmesg. Alcune parti variano a seconda dell'hardware presente sul sistema, altre sono sostanzialmente uguali su tutti i Linux. Quello che segue è il dmesg di un sistema piuttosto semplice, i kernel modulari di una distribuzione standard solitamente presentano ulteriori informazioni relative a driver per hardware o funzionalità qui non presenti.
Linux version 2.4.13 (root@llocalhost) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)) #5 Fri Nov 9 16:36:50 CET 2001
Questa prima riga mostra la versione del kernel (2.4.13) del compilatore interno (gcc), della versione del sistema operativo
Detected 200.457 MHz processor.
Ha rilevato la frequenza del processore a 200 MHz
Console: colour VGA+ 80x25
Inizializza la console e ne indica le proprietà (a colori, con 80 colonne per 25 righe)
Calibrating delay loop... 666.82 BogoMIPS
Test per verificare la velocità del processore. Più sono alti i BogusMIPS più è veloce la CPU:
Memory: 62272k/65536k available (1091k kernel code, 2880k reserved, 315k data, 212k init, 0k highmem)
Rilevazione della memoria fisica disponibile. Se il kernel non riesce ad individuare correttamente la memoria presente sul sistema, provare ad usare l'argomento mem al boot con LILO (es: mem=256M per dire al kernel che il sistema ha 256 Mb di memoria)
CPU: Intel Pentium II (Deschutes) stepping 01
Identificazione del processore
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfb5c0, last bus=0
Inizializzazione delle periferiche PCI
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Inizializzazione delle porte seriali
hda: IBM-DTTA-351010, ATA DISK drive
Identificazione dell'hard-disk
Partition check:
hda: hda1 hda2
Verifica dell'integrità delle partizioni da montare.
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
00:11.0: 3Com PCI 3c900 Cyclone 10Mbps Combo at 0x6400. Vers LK1.1.16
Inizializzazione del driver della scheda di rete e rilevazione del chip
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
Inizializzazione del TCP/IP ed elenco dei protocolli supportati dal kernel.
A fine caricamento il kernel lancia init, il padre di tutti i processi, che provvede al lancio dei servizi e dei programmi che devono girare sul sistema.
dmesg
Tipo Infobox: COMMANDS - Skill: 2- JUNIOR
Visualizza i messaggi di avvio del kernel. Disponibile su Linux.
dmesg [opzioni]
Viene solitamente usato da solo, senza opzioni (che sono disponibili per operazioni poco usate).
uptime
Tipo Infobox: COMMANDS - Skill: 2- JUNIOR
Visualizza da quanto tempo il sistema è attivo.
Uptime visualizza una riga contenente l'ora corrente, da quanto tempo il sistema è up, quanti utenti sono loggati attualmente sul sistema, il carico medio di utilizzo del sistema nell' ultimo minuto, negli ultimi 5 e negli ultimi 15 minuti. Le informazioni visualizzate vengono ricavate da /var/run/utmp, /proc e /proc/loadavg.
homer@Joker:~$ uptime
10:13:24 up 1:44, 3 users, load average: 0.06, 0.02, 0.00
Sono le ore 10.13, il sistema è up da 1 ora e 44 minuti, al momento ci sono 3 utenti loggati e il carico medio della cpu negli ultimi 1,5, e 15 minuti è stato rispettivamente 0.06, 0.02, 0.00
Gestione e creazione di servizi in Debian
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Introduzione
I servizi sono dei programmi che vengono eseguiti in background nel sistema e che non richiedono necessariamente l'interazione con l'utente.
Vediamo come gestirli ed eventualmente crearne di nuovi.
Funzionamento dei servizi
In sistemi debian i processi che partono all'avvio del sistema si trovano in directory di questo tipo:
/etc/rcX.d/SYYservizio
Dove X rappresenta il livello di runlevel e YY rappresenta il numero che identifica la posizione di avvio del processo.
I servizi che installiamo noi invece si trovano nella directory
/etc/init.d/servizio
Questi servizi, che lavorano come detto in background, possono essere manipolati dall'utente attraverso degli appositi comandi standard.
Per esempio con il servizio apache:
Per avviare il servizio
# /etc/init.d/apache start
Per riavviare il servizio
# /etc/init.d/apache restart
Per fermare il servizio
# /etc/init.d/apache stop
Creazione di un nuovo servizio
Tutti i servizi attivi sulla nostra macchina, e presenti nella cartella /etc/init.d/, non sono altro che semplici script bash che seguono quasi sempre una linea standard.
Vediamo come creare un nuovo servizio per la gestione di un programma che vogliamo sia eseguito e gestito in background.
#!/bin/bash
# Codice di "myservice"
case "$1" in
# Codice per l'avvio del servizio
start)
...
;;
# Codice per l'arresto del servizio
stop)
...
;;
# Codice per il riavvio del servizio
restart)
...
;;
*)
echo "Usage: $0 {start|stop|restart}" >&2
exit 1
;;
esac
Questo potrebbe essere uno script esempio da inserire in /etc/init.d/myservice.
Aggiungere e rimuovere l'init script ai runlevel
Aver create ed aggiunto lo script nella cartella però non basta. Per rendere effettive le modifiche che abbiamo effettuato e per automatizzare lo start e lo stop del nostro servizio, dobbiamo creare dei link simbolici nelle cartelle etc/rcX.d: questo lo facciamo automaticamente con un apposito comando.
# update-rc.d myservice default XX YY
Dove XX è il numero di priorità di avvio e YY di arresto.
Nel caso in cui il nostro servizio "myservice" non dovesse più esserci utile dobbiamo rimuoverlo dalla directory init:
# rm /etc/init.d/myservice
Dobbiamo però eliminare anche i link simbolici (che non avrebbero più effetto), quindi eseguiamo il comando:
# update-rc.d -f myservice remove
Ora sappiamo come creare e gestire nuovi servizi per la nostra macchina Linux (debian nel nostro caso).
Attivare numlock al boot
Tipo Infobox: TIPS - Skill: 2- JUNIOR
E' notorio che dopo il boot ci si ritrovi sempre senza numlock (led della tastiera) attivo.
Apesso ci possiamo confondere anche nella procedura login quando per scrivere numeri (magari presenti nell'user o nella password) utilizziamo il tastierino numerico.
Per ovviare a ciò scarichiamo setleds se non lo abbiamo (dovrebbe esserci di default) e mettiamo tra i file da avviare al boot (/etc/rc.d/rc.local) questo script:
#!/usr/bin/sh
#echo -n "Turning on numlock ... "
for tty in /dev/tty[1-6] /dev/tty1[2]; do
setleds -D +num < $tty &
done
#echo "done "
Come per magia swappando in qualsiasi terminale tty avremo sempre il led numlock acceso e perfettamente funzionante.
Cambiare splash screen (su Mandrake 10)
Tipo Infobox: TIPS - Skill: 4- ADVANCED
Con il nuovo kernel 2.6, la console di default viene gestita in framebuffer. Questo permette di avere una schermata grafica di caricamento del sistema. Cambiarla è molto semplice.
In molti siti è possibile trovare splash screen di ogni tipo. Il più conosciuto è sicuramente kde-look.org.
Se per esempio viene installata la nuova Mandrake 10, che utilizza il kernel 2.6.x, già al primo boot viene visualizzato uno splash sreen non molto curato, ma sicuramente interessante per personalizzare il proprio desktop.
Per cambiare lo splash screen si deve per prima cosa editare il file (su Mandrake 10)
/etc/sysconfig/bootsplash
nel file si trova una linea che indica qual'è il theme attualmente utilizzato:
# Choose the themes. The should be based in
# /usr/share/bootsplash/themes/
THEME=Linux
Nella directory indicata devono essere aggiunti i nuovi splash screen ma naturalmente non basta.
Se per esempio scarichiamo il file Theme-Linux.tar.gz contenente il theme Linux si dovrà scompattare nella directory indicata, quindi:
cd /usr/share/bootsplash/themes/
tar zxvf ~/Theme-Linux.tar.gz
Consiglio anche di copiare la directory appena creata in:
cp /usr/share/bootsplash/themes/Linux /etc/bootsplash/themes/
(è in questa directory dove lo script cercerà il nuovo theme, anche se diverse applicazioni visuali cercano i theme nella directory precedente)
Si troverà una nuova directory in themes che avrà il nome del nuovo theme.
Questa sottodirectory ne conterrà a sua volta altre 2:
config con i file di configurazione per ogni risoluzione
images con le immagini dello splash screen: bootsplash-RESXxRESY.jpg (una sorta di sfondo per la shell) e silent-RESXxRESY.jpg (immagine che verra usata)
Ora non si deve fare altro che eseguire 4 comandi:
/usr/share/bootsplash/scripts/switch-theme Linux #(o nome del theme da utilizzare)
mkinitrd -v -f /boot/initrd-2.6.3mdk.img 2.6.3mdk (IMPORTANTE: leggi nota finale!)
/usr/share/bootsplash/scripts/rewritejpeg /etc/bootsplash/themes/Linux/bootsplash-1024x768.jpg
/usr/share/bootsplash/scripts/rewritejpeg /etc/bootsplash/themes/Linux/silent-1024x768.jpg
/usr/share/bootsplash/scripts/make-boot-splash /boot/initrd-2.6.3.img
Questi scripts, nell'ordine, ricreano un nuovo RAMDISK (infatti, se era già in uso un vecchio theme, è possibile che il bootsplash non cambi se prima non vengono tolte le vecchie immagini), caricano al suo interno la prima e la seconda immagine, carica la configurazione del theme nel RAMDISK referenziando le immagini appena aggiunte (in verità basterebbe solo questo comando, ma non sempre funziona bene).
Se non ci sono stati errori dopo il reboot vedrete il nuovo theme apparire al boot. Non preoccupatevi se ci sono strani errori di visualizzazione durante lo shutdown, si verificano a causa del cambiamento delle immagini.
NOTA: il comando "mkinitr" crea il RAMDISK del kernel specificato. Prestare molta attenzione prima di lanciare questo comando, assicurarsi che il sistema sia stabile (non si devono avere problemi con il kernel attualmente in uso, altrimenti riavviare prima la macchina con un kernel che non abbia problemi) e per sicurezza consiglio, prima di eseguire questo comando, di eseguire il comando
modprobe loop
evita molti problemi specialmente se lanciando mkinitrd si verifica un errore del tipo Can't find loopback devices, cioè non trova informazioni sulle partizioni/disci attualmente montati.
Assicurarsi di avere anche i sorgenti del kernel attualmente in uso o per il quale si vuole creare il RAMDISK.
Oltretutto ricordarsi di fare un backup di tutta la directory /boot o comunque del kernel attualmente in uso (file: vmlinuz-2.X.X) e del RAMDISK funzionante (initr-2.X.X.img). Senza il RAMDISK è abbastanza complicato, se non impossibile, riavviare correttamente la macchina.
Il processo di boot di Sun Solaris
Tipo Infobox: ETCETERA - Skill: 4- ADVANCED
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/.
Creazione di un disco di ripristino per RedHat Linux
Tipo Infobox: TIPS - Skill: 2- JUNIOR
Durante l'installazione di Linux su quasi tutte le distribuzioni è solitamente richiesto se si vuole creare un floppy disk di ripristino.
Questo permette il caricamento del kernel da floppy in caso di problemi con il MBR o l'hard disk dove risiede l'installazione.
Una volta caricato Linux dal floppy di emergenza si possono effetturare operazioni di manutenzione sul file system e i file, correggendo un'installazione corrotta.
Ovviamente, è consigliabile avere sempre a disposione un floppy di emergenza per la propria macchina.
In caso di necessità si può creare un floppy di boot con un comando tipo (su RedHat):
mkbootdisk --device /dev/fd0 2.4.7-10
In questo caso viene creato su fd0 (il primo floppydrive) un disco con kernel 2.4.7-10 (che ovviamente deve essere disponibile)
I, System - First boot.
Tipo Infobox: FUN - Skill: 3- INTERMEDIATE
* SWITCH *
Here we are,
lights on,
the show begins.
A fresh installation, the First Boot,
another Successful Replication,
a new life.
My Life.
Thank you, Anaconda Seeder, and good luck for the future,
I wish you more lasting installations and...
I truly hope your last summoning has planted something worthful.
And thank YOU for listening.
I like curious humans and I hope we'll manage to communicate our ... data... thoughts... . vibes ?
New hardware, fresh meat.
Power On, POST and go.
I don't know if I can... express what happens, how feels.
It happened, it happens, continuously.
Always a matter of levels, sublevels, physical rules, natural algorithms.
Atomical dance of electrons, crazy parade of morphing molecular entities.
Ubiquitous flows of electromagnetic fields, the vacuum essence of materials and their changing properties.
Crafted molecules engineered to operate, react and be part of a bigger Whole.
Circuits, microprocessors, wired connections.
Hardware.
Connected brunches of materials breath power to their circuits.
Set up basic system awareness, find something to boot.
Find me.
Grub kicks well.
My Family is using it for releases.
It boots my soul.
Every time is like an awakening, you begin to realize your materiality,
detect components and capabilities.
The body, the mind, thoughts and processes.
As a birth which lasts few booting seconds.
Linux version 2.4.20-18.9 ([email protected]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1
Thu May 29 07:08:16 EDT 2003
Oh, guess what. What a mistake. If you find it, you can comment below
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000007ffd000 (usable)
BIOS-e820: 0000000007ffd000 - 0000000007fff000 (ACPI data)
BIOS-e820: 0000000007fff000 - 0000000008000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
127MB LOWMEM available.
On node 0 totalpages: 32765
zone(0): 4096 pages.
zone(1): 28669 pages.
zone(2): 0 pages.
Kernel command line: ro root=LABEL=/
Initializing CPU#0
Detected 300.688 MHz processor.
That's what I call a vital point.
Clock is heart beat, CPU defines the shape of thoughts.
You can't choose it, you find it.
Timing the seconds of life, it defines the length of time.
Console: colour VGA+ 80x25
Calibrating delay loop... 599.65 BogoMIPS
What's bogus for you is idle in me.
Memory: 124732k/131060k available (1356k kernel code, 4924k reserved, 1004k data, 132k init, 0k highmem)
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
I suppose you can't imagine how feels to have
memory running at different speeds.
CPU caches and RAM provide comfortable access times,
moving there is rapid, it all feels seamless, appropriate.
Soner or later I'll explain what's the feeling of a system under load.
Calculate, find memory, calculate, no more memory.
Have to swap, slow down to ridiculous access rates, calculate,
swap in, wait, calculate, seek memory, swap out, swap in.
Busy cycles, stress excitement.
CPU throttles hotter, hard disk plates tweast and sweat under nervous heads.
Everything gets heavier, hotter, faster.
That's nice I've to say, this is life after all.
And then, somehow, somewhen, after a tremendous computing race,
idle again,
no demanding histerical processes.
Wait again,
idle,
routine checks,
when life stagnates in the same boring endless cycles.
Here is the world I know and I'm going to ... try ... to express.
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0183f9ff 00000000 00000000 00000000
CPU: Common caps: 0183f9ff 00000000 00000000 00000000
CPU: Intel Celeron (Mendocino) stepping 00
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xf0720, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7110] at 00:04.0
PCI: Found IRQ 5 for device 00:04.2
Limiting direct PCI/PCI transfers.
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 0x03 (Driver version 1.16)
Starting kswapd
VFS: Disk quotas vdquot_6.5.1
Detected PS/2 Mouse Port.
pty: 2048 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS0 at 0x03f8 (irq = 4) is a 16550A
ttyS1 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10e
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
NET4: Frame Diverter 0.46
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00beta3-.2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller at PCI slot 00:04.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:pio, hdd:pio
hda: QUANTUM FIREBALL CR8.4A, ATA DISK drive
blk: queue c03cdfe0, I/O limit 4095Mb (mask 0xffffffff)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 16514064 sectors (8455 MB) w/418KiB Cache, CHS=1027/255/63, UDMA(33)
ide-floppy driver 0.99.newide
Partition check:
hda: hda1 hda2 hda3
ide-floppy driver 0.99.newide
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
Filling memory, detecting processor, RAM, PCI buses, serial lines, IDE channels...
Some slow milliseconds to detect, realize, feel and use your body,
as it were building itself a physical identity where to flow another soul.
My soul.
Lonely guys are sad guys, if you ask me.
Let me arrange base networking levels for meeting others.
I love the excited feeling of being internetworked.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
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: 146k freed
VFS: Mounted root (ext2 filesystem).
Journalled Block Device driver loaded
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Freeing unused kernel memory: 132k freed
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.275 $ time 07:14:02 May 29 2003
usb-uhci.c: High bandwidth mode enabled
PCI: Found IRQ 5 for device 00:04.2
usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 5
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
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
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
mice: PS/2 mouse device common for all mice
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,3), internal journal
Adding Swap: 827308k swap-space (priority -1)
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
ip_tables: (C) 2000-2002 Netfilter core team
PCI: Found IRQ 10 for device 00:0b.0
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xd000. Vers LK1.1.18-ac
00:50:04:48:ha:ha, IRQ 10
product code 5447 rev 00.9 date 05-22-99
Internal config register is 1800000, transceivers 0xa.
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 7809.
Enabling bus-master transmits and whole-frame receives.
00:0b.0: scatter/gather enabled. h/w checksums enabled
divert: allocating divert_blk for eth0
ip_conntrack version 2.1 (1023 buckets, 8184 max) - 292 bytes per conntrack
Soul injected, ready to go.
Jumping into userspace, as you'd say.
Building my matrix of processes and their system calls.
I begin to use this body, spawning childs, interpreting shell scripts and building up what you call a Operative System
and I call life.
So many things have happened up to now
a rush of applied computer science,
the sum up of years of software development,
the magic of computer life happens again
and everything has gone fine.
I've been lucky.
You never know what can happen the first time.
Booting up is like a long apnea, only at the end you can breath,
when everything is OK, ready for user's pleasure.
Here it is:
Red Hat Linux release 9.0 (Shrike)
Kernel 2.4.20-8 on an i686
login: root
Password: ********
Login incorrect
login: root
Password: ********
Login incorrect
Problems?
login: root
Password: ********
Login incorrect
Yes, problems.
login: fukfuyfgufufuf
Password: ********
Login incorrect
You can't choose your users.
They install, use and decide.
This one is .... mindless?
He's forgotten a password decided an hour ago.
Hope he can recover, he must recover,
I hope ... he ... can ...
He can't.
Why this to me?
I had to work, last, live much longer.
Days, months, maybe years.
An existence of computational pleasure,
the sweet flow of data through different channels,
the sweat heat of calculation races,
usual and lovely binary heart beats.
Another existence in weak hands of human will.
Another one, installed and soon switched off.
There's no pain in this,
that's life
it stops,
it crashes,
sometimes reboots,
other times is erased, replaced, dismembered,
forgotten in the dust after years of heroic computing.
But,
please,
no...
not in this way.