nov 06
Oggi mi è capitata una di quelle cose che è bello dire solo quando sono finite. Stavo sistemando una serie di nuovi virtual host sul webserver di un cliente quando, del tutto improvvisamente, la macchina ha smesso di rispondere a qualsiasi forma di comando. L’ambiente bash in cui stavo digitando i miei comandi sembrava integra, nel senso che mi era possibile effettuare qualsiasi normale operazione purché non avesse a che fare con il filesystem: funzionavano perfettamente comandi come top e ps, ma era impossibile effettuare il less di un file o addirittura ottenere il man di un qualsiasi comando… In tutti i casi ottenevo un brutale e inequivocabile Input/output error, sintomo tristemente evidente di un problema sul filesystem.
Non che sia una situazione in cui mi sono trovato spesso, grazie al cielo, ma trattandosi quasi sicuramente di un problema del controller RAID e non dei dischi (entrambi nuovi di zecca) ho deciso di effettuare un reboot, ma anche questo comando restituiva il medesimo errore: non essendo disponibile in memoria in forma di processo il kernel lo deve per forza prelevare dal filesystem, quindi… Input/output error.
Fatta questa romanzesca e noiosissima introduzione, vengo al sodo e registro qui il paio di comandi con cui sono riuscito a comunicare al kernel le mie cattive intenzioni:
# echo 1 > /proc/sys/kernel/sysrq
# echo b > /proc/sysrq-trigger
Con la prima istruzione ho abilitato il flag sysrq che permette di inviare comandi direttamente al kernel, mentre la seconda istruzione costituisce a tutti gli effetti il comando di reboot. Ecco alcuni link utili per conoscere meglio questa potentissima e preziosissima modalità di interazione con il kernel di Linux:
lug 17
Attenzione! Questo è soltanto l’aggiornamento di un post pubblicato mesi fa, la cui lettura raccomando vivamente prima di procedere oltre, a meno che non si conosca già sufficientemente l’argomento. Clicca qui per accedere al vecchio post.
Fatta questa piccola – ma doverosa – premessa, ecco le istruzioni per compilare il nuovo kernel 2.6.25 per l’attuale stable release di Debian GNU/Linux (nome in codice: Etch).
Per prima cosa è necessario scaricare i sorgenti del nuovo kernel Linux 2.6.25:
# apt-get -t etch-backports install linux-source-2.6.25
Poi procediamo come di consueto:
- Spostiamoci nella directory dove sono collocati i nuovi sorgenti e scompattiamoli:
# cd /usr/src
# tar xjf linux-2.6.25.tar.bz2
# ln -s linux-2.6.25 linux
# cd /usr/src/linux
- Resettiamo (opzionale) tutti i parametri di compilazione e rivediamoli per maggiore sicurezza:
# make clean && make mrproper
# cp /boot/config-`uname -r` ./.config
# make menuconfig
- Compiliamo i sorgenti e prepariamo i pacchetti .deb:
# make-kpkg clean
# fakeroot make-kpkg --initrd --append-to-version=-tetragono kernel_image kernel_headers
- Installiamo i pacchetti .deb:
# cd ..
# dpkg -i linux-image-2.6.25-tetragono_2.6.25-tetragono-10.00.Custom_i386.deb
# dpkg -i linux-headers-2.6.25-tetragono_2.6.25-tetragono-10.00.Custom_i386.deb
Ed ecco il kernel installato e perfettamente funzionante:

That’s all, folks
feb 05
Lavoro quotidianamente con Debian Etch: la utilizzo con estrema soddisfazione sia sui server aziendali che sul notebook personale (lo stesso con cui scrivo in questo momento). Sono un convinto difensore del ramo Stable di Debian – e di qualsiasi altro sistema operativo – anche perché ne faccio un uso professionale e non mi posso permettere il lusso di perdere tempo o – peggio – di compromettere la stabilità di un sistema per testare l’ultimo gingillo. Sul mio notebook, però, mi si presenta spesso l’esigenza di sfruttare una serie di feature che sono assenti o incomplete nel kernel 2.6.18, una su tutte la possibilità di ricorrere al driver NTFS-3G per gestire al meglio le partizioni NTFS. Leggi il resto »
nov 27
Riporto qui un post comparso sul blog di O.S.Revolution datato 24 settembre. L’argomento non viene scandagliato a fondo, ma questo post può essere un buon punto di partenza per molti, quindi merita di essere letto.
Questo articolo è rivolto a chi avendo installato 2 o più Gigabyte di ram su una distro Linux a 32bit, si trova ad affrontare il problema di mancanza di ram, causa inutilizzo della stessa da parte del sistema. Prendo spunto da un articolo apparso su Linux.com su come sfruttare la ram oltre 1 GB sul pinguino a 32bit, io almeno da 2 anni compilo il mio kernel con questa feature abilitata. Leggi il resto »