# [Lungo] Ho ucciso la mia Gentoo...

## Jabber00

Salve,

questo e' il mio primo post, sebbene abbia lurkato qualche volta alla ricerca di soluzioni per i problemi che mi si sono presentati via via con Gentoo!

Oggi pero' la situazione e' tale da richiedere un post ad hoc!

Veniamo al problema: venerdi', tutto contento e felice, ho deciso di cambiare il disco al sistema su cui ho installato Gentoo: in origine vi erano due dischi, uno da 80 GB  per i dati, uno da 6.4 per il sistema; ho deciso di sostituire il disco dati con una da 160GB e di togliere del tutto il disco da 6.4, "promuovendo" quello da 80 GB a disco di sistema! Ho quindi montato il 160GB, copiato i dati e quindi ho eliminato tutte le partizioni sull'80GB, in modo da ricopiare il 6.4 su di lui e fare il cambio... ma ho dimenticato un piccolo, insignificante dettaglio: in una delle partizioni dell'80GB era  montata /var  :Rolling Eyes: 

Ovviamente mi sono accorto dell'errore solo quando ho riavviato il sistema (non riuscivo ad accederci da remoto e, controllando sul suo monitor, ho scoperto il misfatto)!

Per cercare di recuperare qualcosa, ho dato emerge -e system && emerge -e world, ma prima mi sono bloccato per un errore sulle glibc (modifica USE), poi un altro errore, sempre sulle glibc (modifica del compilatore gcc con gcc-config), infine, quando tutto sembrava andare per il meglio (glibc venivano compilate) e' saltata la corrente (si, non ho un UPS su quel sistema   :Embarassed:  )! Bestemmioni vari (era nel bel mezzo della compilazione delle suddette), riaccendo e... sorpresa: una marea di errori (mi pare di capire che sia saltato qualcosa in /etc e in qualche altra directory... non ho il PC in questione vicino e a memoria e' difficile ricordare! BTW, se puo' servire, cerco di postarle in ualche modo!), il che impedisce di avviare in automatico la rete, tutti i servizi collegati, fa avere un errore se mi autentico con il mio user (permesso negato, ma poi entra, sebbene non riesca, per esempio, ad avviare vncserver), mentre riesco ad autenticarmi come root! Al che rilancio la compilazione delle glibc (emerge glibc), sperando di recuperare la situazione, ma nulla: finita la compilazione do un emerge -e system && emerge -e world e, al primo pacchetto,  sys-libs/zlib-1.2.3-r1

ottengo: 

```
make: *** [example] Error 1

make: *** Waiting for unfinished jobs....

!!! ERROR: sys-libs/zlib-1.2.3-r1 failed.

Call stack:

  ebuild.sh, line 1546:   Called dyn_compile

  ebuild.sh, line 937:   Called src_compile

  zlib-1.2.3-r1.ebuild, line 39:   Called die

!!! (no error message)

!!! If you need support, post the topmost build error, and the call stack if relevant.

```

Ora, secondo voi ho speranza di sistemare tutto o cancello nuovamente le partizioni e riparto con una installazione ex novo?

Se riuscissi a ripristinare la versione "fallata" (aka senza /var), il comando che avevo dato prima di questo caos mi darebbe la speranza di risistemare tutto o e' solo una perdita di tempo?

Grazie!

----------

## Peach

ciao, innanzitutto ti sono vicino in questo momento di dolore e disperazione. 

per quanto riguarda il tuo problema, la situazione è davvero incasinata... perdi la var, blackout e chissà cos'altro.

in ogni caso dall'errore postato non si capisce molto... sarebbe utile sapere cosa c'era prima

vorrei farti notare questo:

```
!!! If you need support, post the topmost build error, and the call stack if relevant. 
```

----------

## Jabber00

 *Peach wrote:*   

> ciao, innanzitutto ti sono vicino in questo momento di dolore e disperazione. 
> 
> per quanto riguarda il tuo problema, la situazione è davvero incasinata... perdi la var, blackout e chissà cos'altro.
> 
> in ogni caso dall'errore postato non si capisce molto... sarebbe utile sapere cosa c'era prima
> ...

 

Mi sono scappate due righe dal copia/incolla, sorry! Forse e' meglio se posto tutto l'output di emerge:

