Problemi comuni e cose di cui non si capisce il motivo

Circa alla versione 1.3.80 del kernel, il codice per la gestione delle reti fu cambiato per permettere il caricamento di famiglie di protocolli (per esempio IPX, AX.25 e AppleTalk) come moduli. Ciò causò l'aggiunta di una nuova richiesta di kerneld: net-pf-X, dove X è un numero che identifica il protocollo (vedi /usr/src/linux/include/linux/socket.h per il significato dei vari numeri). Sfortunatamente ifconfig provoca in modo accidentale questi messaggi, cosicché molte persone ottengono un paio di messaggi di log quando il sistema viene avviato e viene lanciato ifconfig per configurare la periferica di loopback. I messaggi non indicano nulla di pericoloso ed è possibile disabilitarli aggiungendo le linee:

        alias net-pf-3 off      # Forget AX.25
        alias net-pf-4 off      # Forget IPX
        alias net-pf-5 off      # Forget AppleTalk

a /etc/conf.modules. Ovviamente, se si utilizza IPX come modulo, non si deve aggiungere la linea che lo disabilita.

Ci sono stati un paio di casi riportati per questo problema. Sembra essere dovuto ad una sfortunata interazione fra kerneld e lo script tkPPP che viene usato su alcuni sistemi per impostare e monitorare la connessione PPP. Apparentemente lo script si morde la coda mentre esegue ifconfig. Questo richiama kerneld per cercare i moduli net-pf-X (vedi sopra), tenendo il sistema in sovraccarico e generando, eventualmente, un sacco si messaggi del tipo Cannot locate module for net-pf-X nel log di sistema. Non si conosce alcun modo per aggirare il problema, se non quello di evitare tkPPP o di cambiarlo usando qualche altro modo per tenere sotto controllo la connessione.

Aggiungere una voce per il proprio adattatore SCSI al file /etc/conf.module. Si veda la descrizione della voce scsi_hostadapter più sopra.

Questo è un errore nelle utility dei moduli che si verifica solo con le binutils 2.6.0.9 e seguenti e che è anche documentato nelle note per le binutils. Si legga il documento in proposito oppure ci si procuri un aggiornamento per le utility dei moduli che porgano rimedio.

Le impostazioni per un modulo sono salvate all'interno del modulo stesso quando viene caricato. Così, quando kerneld auto-scarica un modulo, ogni impostazione fatta viene dimenticata e la volta successiva il modulo ritorna alle impostazioni di default.

Si può dire a kerneld di configurare un modulo eseguendo un programma dopo che il modulo è stato auto-caricato. Vedere il comando pre/post-install alla voce post-install.

Non è possibile. Nessuna delle versioni di dosemu (ufficiali o di sviluppo) supporta il caricamento dei moduli di dosemu attraverso kerneld. Però, se si utilizza un kernel 2.0.26 o successivi, non c'è più bisogno di alcun modulo speciale dosemu. Semplicemente aggiornarsi alla versione 0.66.1.

Quando il kernel invia una richiesta a kerneld, si aspetta di ottenere un «ricevuto» entro un secondo. Se kerneld non invia questo riscontro, il messaggio d'errore viene registrato nel log di sistema. La richiesta viene ritrasmessa e dovrebbe finalmente arrivare a destinazione.

Questo di solito capita su sistemi con un carico elevato. Poiché kerneld è un processo eseguito in modalità utente, esso viene «schedulato» come ogni altro processo sul sistema. In momenti di alto carico, può non riuscire ad inviare per tempo il «ricevuto», prima che scada il tempo per kernel.

Se questo accade anche quando il carico è scarso, si provi a far ripartire kerneld. Uccidere il processo kerneld e farlo ripartire ancora con il comando /usr/sbin/kerneld. Se il problema persiste, si dovrebbe inviare un messaggio con l'errore a <linux-kernel@vger.rutgers.edu>, ma si prega di accertarsi che la propria versione di kernel, kerneld e delle utility per i moduli sia aggiornata prima di spedire messaggi sul problema. Controllare i prerequisiti in linux/Documentation/Changes.

