# 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 

```
emerge -1OC pacchetto ; emerge -1OK pacchetto
```

 oppure 

```
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 

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

```
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 ... 

```
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 

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

.

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

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

a questo punto, dal 

```
chroot /mnt/gentoo
```

 od anche riavviando nella nostra gentoo abituale:

```
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 

```
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 

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

oppure

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

persino, e qui riflettete bene su quel che implica,

```
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

 *djinnZ wrote:*   

> lanciare un 
> 
> ```
> emerge -1OC pacchetto ; emerge -1OK pacchetto
> ```
> ...

 

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 

```
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.

----------

