Manual:Partes/Instalação/Stage
Escolhendo um arquivo tar de stage
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.
É possível trocar uma instalação do Gentoo em execução usando OpenRC para systemd e voltar. Porém, isso requer um certo esforço e isso está fora do escopo desse manual. Dependendo do que você quer na sua instalação, por favor tenha certeza de que você escolheu o stage tarball correto.
A maioria dos usuários não deve usar as opções de arquivos tar 'advanced'; elas são específicas para alguma configuração de software ou hardware.
OpenRC
OpenRC é um sistema de inicialização baseado em dependências (responsável por iniciar o sistema uma vez que o kernel foi inicializado) que mantém compatibilidade com o programa init providenciado pelo sistema, normalmente encontrado em /sbin/init. É o sistema de inicialização nativo e original do Gentoo, mas também já foi implementado por algumas distribuições Linux e sistemas BSD.
OpenRC não tem a função de substituir o arquivo /sbin/init por padrão e é 100% compatível com os scripts de init do Gentoo. Isso significa uma solução que pode ser encontrada para rodar as dezenas de daemons do repositório de ebuilds do Gentoo
systemd
systemd é um substituto moderno para os init estilo SysV e dos rc para sistemas Linux. Por enquanto é usado na maioria das distribuições Linux. Systemd é suportado no Gentoo e funciona perfeitamente; é amplamente configurável. Infelizmente, grande parte das seções correspondentes do manual de instalação ainda precisam ser escritas ou estão em andamento.
Multilib (32 e 64 bits)
Not every architecture has a multilib option. Many only run with native code. Multilib is most commonly applied to amd64.
Escolher um arquivo tar base para o sistema pode economizar uma considerável quantidade de tempo mais tarde no processo de instalação, especificamente quando for o momento de escolher o perfil do sistema. A seleção de um arquivo tar de stage irá impactar a futura configuração do sistema e pode evitar uma dor de cabeça ou duas mais tarde. O arquivo tar multilib usa bibliotecas de 64 bits quando possível e apenas as versões de 32 bits quando necessário para compatibilidade. Essa é uma excelente opção para a maioria das instalações pois provê grande flexibilidade para personalizações no futuro. Quem desejar que seu sistema seja capaz de trocar facilmente de perfil deve baixar o arquivo tar multilib para sua respectiva arquitetura de processador.
Using
multilib targets makes it easier to switch profiles later, compared to no-multilibNo-multilib (64 bits puro)
Tome cuidado, migrar de um sistema não-multilib (no-multilib) para um multilib requer um excelente conhecimento do Gentoo e de suas ferramentas de baixo nível (isso pode fazer até nossos Desenvolvedores de ferramentas estremecerem um pouco). Não é uma tarefa para cardíacos e está além do escopo deste manual.
Selecionar um arquivo tar no-multilib como base do sistema provê um completo ambiente de sistema operacional de 64 bits. Isso torna efetivamente a habilidade de se trocar para perfis multilib improvável, mas possível. Aqueles que estão iniciando com o Gentoo não devem escolher um arquivo tar no-multilib a menos que seja absolutamente necessário.
Baixando o arquivo tar do stage
Before downloading the stage file, the current directory should be set to the location of the mount used for the install:
root #cd /mnt/gentooAjustando a data e a hora
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.
Verifique a data e a hora atual executando o seguinte comando date:
root #dateMon Oct 3 13:16:22 PDT 2016
Se a data/hora mostrada estiver errada, atualize-a usando um dos métodos abaixo.
Automático
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.
Manual
When NTP access is unavailable, date can be used to manually set the system clock.
Hora UTC é recomendada para todos os sistemas Linux. Mais tarde durante a instalação um fuso horário irá ser definido. Isto irá modificar a exibição do relógio para o horário local.
O comando date pode fazer também uma configuração manual do relógio do sistema. Use a sintaxe MMDDhhmmYYYY (Mês, Dia, hora, minuteo e Ano).
Por exemplo, para ajustar a data para 3 de outubro de 2016, 13:16:
root #date 100313162016Usuários usando ambientes com navegadores web gráficos não terão problema em copiar a URL do arquivo de stage da seção de download do site web principal. Apenas selecione a aba apropriada, clique com o botão da direita no link do arquivo de stage e então Copie o link para copiar o link para a área de transferência, então cole o link para a o utilitário de linha de comando wget para baixar o arquivo tar de stage:
root #wget <PASTED_STAGE_URL>Usuários mais tradicionais ou 'das antigas', trabalhando exclusivamente com a linha de comando podem preferir o links, um navegador não gráfico baseado em menus. Para baixar o arquivo de stage, navegue até a lista de espelhos do Gentoo como abaixo:
root #links https://www.gentoo.org/downloads/mirrors/Para usar um proxy HTTP com o links, passe a URL com a opção -http-proxy:
root #links -http-proxy servidor.proxy.com:8080 https://www.gentoo.org/download/mirrors/Próximo ao links há também o navegador lynx. Assim como o links ele é um navegador não gráfico mas não baseado em menus.
root #lynx https://www.gentoo.org/downloads/mirrors/Se for necessário definir um proxy, exporte as variáveis http_proxy e/ou ftp_proxy:
root #export http_proxy{{=}}"http://servidor.proxy.com:porta"
root #export ftp_proxy="http://servidor.proxy.com:porta"Na lista de espelhos, selecione um espelho próximo. Normalmente os espelhos HTTP são suficientes, mas outros protocolos estão também disponíveis. Mova para o diretório releases/amd64/autobuilds/. Lá todos os arquivos de stage são mostrados (eles podem estar localizados dentro de subdiretórios nomeados segundo as sub-arquiteturas individuais). Selecione um e pressione d para baixar.
Depois que o download do arquivo de stage completar, é possível verificar a integridade e validar o conteúdo do arquivo tar de stage. Aqueles interessados em fazê-lo devem proceder à próxima seção.
Aqueles não interessados em verificar e validar o arquivo de stage podem fechar o navegador de linha de comando pressionando q e podem avançar diretamente para a seção Descompactando o arquivo tar de stage.
Verificando e validando
Most stages are now explicitly suffixed with the init system type (openrc or systemd), although some architectures may still be missing these for now.
Assim como nos CDs mínimos de instalação, estão disponíveis arquivos adicionais para verificar e validar o arquivo de stage. Apesar desses passos poderem ser pulados, esses arquivos são providos para os usuários que se preocupam com a legitimidade dos arquivos baixados.
root #wget https://distfiles.gentoo.org/releases/- Um arquivo .CONTENTS que contém a lista de todos os arquivos contidos no arquivo tar do stage.
- Um arquivo .DIGESTS que contém as somas de checagem do arquivo de stage em diferentes algoritmos.
- Um arquivo .DIGESTS.asc que, como o arquivo .DIGESTS, contém somas de checagem do arquivo de stage em diferentes algoritmos, mas também assinadas criptograficamente para validar que é provido pelo Projeto Gentoo.
Use o comando openssl e compare a saída com as somas de checagem providas pelos arquivos .DIGESTS ou .DIGESTS.asc.
Por exemplo, para validar a soma de checagem SHA512:
root #openssl dgst -r -sha512 stage3-amd64-<release>.tar.?(bz2|xz)dgst 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.
Para validar a soma de checagem Whirlpool:
root #openssl dgst -r -whirlpool stage3-amd64-<release>.tar.?(bz2|xz)Compare a saída desses comandos com o valor registrado nos arquivos .DIGESTS(.asc). Os valores devem bater, senão o arquivo baixado pode estar corrompido (ou o arquivo .DIGESTS está).
Outra forma é usar o comando sha512sum:
root #sha512sum stage3-amd64-<release>.tar.?(bz2|xz)The --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.
Assim como com o arquivo ISO, é possível também verificar a assinatura criptográfica do arquivo .DIGESTS.asc usando o gpg para verificar que as somas de checagem não foram adulteradas.
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-amd64-<release>.tar.?(bz2|xz){.DIGESTS.asc,} If verification succeeds, "Good signature from" will be in the output of the previous command(s).
As impressões digitais das chaves do OpenGPG usadas para assinar os lançamentos das mídias podem ser encontradas na página de assinaturas de lançamentos de mídias do servidor web Gentoo.
Instalando um arquivo tar de stage
Agora desempacote o stage baixado no sistema. Usamos o tar para isso:
root #tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-ownerCertifique-se que as mesmas opções (xpf e --xattrs-include='*.*') são usadas. O x significa Extrair, o p para "preservar" permissões e o f para indicar que queremos extrair um arquivo ("file"), não da entrada padrão. --xattrs-include='*.*' é para incluir a preservação dos atributos estendidos de todos os arquivos armazenados. Finalmente, --numeric-owner é usado para assegurar que os IDs de usuário e grupo dos arquivos sendo extraídos do arquivo tar permanecerão os mesmos que os pretendidos pela equipe de engenharia de lançamentos do Gentoo (mesmo que usuários aventureiros não estiverem usando a mídia de instalação oficial do 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).
Agora que o arquivo de stage está descompactado, proceda com Configurando as opções de compilação.
Configurando as opções de compilação
Introdução
Para otimizar o Gentoo, é possível ajustar algumas variáveis que impactam o comportamento do Portage, o oficialmente suportado gerenciador de pacotes do Gentoo. Todas essas variáveis podem ser ajustadas como variáveis de ambiente (usando export) mas isso não é permanente. Para manter os ajustes, o Portage lê o arquivo /etc/portage/make.conf, que é um arquivo de configuração do 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.
Uma listagem com comentários de todas as possíveis variáveis pode ser encontrada em /mnt/gentoo/usr/share/portage/config/make.conf.example. Para uma instalação com sucesso do Gentoo, apenas as variáveis mencionadas abaixo precisam ser ajustadas.
For a successful Gentoo installation only the variables that are mentioned below need to be set.}}
Use um editor (neste guia usamos o nano) para alterar as variáveis de otimização que iremos discutir a partir daqui.
root #nano -w /mnt/gentoo/etc/portage/make.confOlhando o arquivo make.conf.example fica óbvio como o arquivo deve ser estruturado: linhas de comentário iniciam com "#", outras linhas definem variáveis usando sintaxe VARIAVEL="conteúdo". Diversas dessas variáveis são discutidas a seguir.
CFLAGS e CXXFLAGS
As variáveis CFLAGS e CXXFLAGS definem as flags de otimização para os compiladores C e C++ GCC, respectivamente. Apesar de serem definidas globalmente aqui, para máximo desempenho seria necessário otimizar essas flags para cada programa separadamente. A razão disso é que cada programa é diferente. Entretanto, isso não é viável, por isso a definição dessas flags no arquivo make.conf.
No arquivo make.conf deve-se definir as flags de otimização que fariam o sistema mais responsivo de modo geral. Não coloque ajustes experimentais nessa variável; otimização demais pode fazer com que os programas comportem-se mal (abortem, ou ainda pior, funcionem mal).
Não iremos explicar todas as possíveis opções de otimização. Para compreender todas elas, leia o Manual Online do GCC ou as páginas info do gcc (info gcc -- funciona apenas em um sistema Linux já instalado). O arquivo make.conf.example em si também contém muitos exemplos e informação; não se esqueça de lê-lo também.
Um primeiro ajuste é a flag -march= ou -mtune=, que especifica o nome da arquitetura alvo. As possíveis opções estão descritas no arquivo make.conf.example (como comentários). Um valor comumente usado é "native", que diz ao compilador para selecionar a arquitetura do sistema atual (aquele no qual o Gentoo está sendo instalado).
Em segundo vem a flag -O (um O maiúsculo, não um zero), que especifica a flag da classe de otimização. Valores possíveis são "s" (para otimização por tamanho), 0 (zero - para nenhuma otimização), 1, 2 ou até 3 para flags de otimização para velocidade (cada classe tem as mesmas flags da anterior, mais algumas extras). -O2 é o padrão recomendado. Sabe-se que -O3 causa problemas se usada pelo sistema como um todo, então recomendamos ficar com -O2.
Uma flag de otimização popular é a -pipe (usa pipes em vez de arquivos temporários para comunicação entre os vários estágios da compilação). Ela não tem impacto no código gerado, mas usa mais memória. Em sistemas com pouca memória, o gcc pode ser morto. Nesse caso, não use essa flag.
Usar o -fomit-frame-pointer (que não mantém o ponteiro de frame em um registrador para funções que não precisam de um) pode ter sérias repercussões para depurar aplicações.
Se as variáveis CFLAGS e CXXFLAGS são definidas, combine as várias flags de otimização em uma string. Os valores default contidos no arquivo stage3 que é desempacotado devem ser adequados. Abaixo é apenas um exemplo:
# Flags do compilador para todas linguagens
COMMON_FLAGS="-march=native -O2 -pipe"
# Use os mesmos valores para ambas variáveis
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
Apesar do artigo Guia de otimização do GCC conter mais informação sobre como as várias opções de compilação podem afetar um sistema, o artigo Safe CFLAGS pode ser uma opção mais prática para iniciantes começarem a otimizar seus sistemas.
MAKEOPTS
A variável MAKEOPTS define quantas compilações paralelas podem ocorrer quando um pacote estiver sendo instalado. Uma boa escolha é o número de CPUs (ou núcleos de CPU) em um sistema mais um, porém essa regra nem sempre é perfeita.
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.
Usar muitos jobs pode impactar significantemente o consumo de memória. Uma boa recomendação é ter pelo menos 2 GiB de RAM para cada job em especifico (então, por exemplo.
-j6 requer pelo menos 12 GiB). Para evitar ficar sem memória, reduza o número de trabalhos para caber na memória disponível.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.
Pronto, preparar, vai!
Atualize o arquivo /mnt/gentoo/etc/portage/make.conf de acordo com suas preferências pessoais e grave (usuários do nano podem usar Ctrl+x).
References