Se il proprio nuovo kernel fa veramente cose strane dopo un upgrade,
c'è la possibilità che si sia dimenticato di fare make clean
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 make dep.
Se il proprio kernel si succhia un sacco di memoria, è troppo grande e/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 configuri, 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.
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 /proc/meminfo o l'output del
comando `free'.
Le opzioni di configurazioni per i PC sono: primo, sotto la categoria `General Setup', si selezioni `Parallel port support' e `PC-style hardware'. Poi sotto a `Character devices', si selezioni `Parallel printer support'.
Poi ci sono i nomi. Linux 2.2 chiama il dispositivo della stampante
in maniera differente dalle release precedenti. Come risultato
finale, se si aveva un lp1 sotto il proprio vecchio kernel,
probabilmente è un lp0 in quello nuovo. Si usi
`dmesg' o si dia una scorsa ai log in /var/log per
capire il problema.
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 README siano impostati correttamente. In generale, se un
kernel standard non si compila, nel sistema c'è qualcosa di seriamente
sbagliato, ed è probabilmente necessaria la reinstalazione di alcuni
strumenti.
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 difettata 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.
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 --
è a http://www.bitwizard.nl/sig11/.
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 `boot = /dev/hda1' invece di `boot
= /dev/hda' (questa cosa potrebbe essere un po' noisosa
all'inizio ma una volta che si ha un file di configurazione
funzionante, non sarà più necessario modificarlo).
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 `make zdisk'). È necessario conoscere dov'è il
proprio filesystem di root (/) e di quale tipo è (e.g. second
extended, minix). Nell'esempio seguente è necessario conoscere anche
il filesystem in cui risiede il proprio albero dei sorgenti
/usr/src/linux, il suo tipo e dov'è normalmente montato.
Nell'esempio seguente / è /dev/hda1 e il
filesystem che contiene /usr/src/linux è /dev/hda3,
normalmente montato in /usr. Entrambi sono filesystem
second extended. L'immagine del kernel funzionante è in
/usr/src/linux/arch/i386/boot ed è chiamata
bzImage.
L'idea è che se esiste un bzImage funzionante, è possibile
usarlo per un nuovo dischetto. Un'altra alternativa, che potrebbe o
no funzionare bene (dipende dal modo in cui si è incasinato il proprio
sistema) è discussa dopo l'esempio.
Per prima cosa si avvii dalla combinazione di un boot e un root disk, oppure da un rescue disk, e si monti il filesystem che contiene l'immagine del kernel funzionante:
mkdir /mnt
mount -t ext2 /dev/hda3 /mnt
Se mkdir dice che la directory esiste già semplicemente si
ignori l'errore. Ora, si faccia cd nel posto dov'era il
kernel funzionante. Si noti che
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/bootSi piazzi un dischetto formattato nel drive A: (non il proprio boot o root disk!), di scarichi l'immagine nel dischetto e lo si configuri per il proprio filesystem di root:
cd /mnt/src/linux/arch/i386/boot
dd if=bzImage of=/dev/fd0
rdev /dev/fd0 /dev/hda1
Si faccia cd in / e si smonti il filesystem
/usr normale:
cd /
umount /mnt
Ora si dovrebbe essere in grado di riavviare il proprio sistema normalmente da questo floppy. Non si dimentichi di lanciare lilo (o correggere qualsiasi altra cosa che si è fatto di sbagliato) dopo aver riavviato!
Come menzionato in precedenza c'è un'altra alternativa comune. Se
capita di avere un'immagine funzionante del kernel in /
(/vmlinuz 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 /vmlinuz, si facciano solamente le
seguenti modifiche all'esempio precedente: si cambi /dev/hda3
in /dev/hda1 (nel filesystem /),
/mnt/src/linux in /mnt, e if=bzImage in
if=vmlinuz. La nota che spiega come derivare
/mnt/src/linux può essere ignorata.
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.
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 `update' che
scarica periodicamente i buffer del filesystem. Si prendano i
sorgenti di `bdflush' (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 `update' e dopo un riavvio, il nuovo kernel non
dovrebbe più protestare.
Piuttosto strano, ma un sacco di gente non riesce a far funzionare i loro lettori ATAPI, probabilmente perché si sono un po' di cose che vanno storte.
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.
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 un interfaccia, molti hanno due interfacce IDE integrate nelle loro schede madri (solitamente all'IRQ15), così è pratica comune rendere l'interfaccia della soundblaster un terza porta IDE (IRQ11).
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 fa la rilevazione automatica delle interfacce). Per andare a capo di questa cosa non si hanno molte scelte.
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.
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.
Ci si procuri una nuova versione del programma route e di
qualsiasi altro programma per manipolare gli instradamenti.
/usr/include/linux/route.h (che in realtà è un file in
/usr/src/linux) è cambiato.
Si aggiorni almeno alla versione 1.2.1.
``Non è un file Immagine del kernel compressa''
Non si usi il file vmlinux creato in /usr/src/linux
come propria immagine di boot; quello giusto è
[..]/arch/i386/boot/bzImage.
Si cambi la parola dumb in linux nella voce termcap
della console in /etc/termcap. Si potrebbe dover pure creare
una voce terminfo.
Il sorgenti del kernel linux includono numerosi file include (quelle robe
che finiscono con .h) ai quali viene fatto riferimento dagli
include standard in /usr/include. Solitamente ne viene fatto
in riferimento in questo modo (dove xyzzy.h vorrebbe essere
qualcosa in /usr/include/linux):
#include <linux/xyzzy.h>
Solitamente c'è un link chiamato linux in
/usr/include alla directory include/linux del propri
sorgenti del kernel (in un sistema tipico
/usr/src/linux/include/linux). 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 il proprio utente root 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
p (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 chmod, probabilmente è più facile
riestrarre i file include. Lo si può fare nello stesso modo in cui lo
si è fatto i sorgenti completi all'inizio, aggiungendo solamente un
argomento.
blah# tar zxvpf linux.x.y.z.tar.gz linux/include
Nota: ``make config'' creerà il link /usr/src/linux
se non c'è.
I pochi comandi di esempio che seguono possono essere utili a quanti si domandano come incrementare alcuni limiti imposti dal kernel:
echo 4096 > /proc/sys/kernel/file-max echo 12288 > /proc/sys/kernel/inode-max echo 300 400 500 > /proc/sys/vm/freepages