Forum

Riprendo dal precedente thread [Guida] Installiamo Gentoo: Parte 1 alla fine della quale avevamo editato fstab, dato un nome al nostro PC e rimandato un po' di operazioni previste dal manuale che non ci occorrono ora, perchè stiamo operando via chroot da un'altra installazione.

La rete è OK? Si? Allora è giunto il momento della fatidica...


Per prima cosa, ci serve un logger di sistema. Abbiamo diverse alternative tra cui scegliere. Come l'ho capita io, syslog-ng è, al momento, il più evoluto, perciò la mia scelta è syslog-ng.
Per installare il logger di sistema scelto, si deve emergerlo e aggiungerlo al runlevel di default con rc-update. Poi il manuale suggerisce di emergere anche un demone cron. Scegliamo vixie-cron. Per poter indicizzare i file del sistema, in modo da poterli localizzare rapidamente usando locate, ci occorre anche mlocate.
Per la rete installiamo dhcpcd e ppp Tutti questi comandi li possiamo anche sintetizzare così: Io ho provato e non ha funzionato. Poi, provando i comandi singolarmente, ho scoperto che le difficoltà le dava solo l'emersione di ppp. Quindi, omettendo ppp, la sintesi quì sopra avrebbe funzionato.
Il tempo occorso al PC per scaricare ed installare syslog-ng vixie-cron mlocate dhcpcd è stato complessivamente di circa 5 minuti. Il tentativo di emergere ppp mi ha dato l'output seguente. Cogliamo l'occasione per leggerlo insieme e vedere come rimediare all'intoppo. Le righe che incominciano con le parentesi quadre con dentro scritto [ebuild N] descrivono i singoli pacchetti di cui abbiamo richiesto l'emersione con il comando emerge ppp.
Sono 14 pacchetti, per un totale di 94MB.
Ma... Ecco che ci viene indicato un problema di dipendenze circolari tra 4 di questi pacchetti: Significa che il primo dipende dal secondo che dipende dal terzo che dipende dal quarto che dipende... Indovinate da chi? Dal primo.
Dopo viene descritto qualche altro problema, o possibile problema che non mi è chiaro, ma che riguarda due pacchetti di librerie: glib e libxml2.
Infine, viene dato il suggerimento di ricorrere a package.mask come possibile soluzione.
Ho fatto qualche prova con package.mask, ma non le riporto perchè non sono servite a niente.
Ho emerso individualmente e con successo glib e poi libxml2. Considerata la pausa di 6 mesi, possono esserci aggiornamenti importanti di pacchetti già installati. Proviamo ad eseguire un aggiornamento completo del sistema. Prima di eseguirlo, aggiorniamo il solo portage e poi emergiamo Gentoolkit, il quale va emerso prima di un aggiornamento completo del sistema perchè, dopo questo, è bene fare una pulizia che richiede appunto di avere già installato gentoolkit.
Non riporto i tempi di aggiornamento. Gentoolkit mi ha richiesto solo un minuto e mezzo. Proviamo un aggiornamento completo del sistema. L'output segnala che il nostro profilo è vecchio e deprecato (che schifooo!!! ) e suggerisce di cambiarlo: eseguito il suggerimento, riproviamo. Ancora problemi di dipendenze circolari. Visto così, rimandiamo l'aggiornamento completo e riproviamo ad emergere ppp. Il problema delle dipendenze circolari è sempre lo stesso. Proviamo ad inserire in make.conf tutte le USE riportate nelle righe dei pacchetti che iniziano con [ebuild N ] e riproviamo. Nessun progresso.
Allora proviamo ad emergere i pacchetti in dipendenza circolare uno per volta. scopriamo che questo pacchetto è mascherato perchè per AMD è disponibile solo in versione testing. Per abilitare portage ad impiegare questo pacchetto anche se in versione testing, aggiungiamo la categoria ed il nome del pacchetto: nel file /etc/portage/package.accept_keywords.
Anche così ci sono problemi. Proviamo con un altro pacchetto. Perchè non proprio il primo "virtual/jpeg-0"? Questo viene emerso in 1 minuto. Riproviamo ad emergere ppp e parte l'emersione di ben 72 pacchetti. Ora riproviamo con l'aggiornamento completo. Questa volta è partito e, con la pausa di 6 mesi fatta, ha trovato parecchio da aggiornare, 201 pacchetti. Il tempo di questa operazione non lo includo, perchè è stata resa necessaria dalla lunga interruzione. Diversamente, l'avremmo fatta comunque, però alla fine e trovando molto meno da aggiornare. Perciò questa situazione falserà comunque il calcolo del tempo macchina per l'installazione di Gentoo. Mi spiace.