```
SLASHmk2 ~ # emerge zlib

Calculating dependencies... done!

>>> Emerging (1 of 1) sys-libs/zlib-1.2.3-r1 to /

 * zlib-1.2.3.tar.bz2 MD5 ;-) ...                                         [ ok ]

 * zlib-1.2.3.tar.bz2 RMD160 ;-) ...                                      [ ok ]

 * zlib-1.2.3.tar.bz2 SHA1 ;-) ...                                        [ ok ]

 * zlib-1.2.3.tar.bz2 SHA256 ;-) ...                                      [ ok ]

 * zlib-1.2.3.tar.bz2 size ;-) ...                                        [ ok ]

 * checking ebuild checksums ;-) ...                                      [ ok ]

 * checking auxfile checksums ;-) ...                                     [ ok ]

 * checking miscfile checksums ;-) ...                                    [ ok ]

 * checking zlib-1.2.3.tar.bz2 ;-) ...                                    [ ok ]

>>> Unpacking source...

>>> Unpacking zlib-1.2.3.tar.bz2 to /var/tmp/portage/zlib-1.2.3-r1/work

 * Applying zlib-1.2.3-visibility-support.patch ...                       [ ok ]

 * Applying zlib-1.2.1-glibc.patch ...                                    [ ok ]

 * Applying zlib-1.2.1-build-fPIC.patch ...                               [ ok ]

 * Applying zlib-1.2.1-configure.patch ...                                [ ok ]

 * Applying zlib-1.2.1-fPIC.patch ...                                     [ ok ]

 * Applying zlib-1.2.3-r1-bsd-soname.patch ...                            [ ok ]

 * Applying zlib-1.2.3-LDFLAGS.patch ...                                  [ ok ]

>>> Source unpacked.

>>> Compiling source in /var/tmp/portage/zlib-1.2.3-r1/work/zlib-1.2.3 ...

Checking for shared library support...

No shared library support; try without defining CC and CFLAGS

Building static library libz.a version 1.2.3 with i686-pc-linux-gnu-gcc.

Checking for unistd.h... Yes.

Checking for attribute(visibility) support... Yes.

Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf()

Checking for vsnprintf() in stdio.h... No.

  WARNING: vsnprintf() not found, falling back to vsprintf(). zlib

  can build but will be open to possible buffer-overflow security

  vulnerabilities.

Checking for return value of vsprintf()... Yes.

Checking for errno.h... Yes.

Checking for mmap support... Yes.

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o example.o 

example.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o adler32.o 

adler32.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o compress.o

 compress.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o crc32.o cr

c32.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o gzio.o gzi

o.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o uncompr.o 

uncompr.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o deflate.o 

deflate.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o trees.o tr

ees.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o zutil.o zu

til.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o inflate.o 

inflate.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o infback.o 

infback.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o inftrees.o

 inftrees.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o inffast.o 

inffast.c

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP   -c -o minigzip.o

 minigzip.c

i686-pc-linux-gnu-ar rc libz.a adler32.o compress.o crc32.o gzio.o uncompr.o def

late.o trees.o zutil.o inflate.o infback.o inftrees.o inffast.o 

i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe -fomit-frame-pointer -DHAS_attri

bute_visibility -fvisibility=hidden -DNO_vsnprintf -DUSE_MMAP -o example example

.o  libz.a

/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/bin/ld:/usr/l

ib/gcc/i686-pc-linux-gnu/4.1.1/../../../libc.so: file format not recognized; tre

ating as linker script

/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/bin/ld:/usr/l

ib/gcc/i686-pc-linux-gnu/4.1.1/../../../libc.so:5: syntax error

collect2: ld returned 1 exit status

make: *** [example] Error 1

make: *** Waiting for unfinished jobs....

!!! ERROR: sys-libs/zlib-1.2.3-r1 failed.

Call stack:

  ebuild.sh, line 1546:   Called dyn_compile

  ebuild.sh, line 937:   Called src_compile

  zlib-1.2.3-r1.ebuild, line 39:   Called die

!!! (no error message)

!!! If you need support, post the topmost build error, and the call stack if rel

evant.

```

Aggiungo che, dando shutdown -h now, ottengo:

```
 /etc/init.d/halt.sh: ebegin: command not found

altri errori di quel tipo su eend, stop_addon, stop_volumes [*]

INIT: no more processes left in this runlevel

```

