Dalla versione 5.0 del libro LFS, rilasciata il 5 Novembre 2003, LFS usa GRUB, invece di LILO. GRUB è stato scelto perchè non necessita di essere reinstallato, dopo un aggiornamento del kernel, ed ha una console di ripristino veramente efficace. Se la propria installazione corrente usa LILO, o comunque si preferisce usarlo, è possibile farlo, ma sarà anche necessario installare BIN86, e, per le ultime versioni di LILO, NASM. Ad ogni modo vi preghiamo di non lamentarvi, a tale riguardo, sulle mailing list di LFS, poiché in passato abbiamo avuto molte guerre di opinione sull'argomento.
Marc Heerdink forse lo ha spiegato meglio in un messaggio in lfs-dev: “Il problema è che le FAQ costituiscono un documento dinamico. Se incluse nel libro, verrebbero rilasciate solo alla successiva versione dello stesso, dal momento che esse vengono aggiornate per riflettere le domande poste circa la versione corrente del libro. Un link è meglio, cosi si hanno sempre risposte aggiornate.
L'argomento è abbastanza ben discusso qui: http://linuxfromscratch.org/pipermail/lfs-dev/2002-February/023030.html
Il libro include ed, perchè il programma “patch” lo usa per processare gli script di ed. Tuttavia, questi ultimi sono rari oggigiorno; tutti usano patch in formato diff. Ma ed ha anche altri usi:
La release di Binutils che solitamente si trova su ftp.gnu.org è comunemente conosciuta come “binutils FSF”. Anche il noto hacker H.J. Lu, tuttavia, opera dei rilasci al di fuori del repository CVS ufficiale; esse sono comunemente conosciute come “binutils HJL” e possono essere trovate, solitamente, su ftp.kernel.org. Spesso sorgono dibattiti su quale delle due versioni usare, anche a motivo del fatto che molte delle distribuzioni Linux principali tendono ad usare le buinutils HJL, nonostante esse siano tipicamente marcate come “beta”. Ecco la nostra interpretazione delle differenze tra le due:
Si noterà, nella comparazione di cui sopra, il frequente uso di parole come “solitamente” o “a volte”. Ciò dimostra come la situazione possa essere differente, a seconda del momento storico al quale ci si riferisce. Per esempio, di volta in volta ci potrà essere una nuova fiammante caratteristica in gcc o in glibc che richiede supporto da binutils; in tali occasioni si sentiranno spesso gli sviluppatori dire: “bisogna usare l'ultima versione HJL di buinutils x.y.z.a.b.”. L'unico modo per scegliere correttamente quale release usare, allora, è di:
Il punto è che i pacchetti appartenenti alla toolchain fondamentale sono strettissimamente legati tra loro e devono essere provati, per vedere se lavorano bene insieme. In pratica bisogna costruire una distribuzione completa e provarla in ogni aspetto, se si vuole essere pienamente soddisfatti. Se si seguono le mailing list dei pacchetti che riguardano il cuore del sistema per sufficiente tempo, si comprenderà subito che gli sviluppatori non si preoccupano tanto di verificare se una particolare versione di un “pacchetto A” funziona bene con un'altra specifica versione di un “pacchetto B”. In altre parole, il coordinamento delle release tra i vari progetti non è una priorità . Nella realtà, dunque, ha ragione Alan Cox, quando dice che non si può semplicemente andare su ftp.gnu.org, scaricare l'ultimo pacchetto disponibile di ogni cosa, e aspettarsi che, semplicemente, si metta a funzionare insieme agli altri.
La gestione dei pacchetti (Package Management) - al di la di quella fornita dai semplici tarball e dai makefile - esula dallo scopo del libro. Se non altro, il semplice elenco di soluzioni dovrebbe portare ad alcuni dei motivi di questa scelta. Ecco alcune delle opzioni:
Se si hanno aggiunte a questo elenco si è pregati di inviare l'id, URL, ed altre informazioni, al gestore delle FAQ o verso una appropriata mailing list, così che possa essere aggiunta qui.
La gestione dell'alimentazione (Power Management) è una funzione del kernel; bisogna attivarla nel kernel. Nel kernel 2.4 bisogna abilitare le opzioni per il supporto per la gestione dell'alimentazione (Power Management Support) sotto la voce General Setup. Per macchine più vecchie, probabilmente si vorranno le opzioni APM, mentre macchine più recenti spesso richiedono ACPI. Assicurarsi di abilitare APM o ACPI nel kernel, ma assolutamente non entrambe contemporaneamente (sono noti problemi di varia natura, in casi come questi, come il non funzionamento delle opzioni abilitate). Inoltre, provare a disabiliare SMP se si ha un solo processore; esso è noto per causare erronei spegnimenti dell'hardware. Assicurarsi di leggere l'Help fornito per ogni opzione. Dopo aver riavviato la macchina con il nuovo kernel si dovrebbe essere in grado di spegnere la macchina con il comando shutdown -h now o poweroff (leggere anche man shutdown e man halt). Se si ha compilato APM o ACPI come moduli, assicurarsi che essi siano caricati, prima di dare il poweroff. Alcune macchine vogliono APM o ACPI compilati direttamente nel kernel, poiché devono essere inizializzati durante la sequenza di avvio.
Qualunque distribuzione recente va bene. Se si hanno problemi, provare a installare e/o aggiornare i pacchetti di sviluppo (cercare quelli che iniziano per “gcc”, “glibc”, o “libstdc++” e che finiscono in ”-dev“). Se si vuole fare uso di LFS come proprio sistema principale e si vuole installarlo senza prima installare una distribuzione provare il LiveCD LFS o Knoppix.
In aggiunta alla documentazione del kernel su /usr/src/linux/Documentation o ovunque si siano scompattati i sorgenti del proprio kernel e l'help nel tool di configurazione del kernel (make menuconfig), guardare il Module-HOWTO su http://www.tldp.org/HOWTO/Module-HOWTO/.
Risposta breve: no.
Risposta lunga: probabilmente, ma solo per chi lavora al pacchetto che si sta tentando di compilare. Di solito, a meno che non ci siano interruzioni con un errore, va tutto bene.
Qui c'è un esempio:
sk ~/tmp $ cat > Makefile
main:
gcc main.c
sk ~/tmp $ cat > main.c
void main() { exit(0); }
sk ~/tmp $ make
gcc main.c
main.c: In function `main':
main.c:1: warning: return type of `main' is not `int'
sk ~/tmp $ ######## questo ha funzionato ########
sk ~/tmp $
sk ~/tmp $ cat > main.c
int main() { exxit(0) }
sk ~/tmp $ make
gcc main.c
main.c: In function `main':
main.c:1: parse error before `}'
make: *** [main] Error 1
sk ~/tmp $ ######## questo è fallito ########
sk ~/tmp $
Gerard descrive il processo di realizzazione di una installazione LFS da 5MB in una email a lfs-support, e ci sono link a molte risorse in un post di Cor Lem e una risposta ad esso.
Per informazioni sulla costruzione di LFS per un ampio ventaglio di sistemi dare un'occhiata al ramo Cross-LFS di LFS.
Kelledin, inoltre, mantiene una lista di correzioni per la costruzione sulla piattaforma Alpha presso http://skarpsey.dyndns.org/alpha-lfs/alpha.html.
E' spesso utile compilare LFS per una macchina su un'altra macchina. Ovvero usare quel veloce Athlon da 1Ghz per costruire un'installazione per un vecchio 486. Sebbene questo tecnicamente non sia cross compiling, i binari compilati per Athlon non possono funzionare su 486, perché i binari compilati per il processore più nuovo usano caratteristiche che il vecchio processore non ha.
Il libro LFS specifico per il cross compiling è il libro Cross-LFS. Un'altra sorgente di informazioni è l'hint sul cross-compiling
Ha a che fare con i caratteri usati a fine linea.
Ce ne sono due che possono essere usati:
Unix, DOS, e MacOS usano ciascuno una diversa combinazione per terminare le linee nei file di testo:
come
gradini di
una scala.
Per cambiare da DOS a Unix, usare
cp <fileid> <fileid>.dos && cat <fileid>.dos | tr -d '\r' > <fileid>
Oppure in vim, si può convertire un file con: set ff={unix, dos, mac}. Altre conversioni probabilmente richiederanno sed o un diverso uso di tr e sono lasciate come esercizio per il lettore.
Sì. In generale non si può fare affidamento su make clean o make dist-clean per avere sorgenti puliti. Spacialmente quando avete modificato manualmente i sorgenti o aplicato patche ad essi dovreste prima provare di nuovo con un pacchetto nuovo non scompattato. La sola eccezione a questa regola è il linux kernel, che richiede che i suoi sorgenti siano presenti quando sono necessari moduli di terze parti, come i driver NVidia.
Normalmente le patch da GNU non funzionano. Si può o scaricare l'intero archivio e riprovare o provare la soluzione data da Gerard Beekmans:
Il problema è che vengono patchati anche gli script marcati come eseguibili, e così facendo perdono il bit di eseguibilità, così non è più possibile eseguire questi script fino a quando su di essi non si esegue un “chmod +x” (o qualcosa di simile, come chmod 755) prima di installare Glibc. Provate chmod +x glibc-2.2.5/scripts/* (non sicuro al 100% sul percorso della directory, ma dovrebbe essere ovvio dove farlo eseguendo un 'ls' sulla directory glibc-2.2.5).
Si è sovraottimizzato gcc.
Se si ottengono errori e si setta CFLAGS, o si passano comunque flag di ottimizzazione al compilatore, il problema può essere questo.
Se si chiede alla lista e nessuno capisce immediatamente è facile che suggeriscano di provare senza le ottimizzazioni. Così, se semplpicemente si provasse senza i flag prima di chiedere, si sarebbe un passo avanti rispetto alla lista :)
Da notare in particolare che l'ottimizzazione di binutils, gcc, o glibc può causare il fallimento della compilazione di qualunque altro pacchetto o causare errati comportamenti in modi strani e misteriosi. Inoltre, ottimizzazioni che funzionano per qualcun altro potrebbero non funzionare per voi. Flag che hanno sempre funzionato potrebbero misteriosamente smettere di funzionare. Anche alcuni innocenti cambiamenti dell'hardware possono fare la differenza.
(Se non si sa cosa sono i flag di ottimizzazione non è il caso di preoccuparsi, non ce n'è veramente bisogno.)
Verificate che /dev/null appaia così:
$ ls -l /dev/null crw-rw-rw- 1 root root 1, 3 Aug 3 2000 /dev/null
Se non lo è, dovrebbe. Vedere le pagine man di chmod(1), chown(1), e mknod(1) e /usr/src/linux/Documentation/devices.txt se si ha bisogno di un aiuto per sistemarlo.
Se è corretto, il problema risiede probabilmente nelle opzioni di mount. Vedere la risposta a ”./configure: bad interpreter: Permission denied“.
La risposta lunga è su http://www.bitwizard.nl/sig11/.
La risposta corta è che se riavviando make si va ogni volta un po' più avanti, si ha un problema hardware. (Se make, o qualunque cosa si esegue, fallisce ogni volta nello stesso punto, allora non è dovuto all'hardware.)
Supponendo che non si stia overclockando, il problema hardware più probabile è la memoria difettosa, che è possibile verificare con Memtest86 da http://www.memtest86.com/. Se non è questo, vedere la risposta lunga.
Esempi di questo errore sono:
/usr/bin/env: /static/bin/bash: No such file or directory gcc: No such file or directory
Con la nuova procedura di costruzione del Capitolo 5 la causa più comune di questo problema è dimenticare di applicare la patch specs.
Ciò che succede è che il percorso al linker dinamico incorporato nell'eseguibile punta ancora a /lib/ld-linux.so.2 e quando uno va ad eseguire il binario all'interno di chroot dove /lib/ld-linux.so.2 non esiste ancora, viene mostrato l'oscuro messaggio No such file or directory.
Si può testare questo con readelf -l {binary} | grep interpreter. Il suo output deve essere: Requesting program interpreter: /tools/lib/ld-linux.so.2.
Si è dimenticato di entrare nella directory estratta del pacchetto con il comando cd dopo averlo estratto.
E' più facile che questo accada quando si costruisce la bash nel Capitolo 5 del libro LFS. Il problema risiede probabilmente nelle opzioni di mount. Probabilmente in /etc/fstab c'è una linea come:
/dev/hda10 /mnt/lfs ext2 user 1 2
'user' è il flag di mount, ed è il problema. Citando la pagina man di mount:
user: Permette a un utente ordinario di montare il file system. Questa opzione implica le opzioni noexec, nosuid, e nodev (tranne se sovrascritto da opzioni successive, come nella linea di opzione user,exec,dev,suid).
Quindi cambiare la linea in /etc/fstab in questo modo:
/dev/hda10 /mnt/lfs ext2 defaults 1 2
Tipici sintomi appaiono in questo modo:
sk ~/tmp-0.0 $ ./configure creating cache ./config.cache checking host system type... configure: error: can not guess host type; you must specify one sk ~/tmp-0.0 $
Il problema di solito è che lo script non può eseguire il compilatore. Normalmente manca solo un link simbolico a /usr/bin/cc. Si può correggerlo così:
cd /usr/bin && ln -s gcc cc
Se non lo fa verificare il file config.log creato da configure. Gli errori sono lì, e possono indicare il problema.
Se configure dà un errore come:
checking whether we are using GNU C... no configure: error: GNU libc must be compiled using GNU CC
La causa può essere che egrep non funziona. Poiché egrep è uno shell-script che chiama grep, questo significa che c'è un problema con grep.
Per testare se grep funziona prima di reinstallare il pacchetto grep nel Capitolo 6 lanciare il seguente comando fuori da chroot:
file $LFS/bin/grep
Se non dice statically linked c'è un problema e bisogna reinstallare il pacchetto grep seguendo le istruzioni del Capitolo 5.
Per testare se grep funziona dopo aver reinstallato il pacchetto grep nel Capitolo 6, lanciare il seguente comando dentro chroot:
egrep root /etc/passwd
Se non stampa la linea di root da /etc/passwd, di nuovo, si ha un problema. (Questo test funziona anche se si incontrasse il problema dopo il riavvio nel nuovo sistema LFS.)
Si riceve un messaggio all'inizio del Capitolo 5 (LFS-4.1) o al primo passo di gcc (LFS CVS) che termina così:
-static -o gengenrtl \ gengenrtl.o ../libiberty/libiberty.a ld: cannot find -lc collect2: ld returned 1 exit status
Il proprio sistema host probabilmente è Mandrake 9 o successivo. Per default, il suo sistema base non ha una libreria statica C (/usr/lib/libc.a), che è necessaria per la compilazione statica dei pacchetti.
Bisogna installare l'RPM glibc-static-devel, che è nel terzo CD. Si può verificare il successo dell'installazione verificando che esista /usr/lib/libc.a. Se si sta utilizzando LFS 4.1, verificare che ogni cosa in $LFS/static/bin sia costruita staticamente usando file $LFS/static/bin/*. Se un pacchetto non è linkato staticamente reinstallarlo con le istruzioni del Capitolo 5.
In Mandrake/RPMS2/libncurses5-devel-5.2-16mdk.1586.rpm sul disco 2. I propri numeri di versione potrebbero essere leggermente diversi. (Se non si ha libcurses.a (no “n”), rileggere le istruzioni del libro per bash con più attenzione.)
Se si esegue
expect -c "spawn ls"
e si ottiene il seguente errore
The system has no more ptys. Ask your system administrator to create more.
allora la propria distribuzione linux non è impostata per usare i PTY di Unix98 o per usare il file system /dev/pts.
La soluzione potrebbe richiedere la ricompilazione del kernel. Prima andare nella directory sorgente del proprio kernel e guardare il file .config. Se non si ha un file .config, o se si sta eseguendo il kernel precompilato che è stato installato con rpm, aptget, o quello che la vostra distribuzione usa, allora è necessario cercare supporto dalla FAQ di supporto della propria distribuzione, le mailing list o i canali IRC.
Se si ha un file .config cercare al suo interno le due seguenti opzioni:
CONFIG_UNIX98_PTYS=y CONFIG_DEVPTS_FS=y
Se una delle due dovesse avere 'n' invece di 'y' cambiarla e ricompilare il kernel.
Se entrambe hanno 'y' allora probabilmente non bisognerà ricompilare il kernel.
Successivamente bisogna assicurarsi che il sistema usi sia le PTY di Unix98 che il file system /dev/pts.
Cercare dapprima un dispositivo chiamato /dev/ptmx. Se non esiste crearlo con:
mknod /dev/ptmx c 5 2
Quindi, sia che esista o sia appena stato creato, eseguire:
chmod 666 /dev/ptmx
Successivamente assicurarsi che ci sia una directory chiamata /dev/pts. I permessi dovrebbero essere 755. Crearla e/o eseguire chmod, se necessario.
L'ultimo setup è aggiungere la seguente linea a /etc/fstab:
devpts /dev/pts devpts gid=5,mode=620 0 0
NOTA: cercare il gruppo tty in /etc/group e prendere nota del numero id del gruppo. Cambiare l'opzione gid=5 per farla coincidere con il numero di id del gruppo tty. Il numero id 5 del gruppo è solo un esempio e può essere differente sul proprio sistema.
Ora che tutto è impostato ci sono due possibilità:
Se si riceve un errore sul conflitto di tipi per 'gethostname' quando si compila bash nel Capitolo 5, bisogna installare l'RPM glibc-static-devel. (E' sul terzo CD.)
Se, quando si compila modutils, si ottiene:
/usr/bin/gcc -O2 -Wall -Wno-uninitialized -I. -I. -I./../include -D_GNU_SOURCE -DCONFIG_ROOT_CHECK_OFF=0 -c -o lex.o lex.c lex.l: In function `yylex': lex.l:429: `yytext_ptr' undeclared (first use in this function) lex.l:429: (Each undeclared identifier is reported only once lex.l:429: for each function it appears in.) make[1]: *** [lex.o] Error 1
Allora FBBG (Hint: flex).
Manca un file di dispositivo (probabilmente /dev/null, ma forse /dev/zero). Ad ogni modo, o si è dimenticato di eseguire MAKEDEV, o MAKEDEV ha fallito, o si sta usando devfs e si è dimenticato di montarlo con –bind sotto $LFS.
Se ha fallito MAKEDEV, spesso tutti gli id dei dispositivi termineranno con un ”-“. Probabilmente succede quando MAKEDEV è eseguito senza aver montato $LFS/proc.
I dispositivi devono apparire esattamente così:
sk@bubook:~ $ ls -l /dev/{null,zero}
crw-rw-rw- 1 root root 1, 3 Dec 31 1969 /dev/null
crw-rw-rw- 1 root root 1, 5 Dec 31 1969 /dev/zero
sk@bubook:~ $
Se, compilando GCC nel Capitolo 5, avvengono errori con
Error: Unknown pseudo-op: `.hidden'
Provare la soluzione data negli archivi di lfs-support e nelle repliche.
Questo è causato dall'utilizzo di un host incompatibile per costruire LFS (es. Fedora Core 2). Il problema è causato dal fatto che le binutils dell'host supportano l'opzione ”–as-needed“, ma la versione di GCC che si compila in LFS-5.1.1 non supporta questa opzione. Per risolverlo usare un host più vecchio, o costruire LFS-6.0.
L'errore esatto appare così:
*** On GNU/Linux systems it is normal to compile GNU libc with the *** `linuxthreads' add-on. Without that, the library will be *** incompatible with normal GNU/Linux systems. *** If you really mean to not use this add-on, run configure again *** using the extra parameter `--disable-sanity-checks'.
Non si è scompattato glibc-linuxthreads-X.X.X.tar.bz2 nella directory glibc-X.X.X. Scompattarlo e tutto funzionerà.
L'errore configure: error: cannot determine asm global directive durante la configurazione di glibc indica un problema con l'installazione delle binutils. E' probabile che non siano linkate staticamente. (Si può verificare con file $LFS/static/bin/as.) In ogni caso, provare a reinstallare le binutils.
Manca /dev/null. O si è dimenticato di crearlo quando le istruzioni di costruzione di glibc dicevano di farlo, o si sta utilizzando devfs e si è dimenticato di eseguire “mount –bind /dev $LFS/dev” prima di entrare in chroot. Bisognerebbe cancellare e ricreare le directory glibc-N.N.N e glibc-build dopo aver corretto il problema.
Se glibc fallisce la compilazione con un errore come questo:
'BEGIN { subdirs = ""; inhibit = "" }; \
^# { next }; \
^[^-] { subdirs = subdirs " " $0 }; \
^- { inhibit = inhibit " " substr($0, 2) }; \
END { printf "sysdep-subdirs =%s\n", subdirs; \
printf "sysdep-inhibit-subdirs =%s\n", inhibit; \
print "sysd-dirs-done = t" }' \
/dev/null linuxthreads/sysdeps/pthread/Subdirs
sysdeps/unix/inet/Subdirs sysdeps/unix/Subdirs >
/usr/src/glibc-build/sysd-dirs-tmp
/bin/sh: line 1: BEGIN { subdirs = ""; inhibit = "" };
^# { next };
^[^-] { subdirs = subdirs " " $0 }; ^- { inhibit =
inhibit " " substr($0, 2) }; END
allora fallisce gawk. La chiave è il BEGIN e END nell'output. La ragione probabile è che non è linkata staticamente, cosa che può essere corretta tornando al Capitolo 5 e ricompilandola.
Questo di solito indica che si sta compilando LFS su una partizione Reiser4. Sfortunatamente attualmente non c'è una soluzione nota, tranne usare un tipo diverso di filesystem.
Ncurses nel capitolo 6 finisce con:
checking how to run the C++ preprocessor... /lib/cpp configure: error: C++ preprocessor "/lib/cpp" fails sanity check
Il problema è che non si ha il compilatore C++. Nel Capitolo 5 gcc è costruito senza il compilatore C++. Prima di costruire ncurses gcc è costruito con il compilatore C++. Probabilmente si è dimenticato di estrarre il tarball g++. Maggiori dettagli si trovano nell'archivio mail.
Ci sono diverse ragioni perché il kernel possa non essere in grado di montare il filesystem root:
Quando si vede nei propri log di sistema, una linea come questa:
init: Id “1” respawning too fast: disabled for 5 minutes
Significa che c'è un errore nella linea di /etc/inittab che inizia con il dato id (“1” in questo esempio).
Quando si è compilato net-tools si è abilitato il supporto per una famiglia di protocolli (che è da dove viene “pf”) di cui non si è abilitato il supporto nel kernel. (Probabilmente sono state semplicemente accettate le risposte di default.)
Una lista di protocolli completa è in /usr/include/linux/socket.h, ma qui c'è una lista dei probabili colpevoli:
net-pf-3: Amateur Radio AX.25 (AF_AX25) net-pf-4: Novell IPX (AF_IPX) net-pf-5: AppleTalk DDP (AF_APPLETALK) net-pf-6: Amateur Radio NET/ROM (AF_NETROM) net-pf-9: Reserved for X.25 project (AF_X25)
Naturalmente la soluzione consiste nel ricompilare net-tools senza il supporto per ciò che non serve. (O ricompilare il proprio kernel con il supporto se invece li si voleva.) Aggirare il problema inserendo una linea come la seguente in /etc/modules.conf:
alias net-pf-? off
Sostituire il punto interrogativo con il numero corretto, ovviamente. E rieseguite depmod:
Se si riceve un errore a proposito di net-pf-7, probabilmente bisogna abilitare il supporto per il dispositivo di loopback di rete (non block device) nel proprio kernel. Bisogna aggiungere la linea seguente in /etc/modules.conf e riavviare depmod.
alias net-pf-7 loop
char-major-10-135 si riferisce al dispositivo a caratteri, major 10, minor 135, che è /dev/rtc. Fornisce accesso al clock BIOS, o RTC, il Real Time Clock. Vedere /usr/src/linux/Documentation/rtc.txt per maggiori informazioni.
L'errore è perché qualcosa, probabilmente hwclock, tenta di usare /dev/rtc ma non ne è stato configurato il supporto nel proprio kernel. Cancellare /dev/rtc così che hwclock non tenti di usarlo o abilitare il supporto RTC nel proprio kernel. Si trova in make menuconfig sotto “Character devices” → “Enhanced Real Time Clock Support”.
Vedere il problema modprobe- Can't locate module char-major-10-135.
L'errore completo appare così:
eth0:unknown interface:No such device [failed] Setting up default gateway... SIOCADDRT:No such device [failed]
eth0 è una periferica virtuale non registrata in /dev. Fa riferimento alla prima scheda di rete rilevata nel proprio sistema. La ragione per cui il kernel non può trovare questa periferica è che si è dimenticato di aggiungere il supporto per la propria scheda di rete nel kernel. Il kernel ha rilevato la scheda, ma non ha il driver per essa. Lo script di avvio di LFS tenta di attivare la rete ma non ci riesce a causa di questo.
Ricompilare il proprio kernel con il driver giusto, incorporato o come modulo. Se si è compilato il driver di rete come modulo, allora sistemare anche /etc/modules.conf per dare un alias al modulo della scheda di rete come eth0; per esempio: alias eth0 8139too. Se non si sa quale scheda di rete si ha, si può usare dmesg, /proc/pci o lspci per scoprirlo.
Breve sommario: E' un problema hardware (di solito). Il rumore/interferenza di linea convince il PIC che è successo qualcosa; il risultato può essere che viene lanciato un 'falso' interrupt, che è IRQ7 con il design intel 8259. Il problema può anche essere causato da (o invece essere causato da) un driver di periferica che non maschera correttamente i suoi interrupt prima di servire, questo sarebbe il sospetto se l'IRQ7 avvenisse a raffiche, o più spesso che 'qualche volta' al giorno. (Sorgente e informazioni aggiuntive)
Poiché il messaggio stesso non è pericoloso, è sufficiente sistemare il loglevel output di default di klogd (l'opzione -c) nel bootscript syslogd. Vedere man klogd per i dettagli. Si può anche provare a ricompilare il kernel e disabilitare CONFIG_LOCAL_APIC.
Perché le variabili di ambiente LANG e LC_ALL non sono impostate. Per correggere questo, settarle entrambe nei file ~/.bash_profile e ~/.bashrc per ciascun utente o in /etc/profile, che riguarderà tutti gli utenti, aggiungendo linee come questa:
export LANG=en_US export LC_ALL=POSIX
Queste linee possono essere aggiunte a /etc/profile con il seguente comando:
echo -e 'export LANG=en_US\nexport LC_ALL=POSIX' > /etc/profile
Se non si usa US English bisognerà cambiare la parte “en_US” e possibilmente anche i valori di diverse variabili LC_*. Eseguendo il comando “locale” vengono elencate molte (tutte?) delle variabili LC_*.