L'aggiornamento non è riuscito fino in fondo. Si è interrotto al pacchetto 154: Inoltre, ci suggerisce ed eseguiamo: Dall'output traiamo il suggerimento di ridare revdep-rebuild per sicurezza.
Eseguiamo. Tutto a posto.
Proviamo a ripetere l'aggiornamento completo.
Questa volta compare subito e solo il problema con openldap.
Siccome prima ha prodotto anche l'indicazione: Diamo il comando (alla richiesta di selezione: -5)
così aggiorna: Ora vediamo come sbloccare il problema con Openldap.
Proviamo a dare il comando: Emerge 2 pacchetti in 8m Riprovando l'aggiornamento completo, nonostante openldap sia stato già emerso, tenta nuovamente di emergerlo per aggiornarlo alla stessa versione. Questo è certamente un bug.
Non ci resta che aggirare il problema mascherando openldap. Apriamo: ed inseriamo: Riproviamo l'aggiornamento. Questa volta lo completa. Quindi ridiamo: (alla richiesta di selezione: -5)
Dopo questa mole notevole di aggiornamento, è meglio ripulire il sistema di eventuali dipendenze orfane e verificare che sia tutto a posto.
Quindi diamo: Sembra che sia andato tutto bene. Ora possiamo riprendere il percorso principale da dove eravamo arrivati, prima di questo aggiornamento generale. Avevamo installato ppp, come suggerito al punto 9.f.6.2 del manuale.
Ci serve un bootloader. Per la piattaforma AMD64, Gentoo Linux fornisce GRUB e LILO.
A questo punto, nelle mie prove è sorto un problema: Non sono riuscito ad emergere nè Grub, nè lilo.
La causa sembra essere che il profilo attivo del compilatore gcc è invalido.
Quindi, ho indagato su come si fa per rimediare. Sembra facile. Basta chiedere al sistema: Per avere la lista dei profili disponibili. La risposta è stata: Quello elencato, dovrebbe essere l'unica alternativa a quello attualmente attivo, che è invalido.
Per cambiarlo diamo: Oppure, diamo : Il risultato dovrebbe essere lo stesso.
Poi diamo: per renderlo attivo già nella shell che stiamo usando.
Torniamo alla questione del bootloader. Avendo già Lilo in Salix, scegliamo di usarlo anche per Gentoo. In fondo agli output espressi dal nostro terminale, dovremmo aver già notato più volte che ci sono delle notizie in attesa di essere lette. Facciamo una pausa per vedere queste notizie. Quelle più vecchie del 2012 non dovrebbero riguardarci.
Poi veniamo invitati a compiere una migrazione: Ci sono varie altre news, ma non mi sembra che suggeriscano qualcosa di rilevante per questa installazione.


Work in progres:
Osservazioni, suggerimenti, critiche, per migliorare questa piccola guida e renderla meglio utilizzabile sono molto graditi.

sta venendo un bel lavoro, bravo!
Continua a postare il tempo di compilazione...
(usa "qlop", trovi in fondo a questa pagina un po' di info: http://www.gentoo.org/doc/it/portage-utils.xml )

ma qlop -c mi dà il tempo di compilazione del singolo pacchetto o di tutto quello che sto emergendo nella sessione corrente di emersione?
E come faccio ad utilizzarlo durante l'emersione?
L'esempio di stima preventiva che fa quella pagina, dà una risposta "for 4 merge".
E' il tempo impiegato per 4 emersioni? O dice che è una stima fatta come media di 4 emersioni?
Anche così, mi sembra strano. 4 emersioni si possono fare con una marea di macchine diverse, da saette superpompate a catorci d'anteguerra. Ci vorrebbe piuttosto una indicazione del tipo di hardware impiegato come elemento di paragone.

Non so come calcoli la stima, ma penso faccio stima del tuo hardware.
Quindi per sapere quanto tempo impiega un pacchetto:
qlop -tH _nomepacchetto_

qlop -c
ti fa vedere, sostanzialmente, da quanto tempo sta emergendo ciò che sta "attualmente" emergendo...

qlop -l
ti fa vedere la lista dei pacchetti emersi!

E non c'è un comando per vedere il tempo della sessione di emersione comprensiva di tutti i pacchetti emersi in una sessione di emersione?

Comunque, qlop -c come glielo dò se sto emergendo?
Suppongo vada integrato nel comando di emersione, ma come?

qlop -c lo da in un altro terminale...

prova a vedere:
man qlop
info qlop
magari trovi info per plottare info su sessioni intere... ma non credo!

Info qlop produce una montagna di linee di testo, ma non mi sembra che indichi le opzioni disponibili.

pensavo ci fosse il man di qlop.

vabbè vai con:
info qlop| less

conoscenza ha scritto:vabbè vai con:
info qlop| less

Mi risponde:

conoscenza ha scritto:... per sapere quanto tempo impiega un pacchetto:
qlop -tH _nomepacchetto_

Non mi funziona. Cioè, non mi ha dato nessun output. Mi ha solo restituito la linea di comando.
E se non posso restare davanti al PC a vedere quanto ci mette ad emergere, come faccio?
Al ritorno trovo che ha finito, ma come faccio a sapere a che ora ha finito?