Handbook:MIPS/Installation/Stage/it
Scegliere uno stage tarball
On supported architectures, it is recommended for users targeting a desktop (graphical) operating system environment to use a stage file with the term
desktop within the name. These files include packages such as sys-devel/llvm and dev-lang/rust-bin and USE flag tuning which will greatly improve install time.The stage file acts as the seed of a Gentoo install. Stage files are generated with Catalyst by the Release Engineering Team. Stage files are based on specific profiles, and contain an almost-complete system.
When choosing a stage file, it's important to pick one with profile targets corresponding to the desired system type.
While it's possible to make major profile changes after an installation has been established, switching requires substantial effort and consideration, and is outside the scope of this installation manual. Switching init systems is difficult, but switching from
no-multilib to multilib requires extensive Gentoo and low-level toolchain knowledge.La maggior parte degli utenti non dovrebbe usare le opzioni 'avanzate' dei tarball; infatti queste riguardano specifiche configurazioni software o hardware.
OpenRC
OpenRC is a dependency-based init system (responsible for starting up system services once the kernel has booted) that maintains compatibility with the system provided init program, normally located in /sbin/init. It is Gentoo's native and original init system, but is also deployed by a few other Linux distributions and BSD systems.
OpenRC does not function as a replacement for the /sbin/init file by default and is 100% compatible with Gentoo init scripts. This means a solution can be found to run the dozens of daemons in the Gentoo ebuild repository.
systemd
systemd is a modern SysV-style init and rc replacement for Linux systems. It is used as the primary init system by a majority of Linux distributions. systemd is fully supported in Gentoo and works for its intended purpose. If something seems lacking in the Handbook for a systemd install path, review the systemd article before asking for support.
Multilib (32 e 64 bit)
Not every architecture has a multilib option. Many only run with native code. Multilib is most commonly applied to amd64.
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.
Using
multilib targets makes it easier to switch profiles later, compared to no-multilibNon multilib (64 bit puro)
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.
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.
Scaricamento dello stage tarball
Before downloading the stage file, the current directory should be set to the location of the mount used for the install:
root #cd /mnt/gentooImpostare data e ora
Stage archives are generally obtained using HTTPS which requires relatively accurate system time. Clock skew can prevent downloads from working, and can cause unpredictable errors if the system time is adjusted by any considerable amount after installation.
Verificare data e ora eseguendo il comando date:
root #dateLun 3 Ott 13:16:22 CET 2016
Se la data/ora mostrata è sbagliata, correggerla usando uno dei seguenti metodi.
Automatico
Using NTP to correct clock skew is typically easier and more reliable than manually setting the system clock.
chronyd, part of net-misc/chrony can be used to update the system clock to UTC with:
root #ntpd -q -gSystems without a functioning Real-Time Clock (RTC) must sync the system clock at every system start, and on regular intervals thereafter. This is also beneficial for systems with a RTC, as the battery could fail, and clock skew can accumulate.
Standard NTP traffic not authenticated, it is important to verify time data obtained from the network.
Manuale
When NTP access is unavailable, date can be used to manually set the system clock.
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.
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).
Per esempio, per impostare la data sul 3 ottobre, 13:16 nell'anno 2016:
root #date 100313162016Browser 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/mips/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
Most stages are now explicitly suffixed with the init system type (openrc or systemd), although some architectures may still be missing these for now.
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.
root #wget https://distfiles.gentoo.org/releases/- 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-mips-<release>.tar.bz2dgst instructs the openssl command to use the Message Digest sub-command, -r prints the digest output in coreutils format, and -sha512 selects the SHA512 digest.
Per validare con il checksum Whirlpool:
root #openssl dgst -r -whirlpool stage3-mips-<release>.tar.bz2Confrontare 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).
Un altro modo è usare il comando sha512sum:
root #sha512sum stage3-mips-<release>.tar.bz2The --check option instructs sha256sum to read a list of expected files and associated hashes, and then print an associated "OK" for each file that calculates correctly or a "FAILED" for files that do not.
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:
For official Gentoo live images, the sec-keys/openpgp-keys-gentoo-release package provides PGP signing keys for automated releases. The keys must first be imported into the user's session in order to be used for verification:
root #gpg --import /usr/share/openpgp-keys/gentoo-release.ascFor all non-official live images which offer gpg and wget in the live environment, a bundle containing Gentoo keys can be fetched and imported:
root #wget -O - https://qa-reports.gentoo.org/output/service-keys.gpg | gpg --importVerify the signature of the tarball and, optionally, associated checksum files:
root #gpg --verify stage3-mips-<release>.tar.bz2.DIGESTS.ascIf verification succeeds, "Good signature from" will be in the output of the previous command(s).
The fingerprints of the OpenPGP keys used for signing release media can be found on the release media signatures page.
Installare uno stage tarball
Ora scompattare lo stage scaricato nel sistema. Useremo tar per procedere:
root #tar xvjpf stage3-*.tar.bz2 --xattrs --numeric-ownerAssicurarsi 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.
xextract, instructs tar to extract the contents of the archive.ppreserve permissions.vverbose output.ffile, provides tar with the name of the input archive.--xattrs-include='*.*'Preserves extended attributes in all namespaces stored in the archive.--numeric-ownerEnsure that the user and group IDs of files being extracted from the tarball remain the same as Gentoo's release engineering team intended (even if adventurous users are not using official Gentoo live environments for the installation process).
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.
Technically variables can be exported via the shell's profile or rc files, however that is not best practice for basic system administration.
Portage reads in the make.conf file when it runs, which will change runtime behavior depending on the values saved in the file. make.conf can be considered the primary configuration file for Portage, so treat its content carefully.
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.
For a successful Gentoo installation only the variables that are mentioned below need to be set.}}
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.confDal 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:
CFLAGS="-mabi=32 -mips4 -pipe -O2"
# Usare le stesse impostazioni per ambo le variabili
CXXFLAGS="${CFLAGS}"
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.
Further, as of Portage 3.0.53[1], if left undefined, Portage's default behavior is to set the MAKEOPTS load-average value to the same number of threads returned by nproc.
A good choice is the smaller of: the number of threads the CPU has, or the total amount of system RAM divided by 2 GiB.
Using a large number of jobs can significantly impact memory consumption. A good recommendation is to have at least 2 GiB of RAM for every job specified (so, e.g.
-j6 requires at least 12 GiB). To avoid running out of memory, lower the number of jobs to fit the available memory.When using parallel emerges (
--jobs), the effective number of jobs run can grow exponentially (up to make jobs multiplied by emerge jobs). This can be worked around by running a localhost-only distcc configuration that will limit the number of compiler instances per host.MAKEOPTS="-j2"
Search for MAKEOPTS in man 5 make.conf for more details.
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).
References