<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>The Linux Kernel HOWTO: Alcuni trabocchetti </TITLE>
<LINK HREF="Kernel-HOWTO-9.html" REL=next>
<LINK HREF="Kernel-HOWTO-7.html" REL=previous>
<LINK HREF="Kernel-HOWTO.html#toc8" REL=contents>
</HEAD>
<BODY>
<A HREF="Kernel-HOWTO-9.html">Avanti</A>
<A HREF="Kernel-HOWTO-7.html">Indietro</A>
<A HREF="Kernel-HOWTO.html#toc8">Indice</A>
<HR>
<H2><A NAME="s8">8. Alcuni trabocchetti </A></H2>
<P>
<P>
<H2><A NAME="ss8.1">8.1 make clean </A>
</H2>
<P>Se il proprio nuovo kernel fa veramente cose strane dopo un aggiornamento,
c'è la possibilità che si sia dimenticato di fare <CODE>make clean</CODE>
prima di compilare il nuovo kernel. I sintomi possono essere
qualsiasi, da crash senza motivo a strani problemi di I/O, fino a
prestazioni pietose. Ci si assicuri di fare anche un <CODE>make dep</CODE>.
<P>
<P>
<H2><A NAME="ss8.2">8.2 Kernel grossi o lenti </A>
</H2>
<P>Se il proprio kernel si piglia un sacco di memoria, è troppo grande
o ci mette un'eternità per compilarsi anche se si è preso il nuovo
Quadbazillium-III/4400, probabilmente si sono configurate un sacco di
cose non necessarie (device driver, filesystem ecc). Se non le si
usa, non le si selezioni, perché non fanno altro che occupare memoria.
Il sintomo più ovvio di un kernel cicciotto è il continuo swap tra la
memoria e il disco; se il proprio disco sta facendo un sacco di rumore
e non è uno di quei vecchi Fujitsu Eagles, che sembrano jet che
atterrano quando vengono spenti, si dia un'occhiata alla
configurazione del kernel.
<P>
<P>Si può scoprire quanta memoria sta usando il kernel prendendo il
totale della memoria nella propria macchina e sottraendogli
l'ammontare di "total mem" in <CODE>/proc/meminfo</CODE> o l'output del
comando "<CODE>free</CODE>".
<P>
<P>
<H2><A NAME="ss8.3">8.3 La porta parallela non funziona/la mia stampante non funziona</A>
</H2>
<P>
<P>Le opzioni di configurazioni per i PC sono: innanzitutto, sotto la categoria
"General Setup", si selezioni "Parallel port support" e "PC-style hardware".
Poi sotto "Character devices", si selezioni "Parallel printer support".
<P>Poi ci sono i nomi. In Linux 2.2 i nomi dei file di device sono diversi
da quelli delle release precedenti. Come risultato finale, se si aveva un <CODE>lp1</CODE>
sotto il proprio vecchio kernel, probabilmente si chiama <CODE>lp0</CODE> per quello nuovo.
Si usi "<CODE>dmesg</CODE>" o si dia una scorsa ai log in <CODE>/var/log</CODE> per capire il
problema.
<P>
<P>
<H2><A NAME="ss8.4">8.4 Il kernel non si compila </A>
</H2>
<P>
<P>Se non si compila, allora probabilmente una patch ha fallito o i
propri sorgenti sono in qualche modo corrotti. Inoltre potrebbe non
essere corretta la propria versione di gcc, o potrebbe essere essa
stessa corrotta (per esempio, i file include potrebbero contenere
degli errori). Ci si assicuri che i link simbolici che Linus descrive
nel <CODE>README</CODE> siano impostati correttamente. In generale, se un
kernel standard non si compila, nel sistema c'è qualcosa di davvero
sbagliato ed è probabilmente necessaria la reinstallazione di alcuni
strumenti.
<P>
<P>In alcuni casi, gcc può andare in crash a causa di problemi hardware.
Il messaggio d'errore è qualcosa di simile a "xxx exited with signal
15" e in genere sembrerà molto misterioso. Probabilmente non lo
menzionerei se non mi fosse successo una volta: avevo della memoria
cache difettosa e il compilatore occasionalmente andava in palla a
caso. Si provi per prima cosa a reinstallare gcc se si è soggetti al
problema. Si dovrebbe essere sospettosi solo se il kernel si compila
bene disabilitando la cache esterna, con un ammontare di RAM ridotto,
ecc.
<P>
<P>Suggerire alla gente che il loro hardware ha dei problemi tende a disturbare i sonni.
Bene, non lo farò più. C'è una FAQ per questo: <CODE>http://www.bitwizard.nl/sig11/</CODE>.
<P>
<P>
<H2><A NAME="ss8.5">8.5 La nuova versione del kernel sembra non riuscire ad avviarsi</A>
</H2>
<P>
<P>Non si è lanciato LILO o non lo si è configurato correttamente. Una
cosa che mi ha fregato una volta è stato un problema nel file di
configurazione; diceva "<CODE>boot = /dev/hda1</CODE>" invece di "<CODE>boot
= /dev/hda</CODE>" (questa cosa potrebbe essere un po' noiosa
all'inizio ma una volta che si ha un file di configurazione
funzionante, non sarà più necessario modificarlo).
<P>
<P>
<H2><A NAME="ss8.6">8.6 Si è dimenticato di lanciare LILO oppure il sistema proprio non si avvia</A>
</H2>
<P>
<P>Ooops! La cosa migliore che si può fare qui è di fare il boot da un dischetto o da un
CDROM e preparare un altro dischetto avviabile (come farebbe "<CODE>make zdisk</CODE>").
È necessario sapere dov'è il proprio filesystem di root (<CODE>/</CODE>) e di quale tipo
è (e.g. ext2, minix). Nell'esempio seguente è necessario conoscere anche il filesystem
in cui risiede il proprio albero dei sorgenti <CODE>/usr/src/linux</CODE>, il suo tipo e
dov'è normalmente montato.
<P>
<P>Nell'esempio seguente <CODE>/</CODE> è <CODE>/dev/hda1</CODE> e il filesystem che contiene
<CODE>/usr/src/linux</CODE> è <CODE>/dev/hda3</CODE>, normalmente montato in <CODE>/usr</CODE>.
Entrambi sono filesystem ext2. L'immagine del kernel funzionante è in
<CODE>/usr/src/linux/arch/i386/boot</CODE> ed è chiamata <CODE>bzImage</CODE>.
<P>
<P>L'idea è che se esiste un <CODE>bzImage</CODE> funzionante, è possibile usarlo per un nuovo
dischetto. Un'altra alternativa, che potrebbe funzionare bene o no (dipende dal modo in
cui si è incasinato il proprio sistema) è discussa dopo l'esempio.
<P>
<P>Per prima cosa si avvii combinando un dischetto di boot e uno di root,
oppure da un dischetto di recupero, e si monti il filesystem che contiene
l'immagine del kernel funzionante:
<P>
<P>
<PRE>
mkdir /mnt
mount -t ext2 /dev/hda3 /mnt
</PRE>
<P>Se <CODE>mkdir</CODE> dice che la directory esiste già semplicemente si
ignori l'errore. Ora, si vada nella directory dove si trova il
kernel funzionante. Si noti che
<PRE>
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot
</PRE>
Si inserisca un dischetto formattato nel drive A: (non il proprio
dischetto di boot o di root!), si scarichi l'immagine nel dischetto e lo si
configuri per il proprio filesystem di root:
<P>
<P>
<PRE>
cd /mnt/src/linux/arch/i386/boot
dd if=bzImage of=/dev/fd0
rdev /dev/fd0 /dev/hda1
</PRE>
<P>Si dia "<CODE>cd /</CODE>" e si smonti il filesystem <CODE>/usr</CODE> normale:
<P>
<PRE>
cd /
umount /mnt
</PRE>
<P>Ora si dovrebbe essere in grado di riavviare il proprio sistema
normalmente da questo dischetto. Non si dimentichi di lanciare lilo (o
correggere qualsiasi altra cosa che si è fatto di sbagliato) dopo aver
riavviato!
<P>
<P>Come menzionato in precedenza c'è un'altra alternativa comune. Se
capita di avere un'immagine funzionante del kernel in <CODE>/</CODE>
(<CODE>/vmlinuz</CODE> per esempio), la si può usare per un dischetto di
boot. Si suppongano tutte le condizioni precedenti e che la nostra
immagine del kernel sia <CODE>/vmlinuz</CODE>, si facciano solamente le
seguenti modifiche all'esempio precedente: si cambi <CODE>/dev/hda3</CODE>
in <CODE>/dev/hda1</CODE> (nel filesystem <CODE>/</CODE>),
<CODE>/mnt/src/linux</CODE> in <CODE>/mnt</CODE>, e <CODE>if=bzImage</CODE> in
<CODE>if=vmlinuz</CODE>. La nota che spiega come derivare
<CODE>/mnt/src/linux</CODE> può essere ignorata.
<P>
<P>L'uso di LILO con dischi grossi (più di 1024 cilindri) può causare
problemi. Si veda il LILO mini-HOWTO o la documentazione per aver
aiuto in proposito.
<P>
<P>
<H2><A NAME="ss8.7">8.7 Dice `warning: bdflush not running' </A>
</H2>
<P>
<P>Questo può essere un problema serio. A partire dalle release del
kernel dopo la 1.0 (attorno al 20 aprile 1994), è stato
aggiornato/rimpiazzato un programma chiamato "<CODE>update</CODE>" che
scarica periodicamente i buffer del filesystem. Si prendano i
sorgenti di "<CODE>bdflush</CODE>" (lo si dovrebbe trovare dove si sono
presi i sorgenti del kernel) e lo si installi (probabilmente è meglio
far funzionare il sistema con il vecchio kernel mentre lo si fa). Si
installa come "<CODE>update</CODE>" e dopo un riavvio, il nuovo kernel non
dovrebbe più protestare.
<P>
<P>
<H2><A NAME="ss8.8">8.8 Non riesco a far funzionare il mio lettore CD-ROM IDE/ATAPI</A>
</H2>
<P>
<P>Piuttosto strano, ma un sacco di gente non riesce a far funzionare i
loro lettori ATAPI, probabilmente perché ci sono un po' di cose che
vanno storte (NdT non succede praticamente più al giorno d'oggi).
<P>Se il proprio CD-ROM è il solo dispositivo in una particolare
interfaccia IDE, dovrebbe essere impostato come "master" o
"single". Questo è l'errore più comune.
<P>Creative Labs (per dirne una) ora ha messo interfacce IDE sulle sue
schede audio. Comunque, questo porta all'interessante problema che
mentre alcuni hanno solo una interfaccia, molti hanno due interfacce
IDE integrate nelle loro schede madri (solitamente all'IRQ15), così è
pratica comune rendere l'interfaccia della soundblaster una terza porta
IDE (IRQ11).
<P>Ciò causa problemi con Linux in quelle versioni 1.2.x che non
supportano una terza interfaccia IDE (c'è il supporto a partire da
qualche parte nella serie 1.3.x, ma si ricordi che è in sviluppo ed
inoltre non rileva automaticamente le interfacce). Per
andare a capo di questa cosa non si hanno molte scelte.
<P>Se si ha già una seconda porta IDE, è possibile che non la si stia
usando o che non abbia già connessi due dispositivi. Si tolga il
lettore ATAPI dalla scheda audio e lo si metta nella seconda
interfaccia. Si può poi disabilitare l'interfaccia della scheda
audio, il che fa risparmiare anche un IRQ.
<P>Se non si ha una seconda interfaccia, si configuri (con i ponticelli)
l'interfaccia della scheda audio (non la parte relativa alla scheda
audio) come IRQ15, la seconda interfaccia. Dovrebbe funzionare.
<P>
<P>
<H2><A NAME="ss8.9">8.9 Dice strane cose a proposito di richieste di instradamento </A>
</H2>
<P>
<P>Ci si procuri una nuova versione del programma <CODE>route</CODE> e di
qualsiasi altro programma per manipolare gli instradamenti.
<CODE>/usr/include/linux/route.h</CODE> (che in realtà è un file in
<CODE>/usr/src/linux</CODE>) è cambiato.
<P>
<P>
<H2><A NAME="ss8.10">8.10 Il firewall non funziona in 1.2.0</A>
</H2>
<P>Si aggiorni almeno alla versione 1.2.1.
<P>
<P>
<H2><A NAME="ss8.11">8.11 "Not a compressed kernel Image file"</A>
</H2>
<P>
<P>
<P>Non si usi il file <CODE>vmlinux</CODE> creato in <CODE>/usr/src/linux</CODE>
come immagine di boot; quello giusto è <CODE>[..]/arch/i386/boot/bzImage</CODE>.
<P>
<P>
<H2><A NAME="ss8.12">8.12 Problemi con i terminali console dopo l'aggiornamento al 1.3.x</A>
</H2>
<P>Si cambi la parola <CODE>dumb</CODE> in <CODE>linux</CODE> nella voce termcap
della console in <CODE>/etc/termcap</CODE>. Si potrebbe dover pure creare
una voce terminfo.
<P>
<P>
<H2><A NAME="ss8.13">8.13 Non riesco più a compilare quasi niente dopo l'aggiornamento del kernel</A>
</H2>
<P>I sorgenti del kernel Linux includono numerosi file include (quelle cose
che finiscono con <CODE>.h</CODE>) ai quali viene fatto riferimento dagli
include standard in <CODE>/usr/include</CODE>. Solitamente ne viene fatto
riferimento in questo modo (dove <CODE>xyzzy.h</CODE> vorrebbe essere
qualcosa in <CODE>/usr/include/linux</CODE>):
<PRE>
#include <linux/xyzzy.h>
</PRE>
Solitamente c'è un link chiamato <CODE>linux</CODE> in
<CODE>/usr/include</CODE> alla directory <CODE>include/linux</CODE> del propri
sorgenti del kernel (in un sistema tipico
<CODE>/usr/src/linux/include/linux</CODE>). Se non c'è questo link, o
punta in un posto sbagliato, la maggior parte delle cose non si
compileranno affatto. Se si è deciso che i sorgenti del kernel
occupano troppo spazio su disco e li si è cancellati allora ovviamente
il problema sarà questo. Un'altra cosa che potrebbe non andare bene
sono i permessi dei file; se <CODE>root</CODE> ha una
umask che per default non permette agli altri utenti di vedere i suoi
file e si sono estratti i sorgenti del kernel senza l'opzione
<CODE>p</CODE> (preserva i permessi dei file), quegli utenti non saranno
in grado di usare il compilatore C. Sebbene per correggere questa cosa
si possa usare il comando <CODE>chmod</CODE>, probabilmente è più facile
riestrarre i file include. Lo si può fare nello stesso modo dei sorgenti
completi all'inizio, aggiungendo solamente un argomento.
<P>
<PRE>
blah# tar zxvpf linux.x.y.z.tar.gz linux/include
</PRE>
Nota: "<CODE>make config</CODE>" creerà il link <CODE>/usr/src/linux</CODE>
se non c'è.
<P>
<P>
<H2><A NAME="ss8.14">8.14 Incrementare i limiti</A>
</H2>
<P>I pochi comandi di <I>esempio</I> che seguono possono essere utili a
quanti si domandano come incrementare alcuni limiti imposti dal kernel:
<PRE>
echo 4096 > /proc/sys/kernel/file-max
echo 12288 > /proc/sys/kernel/inode-max
echo 300 400 500 > /proc/sys/vm/freepages
</PRE>
<P>
<P>
<HR>
<A HREF="Kernel-HOWTO-9.html">Avanti</A>
<A HREF="Kernel-HOWTO-7.html">Indietro</A>
<A HREF="Kernel-HOWTO.html#toc8">Indice</A>
</BODY>
</HTML>
