Infatti, tra un impegno ed un altro, mi sono accorto sul forum di Arch Linux, e non solo, di dover fornire spiegazioni riguardo questa utility, che non è, d’altronde, ricca di documentazione e spiegata come vorrei (e come vorrebbero). :P

Innanzi tutto, una breve introduzione: chroot serve per entrare in una data directory provvista di filesystem Unix e, all’interno di questa, bash, per sfruttarla alla stregua di una vera e propria directory radice, allo scopo di eseguire programmi o riparare, come mi è successo spesse volte, problemi vari. Nello specifico, mi sono trovato a spiegare chroot nell’ambito della risoluzione di problemi legata a sistemi che, in circostanze varie, non eseguono correttamente la procedura di boot, per cui non ci si può loggare all’interno del sistema per riparare i danni.

Chroot quindi, oltre che una utility per scopi più o meno noti, può servire da trucchetto d’emergenza per riparare al fatto di aver fatto una razzata; spesso si sente dire “Linux va formattato solo in caso di problemi gravissimi”. Ebbene, questo è falso, perchè in caso di problemi gravissimi abbiamo il nostro chroot pronto a darci una mano in qualsiasi circostanza :D

Ma vediamone per bene il funzionamento: innanzi tutto, abbiamo bisogno, come ho detto su, di una subdirectory con un filesystem Unix e la bash installata; nel caso in cui dovessimo riparare dei danni, la nostra partizione target può diventare facilmente una subdirectory del sistema operativo che stiamo utilizzando tramite una semplice operazione di montaggio. Creiamo quindi il punto di aggancio:

sudo mkdir /media/target

E montiamo, finalmente, il nostro pseudo-filesystem, o la partizione bersaglio dei cambiamenti che vogliamo effettuare, legandolo in questo modo alla nostra root reale.

mount /dev/sdaX /media/target

A questo punto, se vogliamo solo modificare dei file senza compiere operazioni che interessino i dispositivi o i dati presenti in /proc, possiamo anche saltare il montaggiodi altre parti del nostro sistema base nel sistema bersaglio. Però, c’è un però.

Però, se vogliamo compiere operazioni come un aggiornamento, che interessa ovviamente alcuni dati di /dev e alcuni dati di /proc, conviene rendere disponibili queste informazioni al sistema ospite; come fare? Tramite altri due comandi di montaggio, il primo che riguardi la directory /dev, e l’altro che interessi /proc: in questa maniera rendiamo leggibili le informazioni riguardo l’hardware della macchina al sistema ospite, che potrà, in parecchi casi, averne bisogno. Per esempio per una ricompilazione del kernel. Per esempio.

Ordunque, andiamo a montare /dev con alcune opzioni che non so minimamente cosa significhino, ma dato che sono scritte sul Gentoo Handbook e le ho usate moltissime volte le prendo per buone :mrgreen:

sudo mount -o bind /dev /media/target/dev

E andiamo poi a montare uno pseudo-proc, almeno da quanto ho capito per via della sintassi di comando leggermente più articolata.

sudo mount -t proc none /media/target/proc

A questo punto, siamo pronti. Possiamo tuffarci nel sistema ospite, ed iniziare riparazioni, modifiche, aggiornamenti, installazioni e quant’altro:

sudo chroot /media/target

Come vediamo, il PS1 è cambiato, e rappresenta il .bashrc che abbiamo impostato per l’utente root sulla directory target, nella quale adesso siamo loggati come root e possiamo effettuare ogni tipo di modifica.

Per uscire dalla nuova directory radice, ovviamente, basta un semplice comando exit ;)

In questo modo, si possono far eseguire programmi in una sandbox a prova di bomba, in quanto non condivide nulla, a parte qualche informazione, con la macchina ospitante. Godetevi il vostro chroot, e cominciate a usarlo massivamente per i compiti più disparati. Posso veramente dire: chroot, mai più senza :mrgreen:

Ho visto così comparire tra le twittate indirizzate a me un messaggio da un bot chiamato GentooTweets, il quale si occupa di aggregare tutto ciò che nella twittersfera viene detto riguardo Gentoo. In genere la cosa serve a scopo promozionale, o comunque per promuovere ciò che di buono c’è in questa distro (e ce n’è parecchio); tuttavia la cosa può anche sortire l’effetto contrario, come dimostra il mio screenshot :D