[*] start_volumes l'ho invece visto all'avvio (ricordo solo questo, ma ce n'erano degli altri)Last edited by Jabber00 on Mon Feb 05, 2007 9:31 pm; edited 1 time in total

----------

## Ic3M4n

un'altra cosa: non credo che utilizzare l'emerge -e world sia la soluzione migliore per il tuo problema per il semplice motivo che non hai un file di world. dovresti far mente locale e cercare di ricordarti quali erano i programmi che avevi installato. altra cosa: dopo il misfatto secondo me ti converrebbe iniziare con il fare un sync. almeno hai la struttura di portage completa.

----------

## Jabber00

 *Ic3M4n wrote:*   

> un'altra cosa: non credo che utilizzare l'emerge -e world sia la soluzione migliore per il tuo problema per il semplice motivo che non hai un file di world. dovresti far mente locale e cercare di ricordarti quali erano i programmi che avevi installato. altra cosa: dopo il misfatto secondo me ti converrebbe iniziare con il fare un sync. almeno hai la struttura di portage completa.

 

Dopo la cancellazione di /var o poco il blackout?

Nel primo caso, avevo fatto il sync: lo rifaccio?

I programmi non dovrebbero essere un problema: la maggior parte erano nel runlevel default, quindi basta guardare gli errori e ripristinarli!

----------

## lucapost

```
lucapost@jarod ~ $ equery b /etc/init.d/halt.sh 

[ Searching for file(s) /etc/init.d/halt.sh in *... ]

sys-apps/baselayout-1.12.9 (/etc/init.d/halt.sh)
```

dopo il sync prova ad emerge baselayout, se va a buon fine molte cose potrebbero mettersi a posto...

----------

## Ic3M4n

dopo la cancellazione della var.

per quanto riguarda l'errore di compilazione hai il file libc.so.5 che ha qualche problema. probabilmente l'hai corrotto con il blackout.

se così fosse la vedo grama. quasi quasi se non vuoi reinstallare si potrebbe tentare con l'estrarre uno stage3 nella / e poi ricompilare il solo necessario.

----------

## Jabber00

 *lucapost wrote:*   

> 
> 
> ```
> lucapost@jarod ~ $ equery b /etc/init.d/halt.sh 
> 
> ...

 

Ehm, emerge sync dice:

```
File "/usr/lib/python2.4/UserDict.py", line 103, in iterkeys

    return self.__iter__()

  File "/usr/lib/portage/pym/cache/mappings.py", line 83, in __iter__

    return iter(self.keys())

  File "/usr/lib/portage/pym/cache/mappings.py", line 87, in keys

    self.d.update(self.pull())

  File "/usr/lib/portage/pym/cache/flat_hash.py", line 29, in callit

    return args[0](*args[1:]+args2)

  File "/usr/lib/portage/pym/cache/flat_hash.py", line 47, in _pull

    raise cache_errors.CacheCorruption(cpv, e)

cache.cache_errors.CacheCorruption: app-accessibility/SphinxTrain-0.9.1-r1 is corrupt: dictionary update sequence element #0 has length 1; 2 is required

```

 :Confused: 

Ed emerge baselayout da lo stesso errore di emerge zlib...   :Crying or Very sad: 

 *Ic3M4n wrote:*   

> dopo la cancellazione della var.
> 
> per quanto riguarda l'errore di compilazione hai il file libc.so.5 che ha qualche problema. probabilmente l'hai corrotto con il blackout.
> 
> se così fosse la vedo grama. quasi quasi se non vuoi reinstallare si potrebbe tentare con l'estrarre uno stage3 nella / e poi ricompilare il solo necessario.

 

In effetti era quello che pensavo: utilizzare stage 3! L'idea di passare altri due giorni a compilare (e' un misero Celero 700) per rimettere in funzione il PC non mi attira molto!   :Confused: 

Estraendo stage 3 in / si sovrascriveranno i file di configurazione che avevo, giusto? Vabbe', potrei recuperarli dall'altro disco (quello almeno dovrebbe mancare solo di /var)!

BTW, il journaling di ext3 non dovrebbe prevenire situazioni del genere (parlo di libc.so.5: dal resto non mi avrebbe salvato neppure il miglor FS dell'universo ^^)?

----------

## Ic3M4n

la differenza non è poi molta tra ributtare su uno stage3 e reinstallare tutto. anzi... se per caso avevi in mente qualche modifica strutturale per assurdo la seconda ipotesi sarebbe anche la migliore. magari conservati come hai detto i file di configurazione.

----------

## lucapost

la vedo dura...

visto il risultato del sync, potresti provare a decomprimerti a mano l'ultimo portage, lo trovi su qualsiasi mirror...

scaricatelo nuovo, almeno sai che i sorgenti non sono corrotti.

----------

## Jabber00

 *Ic3M4n wrote:*   

> la differenza non è poi molta tra ributtare su uno stage3 e reinstallare tutto. anzi... se per caso avevi in mente qualche modifica strutturale per assurdo la seconda ipotesi sarebbe anche la migliore. magari conservati come hai detto i file di configurazione.

 

La differenza finale no, ma di tempo ce n'e' parecchia: l'ultima volta ci ha messo 2 giorni tondi tondi a finire la compilazione base!

Anche se, approfittando della cosa, potrei mettere mano alla configurazione del kernel (quella attuale era stata fatta con genkernel) e, gia' che ci sono, installare una revisione piu' recente (ora c'era la 2005.1, mai aggiornata, se non erro)!

Domani ci sara' da lavorare parecchio!   :Crying or Very sad: 

 *lucapost wrote:*   

> la vedo dura...
> 
> visto il risultato del sync, potresti provare a decomprimerti a mano l'ultimo portage, lo trovi su qualsiasi mirror...
> 
> scaricatelo nuovo, almeno sai che i sorgenti non sono corrotti.

 

Anche cosi', resta il problema della compilazione, che si blocca sempre per lo stesso motivo!

Per escludere che si sia fritto il disco (spero di no, ovviamente, ma mi pare strano che ext3 si perda i file cosi'... o la concomitanza di piu' cose e' stata fatale?), c'e' qualche comando da usare (sperando che funzioni) per testarlo?

----------

## GiRa

Parti da stage3, tando dovresti in ogni caso ricompilare tutto.

----------

## Peach

 *GiRa wrote:*   

> Parti da stage3, tando dovresti in ogni caso ricompilare tutto.

 

quoto.

salva il salvabile e parti  :Smile: 

----------

## bandreabis

 *Peach wrote:*   

>  *GiRa wrote:*   Parti da stage3, tando dovresti in ogni caso ricompilare tutto. 
> 
> quoto.
> 
> salva il salvabile e parti 

 

Credo anch'io sia la cosa migliore, così ho fatto quella volta che mi sono smarrito la /var.   :Sad: 

----------

## Jabber00

I lavori sono iniziati: ora sta estraendo il portage (stage3)! I file di configurazione li ho, come dicevo, sul disco da cui sono partito (il 6.4GB che stavo sostituendo: c'e' tutto tranne /var), quindi li prendero' da li'!

Ma ho una curiosita': dopo il blackout ho riavviato e sono riuscito a compilare glibc senza problemi, poi ho riavviato per vedere se i problemi che erano apparsi dopo lo spegnimento forzato erano scomparsi... da li' non c'e' stato piu' verso di compilare nulla!

Allora, mi chiedevo, il file libc.so.5 quando si e' corrotto? Dopo il blackout non credo (non avrebbe dovuto compilare glic, no?), quindi dopo il riavvio?   :Question: 

----------

## randomaze

 *Jabber00 wrote:*   

> Ma ho una curiosita': dopo il blackout ho riavviato e sono riuscito a compilare glibc senza problemi, poi ho riavviato per vedere se i problemi che erano apparsi dopo lo spegnimento forzato erano scomparsi... da li' non c'e' stato piu' verso di compilare nulla!
> 
> Allora, mi chiedevo, il file libc.so.5 quando si e' corrotto? Dopo il blackout non credo (non avrebbe dovuto compilare glic, no?), quindi dopo il riavvio?  

 

Potrebbe essere che il blackout é avvenuto quando il disco non aveva ancora finito di scrivere i dati bufferizzati (in una parola: sfiga)

----------

## Jabber00

 *randomaze wrote:*   

> 
> 
> Potrebbe essere che il blackout é avvenuto quando il disco non aveva ancora finito di scrivere i dati bufferizzati (in una parola: sfiga)

 

Pero' cosi' e' strana la tempistica: cioe', blackout --> accensione --> compilazione corretta di glibc --> riavvio --> libc.so.5 corrotto!

A questo punto l'alternativa mi pare essere un problema nella compilazione... mi sorge un altro dubbio: possibile che sia dipeso dal fatto che ho cambiato il gcc (dalla 3.x alla 4.x) per compilare le glibc (unico modo per completare con successo la compilazione)?

----------

