This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.

Please visit our production wiki at https://wiki.gentoo.org

Installazione dei file di Gentoo

From Gentoo Wiki (test)
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:AMD64/Installation/Stage and the translation is 100% complete.
Manuale AMD64
Installazione
Riguardo l'installazione
Il mezzo d'installazione
Configurare la rete
Preparare i dischi
Installare lo stage3
Installare il sistema base
Configurare il kernel
Configurare il sistema
Strumenti di sistema
Configurare l'avviatore
Ultimare l'installazione
Lavorare con Gentoo
Introduzione a Portage
Opzioni USE
Funzionalità di Portage
Sistema script di init
Variabili d'ambiente
Lavorare con Portage
File e cartelle
Variabili
Mixare i rami del software
Strumenti aggiuntivi
Repositorio pacchetti personalizzato
Funzionalità avanzate
Configurare la rete
Come iniziare
Configurazione avanzata
Networking modulare
Wireless
Aggiungere funzionalità
Gestione dinamica


Installare uno stage tarball

Impostare data e ora

Prima di installare Gentoo, è buona norma assicurarsi che data ed ora siano corretti. Un orologio configurato male può portare a risultati strani: il sistema base dovrebbe essere estratto solo se data ed ora sono esatti. Infatti, dato che molti siti e servizi usano comunicazioni criptate (SSL/TLS), potrebbe essere addirittura impossibile scaricare i file di installazione se l'orologio di sistema è troppo alterato!

Verificare data e ora eseguendo il comando date:

root #date
Lun 3 Ott 13:16:22 CET 2016

Se la data/ora mostrata è sbagliata, correggerla usando uno dei seguenti metodi.

Nota
Le schede madri che non hanno un orologio a tempo reale (Real-Time Clock - RTC) andrebbero configurate per sincronizzare l'orologio di sistema con un time server. Questo vale anche per i sistemi che hanno un RTC ma la cui batteria è scarica.

Automatico

I supporti di installazione ufficiali di Gentoo includono il comando ntpd (grazie al pacchetto net-misc/ntp). I supporti ufficiali includono un file di configurazione che usa i time server di ntp.org. Usare questo metodo richiede una connessione di rete funzionante e potrebbe non essere disponibile per tutte le architetture.

Attenzione
La sincronizzazione automatica dell'ora ha un prezzo da pagare. Rivelerà l'indirizzo IP del sistema e le informazioni di rete correlate al server dell'orario (in questo caso ntp.org). Gli utenti preoccupati per la loro privacy dovrebbero essere consci di questo prima di impostare l'orologio di sistema usando il metodo sottostante.
root #ntpd -q -g

Manuale

Il comando date può essere usato anche per effettuare un'impostazione manuale dell'orologio di sistema. Usare la sintassi MMGGoommAAAA (Mese, Giorno, ora, minuti e anno).

L'orario UTC è raccomandato su tutti i sistemi Linux. Successivamente, durante l'installazione, verrà definito un fuso orario. Ciò modificherà il modo in cui viene mostrata l'ora in base all'ora locale.

Per esempio, per impostare la data sul 3 ottobre, 13:16 nell'anno 2016:

root #date 100313162016

Scegliere uno stage tarball

Multilib (32 e 64 bit)

Scegliere un tarball base per il sistema fa risparmiare una quantità considerevole di tempo lungo il processo di installazione, in particolare quando si dovrà scegliere un profilo corretto. La selezione di uno stage tarball avrà implicazioni dirette sulla configurazione del futuro sistema e può anche prevenire possibili problemi futuri. Il tarball multilib usa librerie a 64 bit ogni volta che è possibile, mentre solo per ragioni di compatibilità passa ai 32 bit. Questa è un'eccellente scelta per la maggior parte delle installazioni, dato che offre grande flessibilità per una personalizzazione futura. Per coloro che desiderano che il loro sistema sia in grado di passare facilmente da un profilo all'altro dovrebbero scegliere un tarbal multilib in relazione all'architettura del loro processore.

