MintNetInstall
Da MontelLUG WIKI.
Procedimento per installazione di rete di Linux Mint (note di Samuele):
Disclaimer
Ora, qualcuno ha preso una mail mia di promemoria sparata in mailing list e l'ha copiata qui. Siccome c'è il rischio molto alto che queste pagine vengano indicizzate da un qualche motore di ricerca andando così ad incrementare l'entropia di istruzioni confusionarie e scarsamente utili che si trovano in rete riguardo ad un certo argomento, mi vedo costretto nonostante il mio profondo odio per la scrittura, per il linguaggio del wiki, e per gli how-to che non spiegano in modo impeccabile un certo argomento, a metterci mano per dare a questa pagina una parvenza di decenza e renderla un minimo utile a quel povero disgraziato che in preda ad una crisi isterica causata da n-mila tentativi andati a vuoto approda su questa pagina. Siccome l'argomento è lungo, non la finirò in un colpo solo e la riprenderò in mano soltanto quando riuscirò a sedermi davanti ad un pc senza aver passato la giornata a lottare con un branco di luser scassa cocomeri per i motivi più insignificanti. Il titolo riporta "installazione di rete di Linux Mint". In realtà il procedimento con qualche adattamento può essere adattato anche ad altre distro (spiegherò più avanti perché sarebbe bene ammazzare chi imposta il processo di boot delle varie distro).
Se qualcuno ha suggerimenti da dare o si accorge di castronerie da corregere è pregato di editare il wiki o mandare una mail a info (scioso) montellug (punto) it.
Chi, come, dove, quando e perché
Perché
Allora, partiamo dall'ultima domanda: perché. Esistono tanti bei metodi per installare linux, si può partire con il floppy, il cdrom, la chiavetta usb, la clonazione del disco, l'installazione manuale in stile Linux From Scratch, debootstrap, l'installazione da rete e qualche altro sistema che mi sono dimenticato di menzionare o non conosco. Quindi, perché uno sano di mente dovrebbe mettere su tutto l'ambaradam sottostante per installare linux?
- l'installazione delle principali distribuzioni moderni è mortalmente noiosa (qualche settimana fà ho provato a fare l'installazione di una ubuntu 12.04. Mi ha chiesto solo il partizionamento, l'hostname, l'utente e la password. Un paio d'anni e ci leggeranno direttamente il pensiero);
- fà sempre bene sperimentare qualcosa di nuovo;
- si evita di dover masterizzare cd (solo questo punto vale tutta la fatica);
- se avete una rete decente (o non provate ad installare 40 pc in contemporanea su una rete a 100 mbit, con 8 switch da 8 porte presi all'ipermercato collegati in cascata) l'installazione è più veloce;
- applicate un metodo che il Luser 2.0 figlio del cugino del vicino di casa tutto iphone, ipad, isarca$$0 che sa tutti i programmi del mondo, che lui si che è bravo ecc. non sa;
- vedere n pc che si installano in contemporanea, facendo tutto da soli (magari anche si accendono se supportano il wake on lan) premendo solo un bottone... non ha prezzo;
- altri motivi a vostra scelta.
Quando
Quando è il caso di usare questo tipo di installazione? Sicuramente non se dobbiamo installare tre pc per ieri (cioè la norma) e non l'abbiamo mai provata prima. Se però vi installate il server (d'ora in poi la "supermucca" in onore di apt-get moo e del mio HP LH3000 che ha fatto da mirror dei repository in qualche linux day passato), anche sul vostro pc portatile (i pacchetti occupano poca roba, il resto sono le iso che normalmente scaricate) e lo avete a portata di mano, vi renderete conto che tenderete ad usarla sempre. In caso di installazioni di molti pc in contemporanea, beh, questa è la morte sua.
Dove
Ovvio: può essere usata dappertutto se avete a che fare con linux. Con windows, le cose si complicano un pochino e non ho avuto modo di provarle, né l'opportunità di poterle applicare e quindi la motivazione per rompermi i cocomeri a studiarla.
Chi
Inteso come chi può farla, beh, tendenzialmente si può dire che è abbastanza semplice e possono farla tutti. Usare il server già installato è idiot-proof quindi può veramente farlo chiunque. Per preparare il server è richiesto solo di essere un po' svegli, che se qualcosa non va essere in grado di ricercare la soluzione, e avere voglia di imparare un po' di basi di quei 4 protocolli/servizi in croce che vengono usati.
Inteso come chi sono i protagonisti della nostra storia, eccoli qui:
- PXE (Preboot eXecution Enviroment);
- DHCP (Dinamic Host Configuration Protocol);
- TFTP (Trivial File Transfer Protocol);
- NFS (Network File System);
- Linux (la vostra distro preferita con forse qualche aggiustamento).
Come
Se non sono riuscito nel mio intento di farvi passare la voglia di leggere quanto segue e di farvi male... qui sotto è spiegato il come. Buon tedio a tutti!
Requisiti hardware & software
- Hardware:
- Un pc che faccia da server con scheda di rete;
- Uno o più pc (per le prove vanno bene, anzi forse anche meglio delle virtual machine) sempre con scheda di rete; sua suprema tirannia IL PRESIDENTE ha provato a far fare il boot da rete al suo mac book senza esito (magari pretende che il server sia un i-coso, boh), quindi se avete un mac e non vi funziona, prima di suicidarvi, provate con un'altro pc;
- In caso di più pc uno switch e relativi cavi;
- Software; i seguenti software possono risiedere tutti su uno stesso pc o su diversi pc, cambia poco. Nel corso della guida farò riferimento ad uno stesso pc.
- DHCP: con questo dovreste avere familiarità tutti. Qui useremeo qualche opzione in più di questo protocollo. E' molto probabile che il vostro router/firewall che fa da dhcp server in casa o al lavoro non abbia queste opzioni. In questo caso dovrete installare il software a parte;
- TFTP server
- NFS server
- Il file iso di una distribuzione (per semplicità partiamo con una ubuntu (ho provato una 9.04 e una 10.04) oppure una Mint (provato con una 13)).
Collegamenti hardware
Su questo punto siete in grado di arrangiarvi. Se non lo siete... vi mancano un po' troppe cose da conoscere. Imparatevi prima cos'è una rete locale, come è composta, come funziona, cos'è il TCP/IP, un file system, un kernel, un sistema operativo, un device, un disco, la ram, una tabella delle partizioni, una iso ecc. e poi tornate qui. Nei pc client dovete abilitare il boot da rete (PXE boot). Come si abilita dipende dal BIOS del pc in questione. In alcuni casi è già abilitato e basta solo impostarne la priorità al momento del boot (prima del boot da hard disk), in altri bisogna cercare una voce nel BIOS con la quale lo si abilita. Alcuni BIOS più vecchi non prevedono il boot da rete, in questi casi la cosa potrebbe essere delegata alla scheda di rete (se è una di quelle furbe). Nel caso non abbiate né il pc, né la scheda di rete che supporta il boot di rete, esistono delle iso in grado di fare il boot da cd o usb (es.: gpxe) che una volta caricate permettono di fare il boot da rete. Qualcuno qui potrebbe obiettare che a sto punto tanto vale masterizzarsi un cd. Allora, intanto questo cd lo potete riutilizzare più volte per qualsiasi distro, secondo, se avete tanti pc da installare, appena fatto il boot ed il s. o. comincia a caricarsi, potete togliere il cd ed usarlo su ogni una delle restanti macchine una alla volta, mentre con il normale cd dovete tenerlo dentro al pc fino al termine dell'installazione. Potrebbe essere utile abilitare anche il wake on lan.
Qualche accenno di storia: RARP/BOOTP/PXE
Perché il pc possa partire, è necessario che carichi prendendolo da qualche parte il sistema operativo. Nel caso di boot da rete, sono necessarie due cose:
- configurare l'indirizzo di rete;
- trovare il sistema operativo da qualche parte;
Nonostante sia integrato nella quasi totalità dei pc degli ultimi anni, la possibilità di fare il boot da rete risale a molti anni fà (1984). Inizialmente era il protocollo RARP (Reverse Address Resolution Protocol), protocollo tramite il quale un host, partendo dal MAC address riesce ad ottenere l'indirizzo ip associato. Se la richiesta è inviata in modalità broadcast, e vi è un server RARP questo fornirà un indirizzo ip all'host. Se la richiesta veniva fatta in fase di boot, poteva essere usata per fare l'avvio da rete. Questa funzionalità è stata resa obsoleta da BOOTP e DHCP. Il RARP è un protocollo a layer 2. Il BOOTP invece si basa su UDP il che permetteva di avere il server BOOTP anche in una sottorete diversa da quella del client. Inizialmente, per fare il boot tramite BOOTP era necessario l'uso di un floppy che facesse avviare il PC ed inoltrasse la richiesta BOOTP in rete. Poi sono state sviluppate delle schede di rete che implementavano nel loro firmware questo protocollo (nelle schede di rete di qualche anno fà è possibile vedere uno zoccolo vuoto dove inserire il chip per avere questa funzionalità). Nel 1999 da parte di Intel è stato definito il protocollo PXE, che è l'attuale standard. In breve, questo protocollo all'avvio ricerca un server DHCP, il quale server, oltre a fornire l'indirizzo ip del cliente fornisce anche il nome del programma da eseguire (NBP, Network Bootstrap Program) ed il server dove reperirlo. Poi, provvede tramite il protocollo TFTP a scaricarlo nella ram del client e ad eseguirlo.
Installazione del software
In linux esistono n sitemi diversi per installare il software, usate il sistema che preferite. L'importante è che riusciate ad installare un tftp server (nel mio caso tftpd-hpa), un dhcp server (isc-dhcp o dhcp3, anche qui, mi verrebbe da picchiare chi ha rinominato o sostituito su debian & co. dhcp3 con isc e spostato di posto i file di configurazione. No, non ho voglia di andarmi a leggere le mail sulle varie ml per capire le pippe mentali che hanno portato a ciò), un nfs server (nfs-kernel-server).
Configurazione del software
TFTP
Come detto sopra, ho usatto tftpd-hpa. Una volta installato nel mio pc, mi sono trovato il programma configurato per girare tramite inetd. Questo l'ho scoperto dopo almeno un'ora di imprecazioni perché il tftp non mi leggeva il file di configurazione come lo avevo impostato io. Per disabilitarlo basta editare /etc/inetd.conf. Se lo usate tramite inetd dovete modificare i parametri di lancio dentro al file /etc/inetd.con altrimenti, se lo usate in modalità demone stand-alone, dovete editare:
supermucca:/# cat /etc/default/tftpd-hpa # /etc/default/tftpd-hpa TFTP_USERNAME="tftp" TFTP_DIRECTORY="/var/lib/tftpboot" TFTP_ADDRESS="0.0.0.0:69" TFTP_OPTIONS="--secure"
L'unica cosa da prestare attenzione è TFTP_DIRECTORY che è la directory dove andremo a posizionare tutti i file utili per il boot da rete.
DHCP
Rispetto ad una configurazione standard di DHCP, sono stati specificati due parametri, filename e next-server:
supermucca:/# cat /etc/dhcp/dhcpd.conf
<... resto del file>
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.70 192.168.1.100;
filename "pxelinux.0";
next-server 192.168.1.50;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.50;
}
- filename: è il nome del file contenente NBP
- next-server: è il nome/ip del server dove si trova il file pxelinux.0, cioè del nostro server TFTP.
Attenti che se avete altri server DHCP in rete, potrebbero nascere dei conflitti.
Struttura delle cartelle nella root TFTP
Allora, nella root del server TFTP (/var/lib/tftpboot) va copiato l'NBP che è pxelinux.0 e potete trovare ad esempio nei repository di debian in:
main/installer-i386/current/images/netboot/debian-installer/i386/pxelinux.0
Va poi creata una directory pxelinux.cfg all'interno della quale si trovano i file di configurazione che l'NBP legge. A seconda dell'indirizzo ip del client può essere specificato un file di configurazione diverso. Es.: posso avere un file di configurazione per i pc con indirizzo 192.168.0.*, un'altro per 192.168.1.*, un file solo ed esclusivamente per il pc 192.168.1.1 ed un file di configurazione per tutti gli altri casi. Per fare questo, bisogna convertire l'indirizzo ip in esadecimale:
192.168.0.0 = C0 A8 00 00
La configurazione dei client 192.168.0.* va nel file: C0A800
La configurazione dei client 192.168.1.* va nel file: C0A801
La configurazione dei client 192.168.1.1 va nel file: C0A80101
La configurazione di tutti gli altri client va nel file: default
Nel nostro caso useremo un solo file per tutti. Cosa mettere all'interno di questo file lo vedremo qui sotto.
Configurazione di NFS
E' giunto il momento di configurare il server nfs. Basta inserire all'interno del file /etc/exports le condivisioni:
supermucca:/# cat /etc/exports /var/lib/tftpboot/ubuntu *(rw,sync,no_wdelay,no_root_squash,insecure) /var/lib/tftpboot/backtrack *(rw,sync,no_wdelay,no_root_squash,insecure) /var/lib/tftpboot/skole *(rw,sync,no_wdelay,no_root_squash,insecure) /var/lib/tftpboot/mint *(rw,sync,no_wdelay,no_root_squash,insecure) /var/lib/tftpboot/xbmc *(rw,sync,no_wdelay,no_root_squash,insecure)
Nelle directory esportate ho montato direttamente l'iso della distribuzione in oggetto. Non create un link simbolico all'iso montata da qualche altra parte. Il TFTP gira in chroot quindi non riesce ad accedervi. Volevo anche mettere la iso di debian, ma non basta, i file inclusi non vanno bene per il boot di rete e bisogna seguire la procedura che indicano nel loro sito. Con le iso altre distribuzionei tipo centos/fedora/suse non ho ancora avuto modo di provare.
L'idea di partenza era quella di avere un server con le varie iso e permettere di fare il boot di una qualsiasi di esse. Purtroppo a seconda del metodo con il quale può essere fatta l'iso (e ce ne sono diversi) i file contenuti in essa potrebbero non andare bene, quindi bisogna valutare caso per caso.
Personalmente ho avuto un problemino con il server nfs per il quale ho fatto una fatica boia a trovare la soluzione. Finché installavo un solo pc attaccato con cavo cross al server, oppure i client erano in macchine virtuali non ho avuto problemi. Nel momento in cui i pc diventavano più di uno ho cominciato ad avere problemi. I client riportavano in console "NFS server is not responding, still trying". Le ricerche su google mi reindirizzavano su forum con le soluzioni più improbabili. Inoltre in nessun tutorial si parlava di questo problema (quindi, a questo punto, o sono io sfigato che mi capitano tutte le rogne di sto mondo, oppure chi fa i tutorial si limita a scopiazzare). Il problema alla fine era questo: il kernel di linux, di default legge e scrive via NFS blocci di 1 MB. Ogni frame ethernet normalmente è lunga al massimo 1500 byte. Questo comportava che se su tutte le oltre 700 frame che servono per inoltrare 1 MB anche una sola risultava persa (o il client non riusciva più a riordinarle ecc.), il client le richiedeva di nuovo tutte. Infatti, avevo un traffico bestiale di rete in confronto ad i dati trasferiti. Qui adesso salta fuori il secondo problema. Il parametro con le dimensioni dei pacchetti NFS, rsize e wsize, non si specifica lato server ma client. Come? Una rapida ricerca, mi ha dato che il kernel di linux, tra i parametri della share nfs dove monta root si può indicare anche la dimensione della frame: bastava dare
nfsroot=192.168.1.50:/var/lib/tftpboot/mint,rsize=8192,wsize=8192
Inspiegabilmente il parametro non veniva recepito. Prova e riprova un pomeriggio in varie salse, aggiungendo spazi, togliendo virgole ecc. Non c'è verso. Ad un certo punto, intercetto su un forum il post di uno che si lamenta di come vengono interpretati i parametri di boot di CASPER (programma che permette il boot delle live). Parlano di un'opzione nfsopts. Dopo un altro po' di googlate scopro che questo CASPER le opzioni le accetta in modo diverso dal kernel. Mi chiedo io, ma pareva brutto e complicato fare che accettasse gli stessi parametri CON LA STESSA sintassi del kernel? Presumo di no, altrimenti la gente non sbaglierebbe e non direbbe abbastanza parolacce. Per quello che serviva a me la sintassi è:
nfsroot=192.168.1.50:/var/lib/tftpboot/mint NFSOPTS="-o rsize=8192"
Da notare che tutti i parametri sono in minuscolo mentre NFSOPTS deve essere obbligatoriamente in maiuscolo. Lascio alla vostra fervida fantasia cosa avrei fatto se avessi avuto di frontre a me chi ha scritto, revisionato, convalidato, scritto la documentazione, testato il parser dei parametri di CASPER. Pensate sia finita qui? Vi sbagliate. Andando alla ricerca di questo casper, vi imbattete nella sua manpage tipo questa: http://manpages.ubuntu.com/manpages/karmic/man7/casper.7.html in cui l'unica citazione NFSOPTS è:
netboot[=nfs|cifs]
This tells casper to perform a network mount. The parameter
"nfsroot=" (with optional "nfsopts="), should specify where is
the location of the root filesystem. With no args, will try
cifs first, and if it fails nfs.
Sta volta sto zitto.
Dopo che sono riuscito a passare questo parametro al kernel per il boot della iso, l'installazione è proceduta in modo rapido e senza riportare errori var NFS. A farmi venire ancora il fegato più grosso, è stato l'indicizzatore di google, perché cercando NFSOPTS, mi ha dato tra i primi risultati questa pagina:
http://www.informit.com/articles/article.aspx?p=1328789&seqNum=8
dove il paragrafo che spiegava il parametro NFSOPTS è intitolato: "NFS Server Is Not Responding". Putt4|\|4, |\/|153r14, \/4cc4, l4dr4, |\/|4l3d3tt4. La stessa stringa esatta, sputata, spiaccicata di ricerca che ho digitato per quasi un giorno, spulciato in modo sequenziale tutti i risultati che mi dava e su quella pagina non ci sono capitato. Che dire, a tutto c'è un limite, tranne che alla sfiga.
Preparazione del file system da montare durante il boot
Ad esempio, nel caso di Mint, ho designato come root directory per i file /var/lib/tftpboot/mint. Qui dentro andrebbero tutta una serie di directory e file necessari a far fare il boot al pc. Sulla guida di debian al PXE boot trovate tutto spiegato per benino. Inutile che mi ripeta. Come detto precedentemente, il mio obiettivo era evitare di dover creare la struttura di directory per ogni distribuzione che volevo mettere a disposizione. Con le derivate di Ubuntu, che sembrano essere fatte tutte allo stesso modo, questo si è rivelato alquanto semplice. Basta semplicemente montare in loop l'iso nella directory prescelta:
supermucca:/# mount -o loop /archivio-iso/linuxmint-13-mate-dvd-32bit.iso /var/lib/tftpboot/mint
File di configurazione per il boot di iso
Adesso che abbiamo preparato tutte le directory ed i servizi vari, è ora di dire al buon NBP (in arte pxelinux.0) che cosa fare quando viene caricato. Purtroppo, sarà anche buono e bravo, ma anche lui ha la sfera di cristallo perennemente in riparazione, così dobbiamo istruirlo. Come detto in precedenza nel paragrafo "Struttura delle cartelle nella root TFTP", l'NBP cerca nella directory pxelinux.cfg un file di configurazione. Nel nostro caso il file si chiama "default".
La versione minima è questa:
LABEL mint
KERNEL mint/casper/vmlinuz
APPEND root=/dev/nfs boot=casper netboot=nfs nfsroot=192.168.1.50:/var/lib/tftpboot/mint NFSOPTS="-o rsize=4096" initrd=mint/casper/initrd.lz ro splash --
All'interno del file, possiamo avere più configurazioni, una per ogni boot che vogliamo fare, come ad esempio con grub. Il comando LABEL da il nome alla voce di boot. KERNEL indica il nome del file contenente il kernel. Il path è relativo alla root di tftp. APPEND fornisce i parametri aggiuntivi che vengono passati al kernel. Ora, dove trovare questi parametri? Trattandosi di distribuzioni live, il modo più semplice è fare il boot di queste immagini ed andarli a scopiazzare dal menù che compare all'avvio. In alternativa li ricopiate direttamente dal file di configurazione del menù presente nella iso (nel caso di Mint si trova in isolinux/isolinux.cfg). Ovviamente alcuni parametri saranno diversi in quanto isolinux.cfg è pensato per il boot da cdrom, mentre noi lo facciamo da rete.
Sempre nel caso di questa Mint che è alquanto semplice, i parametri hanno questo significato:
- boot=casper: non deve fare il boot normalmente, ma usando casper "casper - a hook for initramfs-tools to boot live systems." come recita la man page. Cioè deve fare il boot in modalità "live", quindi con il file system in RAM;
- initrd=mint/casper/initrd.lz: dove si trova il file contenente l'initrd; come nel caso del kernel, il path deve essere riferito alla root di TFTP;
- netboot=nfs: andiamo a dire che la directory di root deve essere montata di tipo nfs;
- root=/dev/nfs: andiamo a dire che la root va montata da /dev/nfs;
- nfsroot=192.168.1.50:/var/lib/tftpboot/mint: diciamo dove si trova la root sul server nfs;
- NFSOPTS="-o rsize=4096": le fantomatiche opzioni per nfs che tanto mi hanno fatto "divertire".
Come ho detto, questo è il minimo. In fase di boot vi comparirà il prompt:
boot:
dove dovrete digitare:
boot: mint
e premere invio. A questo punto inizierà il boot. Qualora non vi piaccia ricordarvi a memoria tutte le possibili scelte, esiste la possibilità di mostrare un file di testo a video in cui scrivete, salutate, insultate ecc. chi vi sta davanti e gli potete fornire l'elenco di scelte per il boot. Il file va piazzato sulla root di tftp. Il file io l'ho chiamato boot.txt. Un esempio può essere questo:
supermucca:/var/lib/tftpboot# cat boot.txt - Boot Menu - ============= backtrack mint squeeze debian ubuntu
Sempre per il motivo della suddetta sfera di cristallo rotta, dobbiamo dire a pxelinux.0 di usare quel file, per questo basta aggiungere all'inizio del file di configurazione la direttiva:
DISPLAY boot.txt
Ovviamente, non aspettatevi menù graficosi o altro. Comunque, c'è la possibilità di farli. Lascio a voi il compito di imparare come si fanno. A me non servono. :-D.
Un altro paio di direttive utili in questo file di configurazione sono:
DEFAULT mint TIMEOUT 3 PROMPT 1
- DEFAULT: E' la command line di default;
- TIMEOUT: Timeout (in decimi di secondo), trascorso il quale senza che l'utente abbia premuto un tasto viene effettuato il boot con la scelta di default;
- PROMPT: Se vale 1 compare la scritta "boot:" per il prompt, se vale 0 il prompt compare solo se è premuto il tasto shift, alt oppure sono attivi il tasto fissa maiuscole o scroll lock.
Per ulteriori info: http://www.syslinux.org/wiki/index.php/SYSLINUX
Configurazione per il netboot di una normale installazione linux
Fin qui abbiamo provato a far partire delle normali distribuzioni live. Ora, mettiamo il caso che non abbiate nulla da fare, vi abbiate fatto prendere la mano da sta storie e vi venga la malsana idea di provare a far funzionare una macchina con tutto il file system in remoto mentre i programmi girano in locale.
Dovete fare questi pochi passaggi:
- procedete con l'installazione locale della macchina come solito. Dovete poi costruire un nuovo initrd configurato per il boot da rete:
pc01:/# cd /etc pc01:/etc# cp -R initramfs-tools initramfs-tools-pxe
- editare /etc/initramfs-tools-pxe/initramfs.conf ed impostando tra le varie variabili:
MODULES=netboot BOOT=nfs
per i dettagli dei comandi fate riferimento ai commenti nel file o alla man page di initrafmfs.conf
- generare il nuovo initrd e copiarlo dentro alla directory di TFTP:
pc01:/# mkinitramfs -d /etc/initramfs-tools-pxe -o /boot/initrd.img-2.6.32-5-amd64-pxe 2.6.32-5-amd64 pc01:/# cp /boot/initrd.img-2.6.32-5-amd64-pxe /var/lib/tftpboot/mio-boot pc01:/# cp /boot/vmlinuz-2.6.32-5-amd64 /var/lib/tftpboot/mio-boot
- editare /etc/fstab in modo che contenga la riga:
/dev/nfs / nfs defaults 1 1
altrimenti appena caricato il kernel non riuscirà a montare la root;
- poniamo che sulla supermucca intendiate montare il file system completo in /var/lib/tftproot/mio. Modificate /etc/exports in modo che contenga:
/var/lib/tftproot/mio *(ro,sync,no_wdelay,no_root_squash,insecure)
- modificare il file 'pxelinux.cfg/default in modo che contenga:
LABEL pc01
KERNEL mio-boot/vmlinuz-2.6.32-5-amd64
APPEND ro quiet initrd=mio-boot/initrd.img-2.6.32-5-amd64-pxe netboot=nfs nfsroot=192.168.1.50:/var/lib/tftpboot/mio root=/dev/nfs init=/sbin/init --
Installazione completamente automatizzata: file di preseed
Cosa può andare storto
La risposta è sempre la solita: tutto. D'altronde... failure is always an option.
Mi limiterò quindi a dire quelle che sono state sulla base della mia esperienza le cose che sono andate storte.
Facciamoci del male
L'initrd: chi è, cosa fà e cosa vuole dalla nostra vita
Affinché il nostro computer funzioni correttamente, il kernel deve contenere tutti i moduli corretti per funzionare con l'hardware su cui gira. Includere nel kernel tutti i possibili moduli esistenti lo farebbe ingrossare notevolmente con conseguente uso di molta memoria. Per evitare questo problema, il kernel contiene solo alcuni moduli essenziali, il resto vengono messi in un file compesso chiamato initrd. Questo file, non fa altro che contenere al suo interno un mini file system che viene caricato in meoria. Qualora sia necessario aggiungere un nuovo modulo, basta includerlo in questo file senza dover ricompilare il kernel. Una volta che il kernel ha caricato tutti i moduli necessari per montare il file system che si trova su disco (moduli del controller del disco, file system, raid software, ecc.) vine chiamata la funzione pivot_root che smonta il file system in ram con quello su disco.
Nel corso degli anni si sono succeduti vari formati per questo file (http://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt). Ai più curiosi, consiglio di scompattare il file e darci un'occhiata:
supermucca:/# mkdir /tmp/caca supermucca:/# cd /tmp/caca supermucca:/tmp/caca# cp /boot/initrd.img-2.6.32-5-amd64-pxe initrd.gz supermucca:/tmp/caca# gunzip initrd.gz supermucca:/tmp/caca# cpio -i -d -H newc -F initrd --no-absolute-filenames
A questo punto in /tmp/caca troviamo:
supermucca:/tmp/caca# ls -la totale 18000 drwxr-xr-x 9 root root 4096 8 lug 15.09 . drwxrwxrwx 17 root root 4096 8 lug 13.32 .. drwxr-xr-x 2 root root 4096 8 lug 09.47 bin drwxr-xr-x 3 root root 4096 8 lug 09.47 conf drwxr-xr-x 6 root root 4096 8 lug 09.47 etc -rwxr-xr-x 1 root root 4238 8 lug 09.47 init -rw-r--r-- 1 root root 18360320 8 lug 09.46 initrd drwxr-xr-x 6 root root 4096 8 lug 09.47 lib drwxr-xr-x 2 root root 4096 8 lug 09.47 lib64 drwxr-xr-x 2 root root 4096 8 lug 09.47 sbin drwxr-xr-x 8 root root 4096 8 lug 09.47 scripts
Quindi, se al kernel in fase di avvio viene passato il parametro initrd provvede a scompattare il file in ram e montarlo come root (/), poi verifica se nella root esiste il file init e lo esegue. Il file è un normale file bash, quindi abbastanza comprensibile dalla maggior parte delle persone che hanno avuto il coraggio di arrivare fino a qui. In poche parole, crea le directory /dev, /root, /sys, /proc, /tmp, provvede a montarle, avvia udev, fa il parsing dei parametri che vengono passati al kernel (/proc/cmdline). Qualora al parametro boot venga passato il valore casper, viene eseguito lo script /scripts/casper piuttosto che il default che è /scripts/local.
Casper: un fantasma in fatto di documentazione
Purtroppo non sono riuscito a recuperare documentazione su questo argomento. Si tratta di una serie di script contenuti nell'initrd che permettono il boot del sistema in modalità live. Casper in fase di avvio va alla ricerca di una directory /casper contenente il file system di root. Se lo trova, attraverso l'uso di unionfs viene creato un file system scrivibile.