Ci sono stati un certo numero di casi riportati per i quali il comando mount(8) non aspettava che kerneld finisse di caricare il modulo del filesystem. lsmod mostra che kerneld carica il modulo e, ripetendo il comando mount subito dopo, questo in effetti viene fatto. Questo sembra essere dovuto ad un errore nella versione 1.3.9f delle utility per i moduli che affligge alcuni utenti Debian. Può essere eliminato procurandosi una versione successiva delle utility per i moduli.

È necessario compilare le utility per ncpfs con l'opzione -DHAVE_KERNELD. Vedere il Makefile di ncpfs.

Si sta usando un versione delle utility per smbmount troppo vecchia. Ci si procuri l'ultima versione (0.10 o successive) dall'archivio SMBFS su TSX-11

Non è possibile rendere modulare tutto: il kernel deve avere abbastanza driver compilati normalmente affinché sia capace di fare il mount del ilesystem principale ed eseguire i programmi necessari ad avviare kerneld[1]. Così non puoi rendere modulare:

• il driver per l'hard-disk sul quale risiede il filesystem principale;

• il driver del filesystem stesso;

• il caricatore del formato binario di init, kerneld e altri programmi.

Le versioni più recenti di kerneld hanno bisogno delle librerie dbm della GNU, le libgdbm.so, per girare. Molte installazione hanno questo file in /usr/lib, mentre si sta probabilmente lanciando kerneld prima che il filesystem per /usr sia stato montato. Un sintomo di questo è che kerneld non parte durante l'avvio (dagli script rc), ma va bene se lo si lancia manualmente dopo che il sistema è partito. La soluzione consiste nello spostare l'avvio di kerneld dopo che sia stato fatto il mount di /usr oppure spostare la libreria gdbm sul filesystem principale, per esempio in /lib.

L'installazione Slackware (possibilmente altre) crea un file /etc/rc.d/rc.modules che opera un esplicito modprobe su una varietà di moduli. Quali moduli esattamente vengano testati dipende dalla configurazione originale del kernel. Probabilmente si è riconfigurato il kernel escludendo uno o più dei moduli che vengono testati nel proprio rc.modules, da cui il messaggio/i di errore. Aggiornare il proprio rc.modules commentando ogni modulo che non viene più utilizzato, o cancellare rc.modules completamente e lasciare che kerneld carichi i moduli quando ne ha bisogno.

Probabilmente il kernel è stato riconfigurato/ricompilato escludendo alcuni moduli, ma ci sono ancora alcuni vecchi moduli non più utilizzati sparsi in giro per la directory /lib/modules. La soluzione più semplice è quella di cancellare la directory /lib/modules/x.y.z e dare un altro make modules_install dalla directory dei sorgenti del kernel. Nota che questo problema capita solo quando si riconfigura il kernel senza cambiare versione. Se si nota questo errore quando si sta eseguendo un aggiornando ad una versione più nuova, il tipo di problema è un altro.

Numeri dispari di Linux sono kernel di sviluppo. Come tale ci si può aspettare che le cose si rompino da una volta all'altra. Una delle cose che è cambiata in maniera significativa è il modo con il quale vengono trattati i moduli e dove il kernel e i moduli vengono caricati in memoria.

In breve, se si desidera utilizzare i moduli con un kernel di sviluppo, si deve:

• leggere il file Documentation/Changes e vedere quali pacchetti hanno bisogno di essere aggiornati sul tuo sistema

• usare l'ultimo pacchetto modutils, disponibile sotto AlphaBits da Red Hat o dal sito mirror TSX-11

Si raccomanda di utilizzare almeno un kernel 2.1.29 se si desidera usare i moduli con un kernel 2.1.

kerneld originariamente aveva qualche supporto per stabilire una connessione di rete in dial-up su richiesta; provando a spedire pacchetti ad una rete senza essere connessi, faceva lanciare a kerneld lo script /sbin/request_route per istituire la connessione PPP o SLIP.

Questo si rivelò essere una cattiva idea. Alan Cox, uno dei famosi nel networking di Linux, scrisse sulla mailing-list linux-kernel:

Il materiale su request_route è obsoleto, inefficiente e inutile [...]. Inoltre è stato rimosso dall'albero 2.1.x.

Invece di usare lo script request-route e kerneld, consiglio vivamente di installare il pacchetto diald di Eric Schenk.