La maggior parte degli utenti non dovrebbe usare le opzioni 'avanzate' dei tarball; infatti queste riguardano specifiche configurazioni software o hardware.

Non multilib (64 bit puro)

Scegliere un tarball non multilib come base per il sistema offre un ambiente completamente a 64 bit. Ciò rende improbabile il passaggio ad un profilo multilib, seppur possibile. Coloro che cominciano ad usare Gentoo non dovrebbero scegliere un tarball no-multilib a meno che non sia assolutamente necessario.

Attenzione
Siate consapevoli che migrare da un sistema no-multilib ad uno multilib richiede una conoscenza di Gentoo molto collaudata, oltre ad una serie di strumenti di basso livello (ciò potrebbe far preoccupare persino i nostri sviluppatori di strumenti (toolchain)). Non è per i deboli di cuore e va oltre lo scopo di questa guida.

Scaricamento dello stage tarball

Spostarsi sulla cartella dove è stato montato il filesystem radice di Gentoo (molto probabilmente /mnt/gentoo):

root #cd /mnt/gentoo

A seconda del mezzo di installazione scelto, il solo strumento necessario per scaricare uno stage tarball è un browser Web.

Browser grafici

Coloro che usano ambienti con browser di rete completamente grafici non avranno problemi a copiare l'URL del file stage dalla sezione di download del sito principale. Semplicemente selezionare la scheda appropriata, cliccare con il tasto destro del mouse sul collegamento al file stage, poi Copiare l'indirizzo (su Firefox) o Copiare la posizione (su Chromium) per copiare l'indirizzo negli appunti, incollare poi il collegamento all'utilità wget da linea di comando così da scaricare lo stage tarball:

root #wget <URL_STAGE_INCOLLATO>

Browser a linea di comando

I lettori più tradizionali o gli utenti Gentoo di 'vecchia data', lavorando esclusivamente da linea di comando, potrebbero preferire l'uso di links, un browser senza grafica e basato sui menu. Per scaricare uno stage, navigare fino alla lista di distributori (mirror) di Gentoo come di seguito:

root #links https://www.gentoo.org/downloads/mirrors/

Per usare un proxy HTTP con links, passare l'URL con l'opzione -http-proxy:

root #links -http-proxy proxy.server.com:8080 https://www.gentoo.org/downloads/mirrors/

Oltre a links esiste anche il browser lynx. Come links, si tratta di un browser privo di grafica ma non basato sui menu.

root #lynx https://www.gentoo.org/downloads/mirrors/

Se è necessario definire un proxy, esportare le variabili http_proxy e/o ftp_proxy:

root #export http_proxy="http://proxy.server.com:port"
root #export ftp_proxy="http://proxy.server.com:port"

Nella lista dei distributori (mirror), selezionarne uno vicino. Solitamente vanno bene i mirror HTTP, ma sono disponibili anche altri protocolli. Spostarsi nella cartella releases/amd64/autobuilds/. Qui sono elencati tutti i file stage disponibili (potrebbero essere posti in sottocartelle nominate con il nome delle singole sotto architetture). Selezionarne uno e premere d per scaricarlo.

Appena lo scaricamento del file stage è completato, è possibile verificare l'integrità e validare i contenuti dello stage tarball. Coloro che lo desiderano dovrebbero leggere la successiva sezione.

Coloro che non sono interessati alla verifica e alla validazione del file stage possono chiudere il browser a linea di comando premendo q e possono proseguire alla sezione di estrazione dello stage tarball.

Verifica e validazione

Note
Some tarballs are being delivered via xz compression. When downloading a tarball ending in .tar.xz, be sure to adjust the tarball filename from .tar.bz2 in the following commands.

