I N S T A L L A Z I O N E
Panoramica del processo di installazione
========================================
Per sua natura, questo pacchetto necessita di almeno due computer.
Uno funge da server e (almeno) un altro sarà configurato come client
diskless. Di conseguenza questa guida all'installazione è divisa in
quattro sezioni:
1.) Compilazione e installazione di programmi di utilità
sul server
2.) Creazione di una immagine avviabile del sistema
operativo scelto
3.) Preparazione del server
4.) Preparazione del client, compresa la bootrom
Il server deve supportare il TCP/IP e alcuni protocolli basati su
questo standard di rete. Molto probabilmente questo sarà un server
di tipo Unix. Sebbene probabilmente sia possibile usare anche, ad
esempio, dei server su cui gira OS/2 o Windows-NT, tutti i programmi
relativi ai server di questo pacchetto, al momento, possono essere
compilati soltanto su sistemi di tipo Unix. Tale requisito è indipendente
dal sistema operativo che verrà avviato più tardi sul client diskless.
Quindi, anche se si desidera avviare MS-DOS sul (sui) client, è
necessario almeno un computer Unix per la compilazione del programma
e per la generazione di tutti i file di boot. In seguito, quando tutti
i file necessari saranno stati compilati, è possibile usare qualsiasi
server si desideri.
Questo pacchetto contiene due parti principali:
1.) I sorgenti ed i binari della bootrom. Questa parte viene
installata sul client diskless. Tutti i programmi, ad
eccezione dei programmi di utilità, sono già precompilati.
Nei sorgenti non ci sono ulteriori opzioni modificabili o
aggiustabili da parte dell'utente; quindi non è necessario
avere accesso agli strumenti di sviluppo a 16 bit per usare
la bootrom, è sufficiente usare i binari forniti.
Per permettere alla bootrom di accedere alla scheda di rete
nel client diskless è necessario un driver. Al momento la
bootrom supporta solo i così detti packet driver, come
quelli che si usano di solito nei sistemi MS-DOS per
interfacciare uno stack di rete con l'hardware. Con questo
pacchetto sono necessari solo i binari del packet driver,
quindi qui non è necessario ricompilare nulla. È possibile
trovare packet driver precompilati per la maggior parte
delle più diffuse schede di rete su qualsiasi mirror FTP SimTel
(si chiama Crynwr packet driver collection) e, per quelli che
non hanno accesso ad Internet, alcuni di tali binari
sono inclusi in questo pacchetto. Un'altra buona fonte per
il packet driver della propria scheda di rete potrebbe
essere il produttore della stessa. Come minimo, i più noti
produttori (per esempio 3Com e SMC) forniscono i packet
driver di tutta la loro linea di prodotti. I packet driver
forniti dai produttori sono di solito più veloci e più facili
da installare di quelli della raccolta Crynwr e, a volte, sono
in grado di determinare la configurazione dell'hardware durante
l'esecuzione, cosa che i driver di Crynwr non riescono a
fare. Tuttavia esiste la limitazione che è possibile usare solo
packet driver eseguibili di tipo COM. Gli eseguibili di
tipo EXE non sono ancora supportati.
2.) Un insieme di programmi per generare sul server delle immagini
avviabili via rete. Tali programmi sono chiamati mknbi-<os>,
ove <os> identifica il sistema operativo che poi girerà sul
client diskless. Al momento sono supportati solo Linux
ed MS-DOS.
C'è un altra esigenza che non può passare inosservata. Sebbene sia
possibile preparare una ROM di boot, dalle funzionalità leggermente
limitate, che occupi meno di 16Kb, la dimensione solita per una scheda
di rete è tra 16Kb e 32Kb. Quindi nel comprare una scheda di rete
bisognerebbe prenderne una che accetti EPROM da 32Kb. Questo è lo
standard per quasi tutte le schede dei principali produttori, ma è
noto che la maggior parte delle economiche NE2000 accettino solo 16Kb
al massimo. Va notato anche che alcune schede di rete di 3Com e SMC
permettono, tramite i loro programmi di configurazione, di selezionare
dimensioni di 32Kb o più per la ROM, ma poi sulla scheda accettano
solo ROM da 16Kb!
Compilazione e installazione dei programmi di utilità sul server
================================================================
Questo pacchetto usa l'autoconf GNU per configurare il processo di
compilazione dei programmi di utilità. Non si dovrebbe avere nessun
problema nel compilare tali programmi su un qualsiasi sistema Unix.
1.) Posizionarsi nella directory netboot e lanciare ./configure.
È uno script di configurazione generato da autoconf che
controlla i file header e altri dettagli specifici del
sistema. Il programma di utilità mknbi contiene dei moduli
assembler Intel che poi gireranno sul client diskless.
Se si vogliono assemblare tali moduli sono necessari as86
e ld86 (che possono essere recuperati gratuitamente sui
sistemi Unix). Comunque sono disponibili i file già
assemblati e quindi in effetti tali programmi non servono.
Configure ne verifica l'esistenza e crea i Makefiles di
conseguenza.
Per una spiegazione delle opzioni disponibili per configure
basta lanciarlo con l'opzione --help. Sono disponibili
delle opzioni aggiuntive:
--disable-mknbi-linux
--disable-mknbi-dos
Queste opzioni vanno scelte se non si vuole creare nessuna
delle corrispondenti utilità mknbi. C'è anche un'altra
opzione di configure:
--enable-bootrom
Va usata solo se si vuole ricompilare la bootrom stessa.
Se si vogliono usare i binari precompilati tale opzione non
è necessaria. Vedere il file INSTALL.bootrom riguardo il
modo in cui ricompilare la bootrom.
2.) Controllare che tutti i Makefile generati e i config.h siano
corretti per il proprio sistema.
3.) Compilare tutti i programmi con
make clean
make
Ciò compilerà tutti i programmi, tranne quelli disabilitati
durante la fase di configurazione.
NOTA IMPORTANTE: alcuni Makefile usano ifdef, che non è
comprensibile a tutti i make. Se si riceve un errore da
make (di solito del tipo: "missing delimiter", manca un
delimitatore) allora ci si procuri e si installi sul proprio
sistema il make GNU! I sistemi System V sono i più noti per
avere tale problema.
4.) Se si desidera installare i programmi di utilità in modo
permanente sul proprio sistema si esegua
make install
Ciò installerà anche le corripondenti pagine di manuale
per futuri riferimenti. Comunque è perfettamente lecito
saltare questo passo e lanciare i programmi mknbi dalle
loro directory sorgenti. Per favore si osservi che
all'interno delle loro directory sorgenti sono chiamati
semplicemente "mknbi". Quindi se in seguito si legge di
lanciare mknbi-dos, bisogna invece usare
"./mknbi-dos/mknbi", se i programmi sono stati installati
senza dare 'make install'.
Creazione di una immagine del sistema operativo avviabile via rete
==================================================================
Questo passo del processo di installazione dipende da quale sistema
operativo si vuole far avviare dai propri client diskless. Tutto
quello che viene descritto in questo capitolo non dipende dal fatto
che si stia lavorando su un sistema Linux. È possibile usare
qualsiasi sistema UNIX per creare le immagini avviabili via rete.
Linux: Con Linux ci sono così tante opzioni che non è possibile
elencarle tutte in questo testo. Per i dettagli si faccia
riferimento alla pagina di manuale di mknbi-linux. Qui
descriveremo solo i modi più comuni per preparare un client
diskless Linux.
Primo: bisogna decidere dove il client Linux monterà il suo
filesystem root. Può essere una directory su un server NFS o
un ramdisk. Configurare il proprio kernel Linux concordemente.
Per usare un filesystem root su un server NFS bisogna
includere nel kernel il supporto per reti TCP/IP ed anche
quello per i filesystem NFS. Non è possibile caricare il
supporto NFS usando un modulo poiché deve essere disponibile
già al momento dell'avvio.
In più, durante la configurazione del kernel, bisogna anche
selezionare il supporto NFSROOT. Tuttavia, non è necessario
il supporto per BOOTP o RARP. Di conseguenza, se si vuole
usare il supporto per i ramdisk, il tipo di filesystem che si
userà sul ramdisk deve essere compilato in modo permanente
nel kernel. In tal caso deve essere incluso anche initrd.
1.) Configurazione del filesystem principale su NFS
Poi si copi il proprio kernel Linux nella directory corrente
e si lanci mknbi-linux:
mknbi-linux -d rom -i rom -k zImage -o bootImage
Si è supposto che l'immagine del proprio kernel si chiami
zImage. Ne verrà fuori una immagine caricabile via rete di
nome bootImage.
2.) Configurazione del filesystem principale su ramdisk
Se si vuole usare un ramdisk come dispositivo principale
bisogna prima creare una immagine del ramdisk. Probabilmente
il modo più semplice per preparare una tale immagine è di usare
un floppy, sebbene sia possibile anche usare un loopback
device se si sta lavorando su un sistema Linux. Innanzitutto si
formatti il floppy e vi si prepari un filesystem. Poi vi si
copino tutti i file e i programmi che si vorranno (in seguito)
avere sul filesystem principale del client diskless.
Bisognerebbe poi provare il floppy di boot; per far ciò si
copi il proprio kernel su un altro floppy, con dd, e si
imposti il suo device principale su floppy usando rdev:
dd if=zImage of=/dev/fd0
rdev /dev/fd0 /dev/fd0
Ora si avvii il proprio client diskless usando tale floppy di
boot. Quando il kernel è partito chiederà di inserire il floppy
di boot e di premere invio. Il disco di boot verrà montato.
Se tutto funziona come previsto si può creare una immagine
avviabile da rete. Reinserire il floppy di boot nel proprio
server (o dovunque si trovi tale directory di boot da rete) e
digitare:
dd if=/dev/fd0 of=ramImage
gzip -9 ramImage
mknbi-linux -d ram -i rom -r ramImage.gz -k zImage -o bootImage
Come sopra, ciò darà un file bootImage contenente il kernel
Linux avviabile da rete.
MS-DOS: Per avviare il DOS sul proprio client diskless bisogna avere
MS-DOS versione 5.0 o successiva. Windows-95 possiede un DOS
interno chiamato versione 7.0, quindi non dovrebbero esserci
problemi. Versioni più vecchie di MS-DOS non funzioneranno
sicuramente. Non ho avuto la possibilità di provare nessun
altro DOS tipo il Novell-DOS o il DR-DOS. Chi li prova mi
racconti.
Primo: bisogna creare una directory contenente tutti i file che
il client vedrà sul suo drive di avvio (A: oppure C:). Questa
può essere la directory principale su un floppy DOS o una
qualsiasi directory sullo stesso sistema su cui si è installato
mknbi-dos. Nel primo caso deve essere un floppy contenente un
sistema DOS avviabile, cioè che è stato creato con
format a: /s
su un sistema DOS. Se la directory si trova in un sistema UNIX,
bisogna copiarsi da soli i due file di sistema msdos.sys e
io.sys, che fanno parte dell'MS-DOS, nella directory in
questione. Per far ciò, suggerisco di usare mread degli MTools,
che sono liberamente disponibili per praticamente tutti i
sistemi UNIX.
Dopo aver creato la directory, o il floppy, che diventerà il
drive di avvio dei client, bisogna copiarci dentro tutti gli
altri file necessari. Probabilmente ci andranno messi programmi
utili a configurare l'ambiente di rete sul client. Quando si
editano i file di testo per il client si tenga conto che, di
solito, devono essere in formato MS-DOS, con le righe che
terminano con la coppia Carriage-Return/Linefeed invece che
solo con Linefeed come si usa sui sistemi UNIX. Quando si è
terminata la preparazione della directory di boot del client,
come prima cosa si faccia una copia dell'immagine del floppy
disk e poi si lanci mknbi-dos per creare l'immagine avviabile
da rete:
dd if=/dev/fd0 of=fdImage
mknbi-dos -r fdImage -o bootImage
Assunto che il floppy sia stato inserito nel drive fd0 del
sistema UNIX, verrà creato un file chiamato bootImage. Se si è
usata una directory UNIX si sostituisca fdimage col suo nome.
mknbi-dos si accorgerà automaticamente se è una directory, un
file normale, o un device a blocchi.
Di default, mknbi-dos crea un'immagine avviabile da rete che
in seguito monterà sul client il ram disk come drive A:. Se
invece si vuole che il ram disk sia montato come C:, bisogna
aggiungere l'opzione '-c' nella chiamata di mknbi-dos.
La differenza fra il montare il ram disk come floppy (A:) o
come disco rigido (C:), è che montato come floppy il ram disk
può essere rimosso successivamente, magari dopo che è stato
caricato un redirezionatore di rete che rende il ram disk
obsoleto; ciò non è invece possibile con un disco rigido virtuale.
D'altra parte, usando il disco rigido come C: è possibile
specificare una diversa dimensione del ramdisk tramite
l'opzione '-s'. Per maggiori informazioni si faccia riferimento
alla pagina di manuale di mknbi-dos.
Preparazione del server
=======================
La preparazione del server dipende dal tipo di server che si sta
usando, quindi tutte le spiegazioni che seguono in questo capitolo
possono servire solo come guida generica. Bisogna riferirsi alla
documentazione del proprio server come fonte decisiva.
Quando viene avviata la bootrom sul client essa prova innanzi tutto a
chiedere ad un server bootp informazioni come i numeri IP e il nome
del file con l'immagine di avvio. Un tale programma di server bootp
viene in genere chiamato bootpd. La maggior parte dei server Sun usano
invece un programma server bootp chiamato bootparamd. C'è da osservare
che _non_ è possibile usare bootparamd come sostituto di bootpd poiché
i due programmi usano protocolli diversi; piuttosto si installi sulla
propria Sun uno dei bootpd pubblicamente disponibili. Poi bisogna
copiare il file bootImage, che è stato creato nel passo precedente, in
una directory accessibile pubblicamente (ad esempio chiamata /boot).
Se si vogliono avviare più client diskless è possibile usare lo stesso
file bootImage per tutti. Tuttavia, se la configurazione è fatta per
un ramdisk (con Linux o DOS) e l'immagine del ramdisk contiene diversi
file di informazione per ogni client, bisognerà ovviamente avere un
diverso file bootImage per ciascun client.
Poi bisogna preparare un file di descrizione del boot per bootpd, che
di solito si chiama /etc/bootptab. Per maggiori informazioni si
consulti la documentazione del proprio server. Comunque, le voci in
tale file di solito saranno qualcosa di questo tipo (per ogni client
diskless):
client1:hd=/boot:vm=auto:ip=192.109.225.66:\
:ht=ethernet:ha=004001417173:\
:bf=bootImage-client1:rp=/boot/client1/root
il marcatore 'hd' indica la home directory e 'bf' è il nome del file
bootImage che si è creato al passo precedente. Quindi il path completo
del file bootImage per il client diskless chiamato "client1", con
questa voce d'esempio, sarà
/boot/bootImage-client1
Il marcatore 'ip' indica l'indirizzo IP del client, 'ht' il tipo di
rete a cui è connesso il client e 'ha' il suo indirizzo hardware. Il
marcatore 'vm=auto' dice a bootpd di usare la stessa codifica del
produttore della bootrom. Se il proprio client diskless dovrà usare il
suo filesystem principale via NFS bisognerà anche specificare la
directory sul server che verrà montata in seguito tramite il marcatore 'rp'.
Invece, se il proprio client diskless usa un ramdisk è possibile
omettere 'rp'. Quando si sceglie di usare la bootrom standard col
display driver ANSI (per maggiori informazioni vedere più avanti) si
potrebbe anche preparare un menu per lasciar scegliere all'utente fra
i diversi file contenenti le immagini di avvio. Per sapere come
realizzare una tal cosa si veda il file INSTALL.menu. Personalmente
raccomando di usare prima il modo standard di preparare il file
bootptab come descritto sopra; sarà sempre possibile aggiungere un
menu in seguito. Ovviamente bisogna anche ricordarsi di fare in modo
che bootpd giri sul server, all'avvio tramite /etc/rc (o con qualche
meccanismo del genere) o tramite inetd. Di nuovo, vedere la
documentazione del proprio server per sapere come fare.
Il passo successivo effettuato dalla bootrom, dopo aver fatto la
richiesta al server bootp, è di caricare il file con l'immagine di
avvio specificato dai marcatori 'hd' e 'bf' in /etc/bootptab. Per far
ciò si usa un protocollo chiamato tftp. Quindi si dovrà poi preparare
sul server un processo demone per questo protocollo. Un tale demone di
solito si chiama tftpd e bisogna di nuovo ricordarsi di fare in modo
che tftpd stia girando, in genere tramite inetd. Dato che il protocollo
TFTP è un modo di accesso al server tftpd molto insicuro, di solito
tale accesso viene ristretto (tramite tftpd stesso, o con un wrapper
TCP/IP tipo tcpd). Ad esempio, tcpd usa delle tabelle di controllo
d'accesso all'host che vengono memorizzate in /etc/hosts.allow e
/etc/hosts.deny. Per maggiori informazioni vedere tftpd(8), tcpd(8),
hosts_access(5) e la documentazione del proprio server.
Se si è scelto un ramdisk per la directory principale del client
diskless allora la preparazione del server è finita; ma se il client
userà NFS (direttamente per avviare Linux o usando programmi contenuti
nel ramdisk) allora bisogna preparare tutto l'occorrente per montare
una directory NFS sul server. Ciò in genere implica l'esecuzione di
diversi programmi: portmap, mountd, nfsd e opzionalmente ugidd. Ma per
usare mountd e nfsd bisogna specificare i permessi che consentono al
client di accedere alle directory necessarie sul server. I suddetti
permessi vengono di solito impostati tramite un file chiamato
/etc/exports, che per il nostro client d'esempio somiglia al seguente:
#
# Export directories for client1 (diskless workstation)
#
/boot/client1/root client1(rw,link_absolute)
/boot/client1/usr client1(rw,link_absolute)
Se si usa 'map-daemon' per mappare i numeri UID e GID sul server
bisogna ricordarsi anche di configurare e lanciare ugidd sul server.
Si consulti la documentazione del proprio server per avere maggiori
informazioni riguardo alla configurazione delle esportazioni NFS.
Forse è il caso di consultare anche le pagine di manuale di portmap(8),
nfsd(8), mountd(8) e ugidd(8). Si ricordi inoltre che l'accesso ad
ognuno di tali servizi sul proprio server dovrebbe essere limitato
tramite tcpd.
Un altro passo importante è riempire la directory principale del
client diskless. Essa deve contenere tutti i file necessari al client
per avviarsi e montare altre directory via NFS (come un filesystem
/usr tipo quello specificato nell'esempio precedente di /etc/exports).
Come configurare tale directory principale va ben oltre lo scopo di
questa documentazione; diamo solo un suggerimento: se sul proprio
server _non_ sta girando Linux bisognerà fare attenzione a come sono
assegnati i numeri principale/secondario nella directory
/boot/client1/root/dev. Ad esempio usando semplicemente mknod su un
server AIX potrebbe dare dei numeri principale/secondario errati
quando la directory viene poi esportata su un client diskless Linux.
Con alcune configurazioni, AIX aggiunge un certo scostamento a tutti i
numeri primari rendendoli inutilizzabili con Linux. Per maggiori
informazioni si faccia riferimento al manuale del proprio server. Se
il proprio client usa Linux si potrebbero trovare alcuni utili
suggerimenti nel file Documentation/nfsroot.txt.
Preparazione del client, inclusa la compilazione della bootrom
==============================================================
Finora si è dovuto lavorare solo sul server (con la sola eccezione
dell'avviare il proprio client diskless da un dischetto per controllare
la correttezza del filesystem principale). Come ultimo passo possiamo
ora occuparci della preparazione del client stesso.
Il primo passo è di configurare la scheda di rete del client diskless.
Per far ciò si faccia riferimento al manuale fornito con la scheda di
rete. Alcune schede richiedono l'inserimento di ponticelli, altre hanno
dei programmi di configurazione da eseguire. Dopo aver configurato
l'interfaccia di rete è il caso di scriversi i parametri hardware
necessari, come gli indirizzi I/O, gli indirizzi di memoria, il numero
della linea interrupt o il canale DMA, visto che tali informazioni
potrebbero servire più tardi nella fase di configurazione.
Poi si passi nella directory netboot sul proprio sistema UNIX (quello
in cui si trova questo file di documentazione) e si digiti
make bootrom
Così verranno compilati tutti i programmi di utilità necessari, quindi
si esegua il programma di configurazione. Esso chiederà innanzitutto
quale kernel di bootrom si vuole usare. Il kernel minimo è obbligatorio
per le schede di rete che accettano solo fino a 16 KB di ROM; kernel86
può essere usato per l'avvio su sistemi a 16 bit (precedenti ai 386),
per esempio per avviare l'MS-DOS. A meno che non si abbiano necessità
particolari va scelto il kernel standard. Poi bisogna specificare il
packet driver da usare con la propria scheda di rete. È possibile
scegliere uno dei driver forniti o usarne uno proprio. Se si vuole
usare il proprio driver bisogna dare il path completo, relativo al
proprio server, del pacchetto col driver in binario e bisogna anche
indicare tutte le opzioni necessarie per lanciarlo.
Non si specifichino qui opzioni che portano il packet driver in modo
windows o che gli permettano di lavorare per sistemi diskless; tali
opzioni sono solo per bootrom di reti Novell e non sono necessarie
per questa bootrom.
Se si usa uno dei driver elencati il programma di configurazione
chiederà tutte le informazioni sull'hardware necessarie per far girare
il packet driver che si è scelto. Di solito verrà chiesto l'indirizzo
I/O della scheda di rete, il suo numero di interrupt e il numero del
canale DMA. Si osservi che vengono chieste solo le informazioni
strettamente necessarie. Bisogna avere le specifiche della propria
scheda di rete a portata di mano quando vengono chieste tali
informazioni. Alcuni packet driver sono in grado di rilevare le
informazioni sull'hardware in fase di esecuzione e quindi non
richiederanno nessun altra informazione.
Se non si è scelto il kernel minimo allora il programma di
configurazione chiederà se si vuole siano inclusi dei driver
addizionali. Innanzi tutto permetterà di scegliere il driver per
il display ANSI, che consente di disegnare sullo schermo dei graziosi
menu con il kernel della bootrom standard. Poi è possibile selezionare
il programma di debugging del packet driver (è un modulo aggiuntivo
che serve per tracciare problemi di rete e di solito non è necessario).
Esso mostra la prima coppia di byte di tutti i pacchetti (in cui gli
header UDP/IP sono codificati) passando poi al packet driver in fase
di avvio del client diskless. Si selezioni questo modulo di debug solo
se si riscontrano problemi durante il processo iniziale di avvio dalla
rete della bootrom _e_ si sanno interpretare le informazioni degli
header UDP/IP. Il programma di configurazione chiederà anche se si
vogliono installare nella bootrom altri moduli aggiuntivi. Tali moduli
devono essere dei programmi di tipo COM standard DOS che potrebbero,
ad esempio, preimpostare la scheda di rete in uno stato particolare
prima che parta il packet driver, oppure potrebbero configurare una
linea seriale per supportare l'avvio tramite connessione PPP o SLIP
(la raccolta di pacchetti Crynwr contiene anche un driver per pacchetti
SLIP che non è fornito con questo pacchetto). Comunque si tenga
presente che la dimensione totale della immagine definitiva della
bootrom non può superare i 64 kB.
Quando si è risposto a tutte le domande il programma di configurazione
crea il kernel della bootrom con tutti i moduli scelti, poi comprime
il file risultante ed aggiunge il codice di avvio della bootrom. Una
volta che il programma di configurazione ha finito, si troveranno due
nuovi file nella directory corrente:
image.flo - questo file può essere scritto su un floppy
usando dd
image.rom - l'immagine da bruciare in una EPROM
Bisogna ora copiare image.flo in un floppy usando
dd if=image.flo of=/dev/fd0
e poi avviare il proprio client diskless usando tale floppy. Se è
tutto pronto (inclusa la propria scheda di rete) si vedrà il codice
della bootrom che parte, fa richiesta al server bootp e carica il file
con l'immagine di avvio. Quando tutto funziona come richiesto si può
andare avanti e scrivere il codice image.rom in una EPROM. Per le
istruzioni su come farlo si consulti il manuale del proprio scrittore
di EPROM. Di solito bisognerà convertire il file immagine in un formato
speciale (ad esempio il formato esa di Intel o Motorola). Si inserisca
la EPROM nello zoccolo della propria scheda di rete e si accenda il
sistema diskless. Si dovrebbe veder partire la bootrom.
Un altro modo di mettere il codice bootrom nel proprio client è di
usare la scheda Flash-EPROM (chiamata FlashCard), di cui è possibile
trovare uno schema e un modello di circuito stampato in questo pacchetto.
È possibile scrivere direttamente image.rom nella FlashCard - non serve
nessuna conversione in esa. Riguardo l'uso e la programmazione della
FlashCard si veda la documentazione nella directory di FlashCard.
Qualora si vogliano creare nuove bootrom senza dover sempre avere i
sorgenti a portata di mano, è possibile installare i binari creati
durante il processo di configurazione tramite il comando
make bootrom_install
Così si copieranno nella directory $prefisso/lib/netboot (dove
$prefisso è /usr/local o il prefisso specificato nell'esecuzione del
configure GNU) tutti i binari necessari per creare nuove bootrom.
Il path tipico sarà /usr/local/lib/netboot. Verrà anche installato lo
script makerom in $prefisso/bin; così sarà sufficiente battere makerom
per creare una nuova bootrom.
Appendice: Ricompilare la bootrom
=================================
Se, per qualunque motivo, si vuole ricompilare la bootrom, si consulti
il file INSTALL.bootrom per ottenere maggiori informazioni. Comunque
non è necessario ricompilare la bootrom solo per poterla usare!