Recuperare pacchetti critici

[djinnZ]

Dalla discussione iniziata qui mi sono reso conto che può capitare di rendere inutilizzabili o cancellare dei pacchetti la cui presenza è indispensabile: gcc, bzip2, make etc.
Ovviamente il primo modo è utilizare questo suggerimento e, dopo aver reso disponibile il nostro backup, lanciare un

Code: Select all

emerge -1OC pacchetto ; emerge -1OK pacchetto

oppure

Code: Select all

tar -xjf /usr/portage/packages/All/pacchetto.tbz2 /

, ovviamente ne caso si tratti tar o bzip non sarà possibile del tutto, e la seconda opzione lascerebbe il nostro sistema "sporco" e non è detto che il binario possa funzionare.
Come mi hanno fatto notare per chi è meno esperto potrebbe non esser chiaro cosa voglia dire "sporco". Emerge non si limita a copiare i file da var/tmp/... nel sistema ma ne registra l'elenco e provvede ad eliminare i file delle precedenti versioni proteggendo da sovrascrittura le configurazioni etc.
Riportare brutalmente il contenuto di un applicativo nell'albero principale non solo potrebbe cancellare irrimediabilmente la configurazione del proxy sulla quale abbiamo perso una settimana (per dirne una) ma potrebbe comunque lasciare l'applicativo inutilizzabile a causa di qualche dipendenza di libreria non più necessaria che non è stata "fisicamente eliminata" e sicuramente c'è il rischio di avere dei "falsi positivi" lanciando il comado revdep-rebuild.

Aggiornamento: quando ho scritto questa guida i signori devel non erano così gentili e premurosi da mettere costantemente a disposizione uno stage3 aggiornato ed un repository binario dei pacchetti in esso contenuti.
Quindi, adesso che ci hanno fatto dono di questa preziosa risorsa sarebbe scortese nei loro confronti non approfittarne, soprattutto per un caso tutt'altro che infrequente: sistema funzionante ma gcc incapace a ricompilare se stesso.
Dalla shell della nostra installazione danneggiata o dal chroot basta lanciare

Code: Select all

PORTAGE_BINHOST="http://tinderbox.dev.gentoo.org/default-linux/x86/ emerge -av1DGK =gcc-4.4.5

Code: Select all

PORTAGE_BINHOST="http://tinderbox.dev.gentoo.org/default-linux/amd64/ emerge -av1DGK =gcc-4.4.5

e così via secondo la nostra architettura.
Nel caso siano altri pacchetti, o si voglia evitare il downgrade di qualcosa ricordo l'opzione -O già illustrata prima.
Per i dettagli ...

Code: Select all

man emerge

come sempre.

Un altro metodo, sempre a condizione che emerge funzioni ancora (ad esempio nel caso sia solo tar o bzip a non funzionare), è tramite il comando ebuild ed un cd di installazione minimale o se è il caso da una live basata su gentoo (kentoo, sabayon e simili). Quando si lancia emerge il programma non fa altro che calcolare le dipendenze e chiamare in sequenza ebuild per compilare ed installare i singoli pacchetti. Quindi nulla ci vienta di procedere manualmente a questa operazione. La guida ufficiale per ebuild è qui.
Se la nostra root è montata nel classico /mnt/gentoo la prima cosa è modificare il /etc/make.conf (senza fare chroot per il momento) per inserire la variabile PORTAGE_TMPDIR=/mnt/gentoo/var/tmp e, dopo aver creato la directory /usr/portage diamo un

Code: Select all

mount --rbind /mnt/gentoo/usr/portage /usr/portage

.
A questo punto, lanciamo il comando (per esempio nel caso di bzip2)

Code: Select all

ebuild /mnt/gentoo/usr/portage/app-arch/bzip2/bzip2-ver.ebuild unpack

a questo punto, dal

Code: Select all

chroot /mnt/gentoo

od anche riavviando nella nostra gentoo abituale:

Code: Select all