Come con i CD di installazione minimali, anche ora sono disponibili file aggiuntivi per verificare e validare il file stage. Sebbene questi passi possano essere saltati, questi file sono forniti per gli utenti che tengono alla legittimità dei file da essi scaricati.

  • Un file .CONTENTS che contiene un elenco di tutti i file all'interno del tarball stage.
  • Un file .DIGESTS che contiene i checksum (somme di controllo) del file stage, in base a diversi algoritmi.
  • Un file .DIGESTS.asc che, come il file .DIGESTS, contiene i checksum del file stage secondo diversi algoritmi, ma è anche firmato crittograficamente per assicurarsi che sia fornito dal progetto Gentoo.

Usare openssl e confrontare il suo risultato con le somme di controllo fornite dal file .DIGESTS o .DIGESTS.asc.

Per esempio, per validare con il checksum SHA512:

root #openssl dgst -r -sha512 stage3-amd64-<release>.tar.bz2

Un altro modo è usare il comando sha512sum:

root #sha512sum stage3-amd64-<release>.tar.bz2

Per validare con il checksum Whirlpool:

root #openssl dgst -r -whirlpool stage3-amd64-<release>.tar.bz2

Confrontare il risultato di questi comandi con il valore registrato nei file .DIGESTS(.asc). I valori devono corrispondere, altrimenti il file scaricato potrebbe essere corrotto (oppure è corrotto il file digests).

Così come per il file ISO, è possibile verificare anche la firma crittografica del file .DIGESTS.asc usando gpg per essere sicuri che le somme di controllo non siano state manomesse:

root #gpg --verify stage3-amd64-<release>.tar.bz2.DIGESTS.asc

Estrazione dello stage tarball

Ora scompattare lo stage scaricato nel sistema. Useremo tar per procedere:

root #tar xvjpf stage3-*.tar.bz2 --xattrs --numeric-owner

Assicurarsi di usare le stesse opzioni (xvjpf e --xattrs). La x sta per Estrai, la v sta per Verboso per vedere cosa succede durante il processo di estrazione (opzionale), la j sta per Decomprimi con bzip2, la p sta per Preserva i permessi e la f indica che si vuole estrarre un File, l'input non è standard. --xattrs serve per includere gli attributi estesi memorizzati nell'archivio. Infine, --numeric-owner viene usato per assicurarsi che gli ID di utenti e gruppi dei file estratti dal tarball rimangano uguali a quelli pensati dalla squadra ingegneristica dei rilasci di Gentoo, anche per gli utenti avventurosi che non stanno usando mezzi di installazione ufficiali di Gentoo.

Una volta che il file stage è stato installato, si continui con la Configurazione delle opzioni di compilazione.

Configurazione delle opzioni di compilazione

Introduzione

Per ottimizzare Gentoo, è possibile impostare un paio di variabili che influenzeranno il comportamento di Portage, il gestore di pacchetti di Gentoo ufficialmente supportato. Tutte quelle variabili possono essere impostate come variabili d'ambiente (usando export) però l'effetto non sarà permanente. Per conservare le impostazioni, Portage legge nel file /etc/portage/make.conf, un file di configurazione di Portage.

Nota
Si può trovare un elenco commentato di tutte le variabili possibili nel file /mnt/gentoo/usr/share/portage/config/make.conf.example. Per completare un'installazione, è necessario impostare solo le variabili menzionate di seguito.

Si apra un editor (in questa guida useremo nano) per modificare le variabili di ottimizzazione che discuteremo in seguito.

root #nano -w /mnt/gentoo/etc/portage/make.conf

Dal file make.conf.example si comprende come questo debba essere strutturato: le linee commentate iniziano con "#", le altre linee definiscono le variabili usando la sintassi VARIABILE="contenuto". Molte di queste variabili sono discusse in seguito.

CFLAGS e CXXFLAGS

