Domande relative a LFS

Ampliamenti richiesti frequentemente

Durante la lettura e costruzione di LFS

Errori generali di compilazione

Errori specifici di pacchetto

Problemi di configurazione e avviamento


Ampliamenti richiesti frequentemente

Perché usare GRUB invece di LILO?

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.

Perchè non includere le FAQ nel libro?

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.

Perché nel libro si usa vim?

L'argomento è abbastanza ben discusso qui: http://linuxfromscratch.org/pipermail/lfs-dev/2002-February/023030.html

Perchè nel libro si usa "ed"?

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:

Perchè la binutils HJL non è nel libro?

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.

Perchè non c'è nessun gestore di pacchetti nel libro?

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.

Come faccio a far spegnere la macchina quando termino la sessione?

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.

Durante la lettura e costruzione di LFS

Quale distribuzione si deve utilizzare come punto di partenza?

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.

Come si compila un kernel o si settano i moduli?

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/.

Sono un brutto segno gli avvisi di GCC?

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 $

Come faccio a fare quella piccolissima installazione citata dal libro?

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.

Ci sono informazioni sulla costruzione di LFS su altri processori?

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.

Come posso fare il cross compile su LFS?

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

Cosa è un file di testo in formato DOS?

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.

Errori generali di compilazione

Non ho cancellato l'albero sorgente dopo l'ultimo tentativo. Devo?

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.

Per aggiornare, ho usato una patch da GNU. Ho fatto bene?

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).

Perchè configure si blocca su "checking for signed size_t type..."?

Si è sovraottimizzato gcc.

Quando si usano i flag di ottimizzazione (settaggio di CFLAGS)

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.)

Ottengo '/dev/null permission denied'

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“.

Segnale 11 (internal error Segmentation fault)

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.

No such file or directory

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.

bash- ./configure No such file or directory

Si è dimenticato di entrare nella directory estratta del pacchetto con il comando cd dopo averlo estratto.

./configure- bad interpreter Permission denied

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

configure non riesce a capire il mio host type

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.

checking whether we are using GNU C... no

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.)

ld- cannot find -lc

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.

Dove è libncurses.a in Mandrake?

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.)

The system has no more ptys. Ask your system administrator to create more.

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à:

  1. Montare /dev/pts e testarlo eseguendo di nuovo il precedente comando expect.
  2. Riavviare il computer e testarlo eseguendo di nuovo il precedente comando expect.

Errori specifici di pacchetto

Bash- conflitto di tipi per 'gethostname'

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.)

Modutils- "lex.l 429 'yytext_ptr' undeclared" durante la costruzione di modutils

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).

Perl fallisce con ''*** missing separator. Stop''.

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:~ $

GCC- Error Unknown pseudo-op '.hidden'

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.

GCC- Error unrecognized option '--as-needed'

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.

Glibc- "... On GNU/Linux systems it is normal to compile GNU libc with the 'linuxthreads' add-on..."

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à.

Glibc- "cannot determine asm global directive"

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.

Glibc- "ld.map No such file or directory"

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.

Glibc fallisce e cita BEGIN e END

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.

La compilazione di Glibc dà un errore dovuto a un file header nss.h mancante

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- C++ preprocessor "/lib/cpp" fails sanity check

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.

Problemi di configurazione e avviamento

Kernel panic- VFS unable to mount root fs

Ci sono diverse ragioni perché il kernel possa non essere in grado di montare il filesystem root:

init- Id "1" respawning too fast disabled for 5 minutes

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).

Ho errori su net-pf-?

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

modprobe- Can't locate module char-major-10-135

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”.

modprobe- Can't locate module /dev/rtc

Vedere il problema modprobe- Can't locate module char-major-10-135.

eth0-unknown interface No such device (failed)

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.

spurious 8259A interrupt IRQ14

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é less (e talvolta man) stampa <AD> invece dei trattini?

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_*.