• Perché usare GRUB invece di LILO
• Perchè non includere le FAQ nel libro
• Perché nel libro si usa vim
• Perchè nel libro si usa "ed"
• Perchè la binutils HJL non è nel libro
• Perchè non c'è nessun gestore di pacchetti nel libro
• Come faccio a far spegnere la macchina quando termino la sessione

• Quale distribuzione si deve utilizzare come punto di partenza
• Come si compila un kernel o si settano i moduli
• Sono un brutto segno gli avvisi di GCC
• Devo tenere i sorgenti dopo l'installazione?
• Come faccio a fare quella piccolissima installazione citata dal libro
• Ci sono informazioni sulla costruzione di LFS su altri processori
• Come posso fare il cross compile su LFS
• Cosa è un file di testo in formato DOS

• Non ho cancellato l'albero sorgente dopo l'ultimo tentativo. Devo
• Per aggiornare, ho usato una patch da GNU. Ho fatto bene
• Perchè configure si blocca su "checking for signed size_t type..."
• Quando si usano i flag di ottimizzazione (settaggio di CFLAGS)
• Ottengo '/dev/null permission denied'
• Segnale 11 (internal error Segmentation fault)
• No such file or directory
• bash- ./configure No such file or directory
• ./configure- bad interpreter Permission denied
• configure non riesce a capire il mio host type
• checking whether we are using GNU C... no
• ld- cannot find -lc
• Dove è libncurses.a in Mandrake
• The system has no more ptys. Ask your system administrator to create more.

• Bash- conflitto di tipi per 'gethostname'
• Modutils- "lex.l 429 'yytext_ptr' undeclared" durante la costruzione di modutils
• Perl fallisce con ''*** missing separator. Stop''.
• GCC- Error Unknown pseudo-op '.hidden'
• GCC- Error unrecognized option '--as-needed'
• Glibc- "... On GNU/Linux systems it is normal to compile GNU libc with the 'linuxthreads' add-on..."
• Glibc- "cannot determine asm global directive"
• Glibc- "ld.map No such file or directory"
• Glibc fallisce e cita BEGIN e END
• La compilazione di Glibc dà un errore dovuto a un file header nss.h mancante
• NCurses- C++ preprocessor "/lib/cpp" fails sanity check

• Kernel panic- VFS unable to mount root fs
• init- Id "1" respawning too fast disabled for 5 minutes
• Ho errori su net-pf-
• modprobe- Can't locate module char-major-10-135
• modprobe- Can't locate module /dev/rtc
• eth0-unknown interface No such device (failed)
• spurious 8259A interrupt IRQ14
• Perché less (e talvolta man) stampa <AD> invece dei trattini

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:

• Per quelli che lo sanno usare, e' un editor di emergenza molto utile. Il client telnet standard usato da MS Windows riesce a dialogare con ed, mentre ha problemi con editor a tutto schermo (come vim); inoltre un vim totalmente equipaggiato richiede non solo ncurses, ma anche X11! Qualsiasi problema con queste ultime librerie lascerebbe il sistema sprovvisto di un editor, se ed non fosse presente.
• Sebbene questo non sia un buon motivo per averlo nel libro… ad alcuni ed piace veramente.
• Capire ed aiuta a capire vi(m) e la storia di UNIX in generale.

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:

• HJL
  • esclusiva per Linux
  • segnalata come “beta”
  • segue strettamente l'aggiornamento del CVS
  • solitamente contiene correzioni sottili agli ultimi bug
  • solitamente contiene correzioni agli ultimi bug sulle versioni per architetture differenti dalla x86
  • solitamente viene rilasciata una nuova versione non appena un bug su Linux viene sistemato
  • teoricamente sono meno stabile, a causa del codice più recente
• FSF
  • supporta più sistemi operativi (non solo Linux)
  • il codice più nuovo è sempre dal ramo “stabile” del CVS
  • a volte non è in linea con le ultimissime sottigliezze del kernel, di gcc e di glibc
  • spesso include caratteristiche “portate” indietro dalle versioni avanzate, dopo un periodo di prova
  • teoricamente più stabile

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:

• tenersi aggiornati, nelle mailing list, sulle novità che riguardano i pacchetti chiave della toolchain
• avere una ampia dose di capacità tecnica e di talento informatico per comprendere tutti gli aspetti
• provare come un matto eseguendo le suite di test
• provare come un matto costruendo sistemi completi

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:

• Nessun gestore di pacchetti è relamente necessario. A meno che non si desideri seguire al minuto l'allocazione dei singoli pacchetti, ogni pacchetto abbastanza grande da poter essere rimosso per necessità di spazio su disco può essere posto in /opt, come indicato dalla FHS (o, magari, in /opt/foo-x.x, con un link da /opt/foo) e nuove versioni possono essere solitamente installate “sopra” le vecchie, sebbene grossi cambiamenti ed aggiornamenti è meglio farli ricostruendo il sistema dalle fondamenta.
• RPM, il Redhat Package Manager, è usato da numerose distribuzioni. E' disponibile su http://www.rpm.org/, e c'è un Hint per RPM per aiutare nell'installazione
• Esiste una versione di LFS basata su RPM, disponibile presso: http://www.puxedo.org/lvr/
• Esistono diverse implementazioni della gestione dei pacchetti su modello dei symlink:
  1. Epkg, da: http://encap.cso.uiuc.edu/epkg/.
  2. Graft, da: http://www.gormand.com.au/peters/tools/.
  3. GNU Stow, da: http://www.gnu.org/software/stow/.
  4. Depot, da: http://asg.web.cmu.edu/depot/.
  5. E molte altre elencate nella documentazione di Graft, che è disponibile presso: http://www.gormand.com.au/peters/tools/graft/graft.html#research.
• Il gestore di pachetti di NetBSD, pkgsrc, è disponibile per altri sistemi, incluso Linux. Si trova presso: ftp://ftp.netbsd.org/pub/NetBSD/packages/bootstrap-pkgsrc/.
• Basato originariamente su uno script creato dallo stesso Gerard Beekmans di LFS, install-log registra un elenco dei file installati da un pacchetto mentre quest'ultimo si installa. E' disponibile presso: http://install-log.sourceforge.net/.
• In seguito, Gerard ha operato delle aggiunte al suo script. E' tutto disponibile presso: http://linuxfromscratch.org/~gerard/log-install e presso: http://linuxfromscratch.org/~gerard/pkgdel.
• CheckInstall prova a registrare chiamate di sistema eseguite da “make install”. E' disponibile presso: http://asic-linux.com.mx/~izto/checkinstall/.
• pkgutils, usato dalla distribuzione CRUX, è disponibile presso: http://www.fukt.bth.se/~per/pkgutils/.
• Ci sono alcuni hint disponibili per i gestori di pacchetti.

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:

• Line Feed: (LF) Ottale:012 Decimale:10 Hex:0A C Style Escape:'\n' Si sposta nella linea sottostante.
• Carriage Return: (CR) Ottale:015 Decimale:13 Hex:0D C Style Excape:'\r' Si sposta sul margine sinistro.

Unix, DOS, e MacOS usano ciascuno una diversa combinazione per terminare le linee nei file di testo:

• Unix: solo LF. Questa è la ragione per cui quando un file testo in formato Unix è inviato grezzo a una stampante, esso stampa

come

gradini di

una scala.

• DOS: entrambi CRLF. Questa è la ragione per cui se si fa “cat -v” su un file DOS si vedrà un “^M” (control m è carriage return) al termine di ciascuna linea. Ed è per questo che gli script non funzionano quando vengono scritti con Microsoft Notepad. Il kernel cerca ”/bin/sh^M“, che non esiste. C'è un ”/bin/sh“, ma nulla con un “^M” appeso.
• MacOs: solo CR. Le stampanti probabilmente stampano le linee una dietro l'altra, e i tool Unix pensano che l'intero file sia una linea con in mezzo dei “^M”.

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

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.

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:

• E' stata specificata la partizione corretta in /etc/lilo.conf?
• Ci si è ricordati di eseguire di nuovo LILO dopo aver modificato /etc/lilo.conf?
• Il supporto per il disco rigido deve essere abilitato nel kernel. Per SCSI questo significa supporto per lo specifico adattatore SCSI.
• Il supporto per il disco rigido deve essere compilato nel kernel, non come modulo. (I moduli sono archiviati nel filesystem. Se un driver necessario per accedere a un filesystem è archiviato come modulo sullo stesso filesystem, bene … si è capito … ;)
• Il supporto per il filesystem deve essere compilato nel kernel. Nuovamente, non come modulo. Il supporto per ext2 è abilitato per default, ma altri come ext3, reiser, jfs, e xfs non lo sono.

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