# Sistema "rotto" dopo aggiornamento a glibc 2.6.1?

## SteelRage

Salve a tutti.

Scusate il post decisamente "niubbo-style", ma stavolta non so nemmeno io troppo bene che pesci pigliare.

Uso un sistema ~x86 e già da un po' di tempo avevo notato la possibilità di aggiornare glibc alla versione 2.6.1.

Dopo circa una settimana ho deciso di fare il gran passo:

- Aggiornamento di glibc alla versione 2.6.1

- Aggiornamento di gcc all'ultima versione ~x86 (scusate se non riesco ad essere preciso, ma non ho gentoo sotto mano), seguito ovviamente da gcc-config

- fix_libtool files [vecchia_versione_di_gcc]

- revdep-rebuild (che non ha ricompilato niente)

- emerge -e system

- etc-update

- Ricompilazione del kernel (stesse opzioni di quello precedente, che funzionava), preceduta da un bel make clean

[già che c'ero: siccome non mi funzionava bootsplash e stavo ricompilando il kernel, ho cambiato l'opzione da passare tramite lilo al kernel da "video=vesafb-tng:1280x1024-32@80" a "video=vesafb:1280x1024-32@80", come da guida su gentoo-wiki]

Morale della favola? All'avvio mi trovo un bel 

```
OK... booting the kernel...
```

 E basta  :Sad: 

Piantone generale.

Ora, le mie domande sono le seguenti:

1) Ho sbagliato qualcosa nella procedura di upgrade?

2) Come faccio a leggere un qualunque tipo di log che mi mostri dov'è l'errore?

3) (Per te, caro lettore a cui piacciono gli enigmi e che vuoi darmi una zampa  :Very Happy:  ) Di che informazioni sul mio sistema avete bisogno per capire dove sta l'inghippo?

Mesi e mesi fa avevo utilizzato prelink... Può essere in qualche modo correlato?

----------

## randomaze

 *SteelRage wrote:*   

> 2) Come faccio a leggere un qualunque tipo di log che mi mostri dov'è l'errore?

 

In quel momento mi sa che non ci sono log o altro... il kernel non parte quindi non può scrivere.

Due possibilità che mi vengono in mente:

Potrebbe darsi che nonostante il "make clean" é rimasto dello sporco nelle dir di compilazione del kernel.

Potrebbe essere che comunque la linea per il vesafb-tng fa a cazzotti con il tuo hardware (quindi prova a rimettere quella di prima)

----------

## djinnZ

make clean si limita a cancellare gli oggetti finali non quelli intermedi quindi un bel make mrproper, soprattutto quando cambi compilatore glibc e simili è necessario per star tranquilli.

Un comportamento del genere in genere capita quando disabiliti il framebuffer o non viene compilato per qualche errore. Se hai usato genkernel dai uno sguado a /var/log/genkernel.log per vedere se è riportato qualche errore di compilazione, nel caso prova a ricompilare il kernel senza -Os.

Prelink non dovrebbe dare problemi ma nel dubbio avendo cambiato gcc e glibc ricompilerei anche binutils e libtool

hai per caso abilitato qualche driver video builtin?

----------

## SteelRage

Grazie ragazzi per i suggerimenti   :Very Happy: 

Dunque, di seguito un elenco di quanto fatto finora [nota: dopo ogni passo ho riavviato il PC per fare una prova]

- Modifica di /etc/lilo.conf ripristinando vesafb-tng, seguita da /sbin/lilo ----> Niente da fare

- Ricompilazione del kernel, preceduta da make mrproper ---->Niente da fare

- Ricompilazione di libtool e binutils ----> Niente da fare

Per le modifiche sono entrato nel sistema da liveCD, tramite chroot (quindi, visto che non ho avuto strani messaggi d'errore, posso dire con certezza si tratti a questo punto di un problema legato al kernel?)

@djinnZ: Nessun driver video builtin. Ho solo rimosso il driver radeon dai device relativi al framebuffer, visto che tanto usavo vesa-tng. Non uso genkernel, ma il metodo "tradizionale", che non mi ha dato alcun errore di compilazione

----------

## cloc3

 *SteelRage wrote:*   

> posso dire con certezza si tratti a questo punto di un problema legato al kernel?
> 
> 

 

il kernel del cd funziona. usa quello e vedi.

----------

## Apetrini

Secondo me il problema sta in lilo, ossia ti sei dimenticato di lanciare lilo(e di controllare che esegua senza errori) la prima volta e quando sei entrato facendo il chroot ti sei dimenticato "qualcosa" . Sei sicuro che dentro chroot lilo abbia eseguito senza problemi... ti ricordo che devi montare /dev e (mi sa) anche /proc

Secondo me controlla lilo....

----------

## SteelRage

 *Apetrini wrote:*   

> Secondo me il problema sta in lilo, ossia ti sei dimenticato di lanciare lilo(e di controllare che esegua senza errori) la prima volta e quando sei entrato facendo il chroot ti sei dimenticato "qualcosa" . Sei sicuro che dentro chroot lilo abbia eseguito senza problemi... ti ricordo che devi montare /dev e (mi sa) anche /proc
> 
> Secondo me controlla lilo....

 

No, no, lilo è stato lanciato dopo ogni modifica in maniera più che sovrabbondante  :Wink:  Anche dentro chroot non dà warning o messaggi d'errore.

(Comuqnue, prima di ogni chroot, monto sempre con l'opzione "-o bind" sia /dev, sia /proc.)

In caso, domani proverò a rimuovere l'opzione realtiva al framebuffer; vediamo se così per caso funziona (ho veramente il dubbio che ci sia un problema con il framebuffer, visto che si pianta subito dopo lo switching. Poi vi saprò dire.

@cloc3: dopo aver provato ciò di cui sopra, farò una prova anche con il kernel del liveCD. Non so quanto possa aiutare però, in quanto anche una vecchia versione di kernel che solitamente utilizzavo come backup ora dà lo stesso problema.

@djinnz: dici che veramente l'opzione -oS possa creare problemi del genere? Lo tengo come ultima chance (anche qui, curiosità: devo dare un make mrproper prima?)

----------

## djinnZ

a me li ha creati (ma sono su hardened ed uso delle cflag/ldflag che sarebbero altamente sconsigliate anche su gentoo "normale") soprattutto se non hai ripulito tutti i binari creati dal compilatore. Tralasciando i vecchi flame contro compat vdso etc.

Si se vuoi passare da -Os a senza devi dare il make mrproper.

Mi sa che in realtà non usavi vesa ma il driver nativo radeon invece...

Non è che ti sei scordato di abilitare il supporto alla console virtuale piuttosto?

----------

## cloc3

 *SteelRage wrote:*   

> 
> 
> @cloc3: ... Non so quanto possa aiutare però ...

 

aiuta. perché devi escludere una causa alla volta.

l'altro giorno ho compilato le binutils in un modo balordo che metà basta.

per riprendere il sistema ho installato una versione delle binutils presa dal primo stage di un mirror di passaggio e ho ritrovato il controllo.

devi cercare di capire esattamente dove accade il guasto.

se non trovi modi più veloci, una possibilità è generare una initrd, eseguire un sh piuttosto che il tradizionale linuxrc e testare i singoli passaggi del boot in linea di comando.

 *SteelRage wrote:*   

> 
> 
> - fix_libtool files [vecchia_versione_di_gcc]
> 
> 

 

quale era la vecchia versione?

----------