Le variabili CFLAGS e CXXFLAGS definiscono rispettivamente le opzioni di ottimizzazioni per i compilatori GCC C e C++. Benché siano definite in maniera generale qui, per ottenere le migliori prestazioni si dovrebbero ottimizzare quelle opzioni separatamente per ogni programma. Dato che ciascun programma è diverso. Tuttavia, ciò non è gestibile, per cui si utilizza la definizione di queste variabili (flag) nel file make.conf.

Nel file make.conf si dovrebbero definire le opzioni di ottimizzazione che renderanno il sistema indicativamente più performante possibile. Non si usino impostazioni sperimentali in questa variabile; troppe ottimizzazioni possono addirittura peggiorare il comportamento dei programmi (blocchi, o anche peggio, malfunzionamenti).

Non spiegheremo tutte le opzioni di ottimizzazione possibili. Per comprenderle tutte, si legga il Manuale GNU Online o la pagina di informazioni di gcc (info gcc - funziona solo su sistemi Linux in esecuzione). Il file make.conf.example stesso contiene tantissimi esempi ed informazioni; non si dimentichi di leggerlo.

Una prima impostazione è l'opzione -march= o -mtune=, che specifica il nome dell'architettura di destinazione. Nel file make.conf.example sono descritte le possibili opzioni (attraverso commenti). Un valore comunemente usato è native che indica al compilatore di usare come architettura di destinazione quella del sistema in uso (quella su cui gli utenti stanno installando Gentoo).

Un'altra opzione è -O (O maiuscola, non zero), che specifica la classe di ottimizzazione di gcc. Possibili classi sono s (per ottimizzare le dimensioni), 0 (zero - per non ottimizzare affatto), 1, 2 o persino 3 per ottimizzare la velocità (ogni classe ha le stesse opzioni della precedente, più alcune aggiuntive). -O2 è l'opzione predefinita raccomandata. È noto che -O3 causa problemi se usata per l'intero sistema, quindi raccomandiamo di attenersi a -O2.

Un'altra opzione di ottimizzazione popolare è -pipe (usa le pipe - passaggio dati - invece di file temporanei per la comunicazione durante i vari passi della compilazione). Non ha alcun impatto sul codice generato, ma usa più memoria. Su sistemi con poca memoria, gcc potrebbe essere interrotto. In tal caso, non si usi questa opzione.

Usare -fomit-frame-pointer (che non conserva il frame pointer nel registro per le funzioni che non se ne servono) potrebbe avere serie ripercussioni sul debug delle applicazioni.

Quando vengono definite le variabili CFLAGS e CXXFLAGS, si combinino le varie opzioni di ottimizzazione in un'unica stringa. I valori predefiniti contenuti nell'archivio stage3 scompattato dovrebbero essere abbastanza buoni. Quello di seguito è solo un esempio:

CODE Esempi delle variabili CFLAGS e CXXFLAGS
CFLAGS="-march=native -O2 -pipe"
# Usare le stesse impostazioni per ambo le variabili
CXXFLAGS="${CFLAGS}"
Tip
Benché l'articolo relativo all'ottimizzazione GCC abbia più informazioni su come le varie opzioni di compilazione possano influenzare un sistema, l'articolo CFLAGS sicure dovrebbe essere un posto più pratico per i principianti per iniziare ad ottimizzare i loro sistemi.

MAKEOPTS

La variabile MAKEOPTS definisce quante compilazioni parallele dovrebbero avvenire quando si installa un pacchetto. Una buona scelta è il numero di CPU (o core di CPU) nel sistema più uno, ma questa linea guida non è sempre perfetta.

CODE Esempio di dichiarazione di MAKEOPTS nel file make.conf
MAKEOPTS="-j2"

Pronti, attenti, via!

Aggiornare il file /mnt/gentoo/etc/portage/make.conf in base alle preferenze personali e salvarlo (gli utenti di nano devono usare Ctrl+X).

Continuare poi con l'Installazione del sistema base.