L’appunto è stato fatto mentre cercavo di applicare una patch a Compiz per farlo compilare con Gconf 2.26.2 su Arch, dato che non so più a che santo votarmi per quel buggarozzo che affligge Metacity di cui ho già parlato più volte :)

Il disappunto è sorto quando mi sono accorto che la patch andava applicata all’ebuild. A quel punto ho smesso di combattere e mandando a quel paese tutto, montando le dita di scorta ho scritto quel messaggio di sconforto. Puntualmente aggregato dal bot :D

E si vola, si vola verso la meta di qualche overlay sapientemente gestito assieme alla mia Gentoo ~x86.

Ma per ora non voglio esagerare, ho raggiunto il primo traguardo, e la cosa non è indifferente: ho una Gentoo ~x86 perfettamente funzionante, con kernel configurato all’osso e senza initrd; ma come è potuto accadere tutto ciò? Analizziamo insieme.

Prima di tutto, ho scaricato gli stage e fatto le solite operazioni di rito, descritte ampiamente nell’handbook, e di cui ho dato solo un cenno nel mio precedente post riguardo Gentoo. Successivamente, settando quel che c’era da settare, ho scoperto che avevo scaricato lo stage sbagliato, e la variabile CHOST era impostata su i486-pc-linux-gnu. Poco male: reimpostata, e lanciato un emerge -e world, ma a quanto pare le grane non erano finite. Ovviamente sui primi pacchetti la compilazione si è piantata; ci ho messo molto poco a capire che mi attendeva un’affannosa ricompilazione del GCC e di altre belle cose che per compilare correttamente impiegano secoli.

E così, ho emerso prima il GCC, poi di nuovo il mitico World. In conclusione, ho cominciato ad installare alcune cosette. Ma la nuvola nera incombeva ancora su di me. Nonostante tutte le compilazioni fossero andate perfettamente lisce, libXML rifiutava di compilare, a causa di un mistico errore di GCC.

Visto che il cambio di CHOST (che causava appunto quell’errore) è fortemente sconsigliato, ho preferito non andare contro i capoccioni, ed ho reinstallato. E ari-emergi il mondo. Ovviamente, questa volta le cose sono andate molto meglio: andando in palestra ho potuto lanciare un tranquillissimo emerge gnome-light, per installare, dopo tutte le varie configurazioni del caso, sulla mia Gentoo nuova di pacca, il Desktop Environment che adoro.

Tornando, ho trovato che tutto era andato liscio. Provo così a loggarmi, ma avevo scordato di dare i giusti permessi per quanto riguardava la cartella Home; con una passata di Chown ho risolto il problema, ed ho continuato a divertirmi fino ad arrivare al target sperato. Ho dovuto emergere qualche pacchetto di diversa versione rispetto a quella fornita in maniera predefinita, ma di problemi grandi non ne ho avuti.

Da qui in poi, la strada sembra essere in discesa: si tratta solo di fare un po’ di manutenzione ogni qual volta se ne presenta la necessità, e prestare un po’ di attenzione agli aggiornamenti entranti.

Ovviamente vi aggiornerò con ogni passo mosso in questo nuovo mondo pieno, per me, di eccitanti novità.

Odi et amo. Quare id faciam, fortasse requiris?
Nescio, sed fieri sentio et excrucior.

Traduzione:

Odio e amo. Come faccia, mi chiedi forse?
Non lo so, ma sento che accade e mi tormento.

È giunto il momento. Taglia e cuci sulle partizioni, estrazione dello Stage 3. Portage. E si comincia.

Infatti, come potete vedere dall’immagine, o per meglio dire, da quello che stavo scrivendo al momento nel terminale, mi trovo ancora nella fase di installazione. Non ho ancora un sistema stabile su cui smanazzare libero servendomi di Portage e Nano, tuttavia l’installazione sta procedendo abbastanza tranquillamente.

Spero veramente di riuscire a portare a termine questa installazione, che mi sta divertendo più di qualunque altra cosa mai fatta; per ora procedo con HandBook alla mano, due terminali aperti e Firefox che controlla la posta.

Si comincia.