ebuild /mnt/gentoo/usr/portage/app-arch/bzip2/bzip2-ver.ebuild compile
ebuild /mnt/gentoo/usr/portage/app-arch/bzip2/bzip2-ver.ebuild install
ebuild /mnt/gentoo/usr/portage/app-arch/bzip2/bzip2-ver.ebuild qmerge

La stessa cosa può esser fatta per baseutils tar, gzip etc.

Ultimo metodo, assai interessante, è installare direttamente i pacchetti dalla live sulla gentoo danneggiata. Come sempre ci serve una distribuzione gentoo funzionate da cui partire.
A questo punto direttamente dalla shell della live, purchè sia in grado di funzionare, impostiamo sempre PORTAGE_TMPDIR=/mnt/gentoo/var/tmp e, dopo aver creato la directory /usr/portage e lanciato

Code: Select all

mount --rbind /mnt/gentoo/usr/portage /usr/portage

, ci affidiamo alle opzioni --root=/mnt/gentoo e --config-root=/mnt/gentoo.
Quindi possiamo persino pensare di usare un comando del genere

Code: Select all

emerge --root=/mnt/gentoo --config-root=/mnt/gentoo -1 gcc

oppure

Code: Select all

emerge --root=/mnt/gentoo --config-root=/mnt/gentoo -1OK python emerge

persino, e qui riflettete bene su quel che implica,

Code: Select all

emerge --root=/mnt/gentoo --config-root=/mnt/gentoo -eOK @system

o

Un'ultima nota (lo so che sembra ovvio e c'è l'8° corollario alla Legge di Murphy ma ci provo) sulla differenza tra -k e -K e -g e -G: -k installa i pacchetti binari se sono disponibili e con le medesime use flag, se le use sono diverse od i pacchetti non sono disponibili vengono ricompilati, -K installa solo i binari (se ci sono); dunque se stiamo installando usando una gentoo gemella potrebbe andar bene ma, se stiamo lavorando da una live, dobbiamo tener presente che è vero che i pacchetti saranno installati sulla ganto ma il linking sarà effettuato alle librerie della live, che ovviamente potrebbero non corrispondere.
Qu8anto a -g, senza -k/-K installa prendendo i binari solo dalla directory configurata con PKGDIR=vattelappesca, -G solo dal(dai) repository remoto configurato con PORTAGE_BINHOST, -g da entrambi.
Non fate confusione perché già sono operazioni delicate, in attuazione di un tentativo estremo di ripristino, se poi siete pure approssimativi ... chissenefrega, i cocci ed il tempo perso sono vostri non miei.

[cloc3]

lanciare un

Code: Select all

emerge -1OC pacchetto ; emerge -1OK pacchetto

oppure

Code: Select all

tar -xjf /usr/portage/packages/All/pacchetto.tbz2

ora torno a casa a mangiare.

ok. devi ancora fare un po' di ordine.

però fai attenzione ad avvertire che, mentre tar colloca semplicemente i file al loro posto, emerge effettua una vero e proprio servizio di installazione, nel senso che aggiorna il database del sistema e ne conserva puntualmente la memoria.
altrimenti, tanto vale passare direttamente a Linux from Scratch.

[djinnZ]

Addendum: è possibile che stiamo tentando di intervenire su un sistema in cui anche il database dei pacchetti è stato danneggiato.
Il caso che mi è capitato è stata una perdita forzata di alimentazione nella fase dell'ebuild install che ha reso inutilizzabile tar e che ha lasciato il file /var/db/pkg/app-arch/tar-<versione>/CONTENTS non valido.
Nel mio caso ho risolto sistemando a manina il file in questione (tronco ed ultima linea non valida) ma in alternativa è possibile pensare a qualcosa del genere

Code: Select all

rm -Rf /mnt/gentoo/var/db/pkg/app-arch/tar-<versione>
FEATURES"-collision-protect" emerge --root=/mnt/gentoo --config-root=/mnt/gentoo -1 tar

Potrebbe anche capitare, in alternativa di trovarsi con due directory /var/db/pkg/app-arch/tar-<versione> in questo caso sarebbe meglio stabilire con un md5 quele file CONTENTS rappresenta il sistema e nel caso fare un merge delle due prima di sovrascrivere reinstallando.