Gentoo Linux mips Handbook: Installing Gentoo
Introdução
Bem-vindo
Em primeiro lugar, bem-vindo ao Gentoo. Você está prestes a entrar em um mundo de opções e performance. O Gentoo é todo sobre opções. Quando você estiver instalando o Gentoo isso é deixado claro muitas vezes -- os usuários podem escolher quanto do sistema querem compilar eles mesmos, como instalar o Gentoo, qual sistema de log usar, etc.
Openness
Gentoo's premier tools are built from simple programming languages. Portage, Gentoo's package maintenance system, is written in Python. Ebuilds, which provide package definitions for Portage are written in bash. Our users are encouraged to review, modify, and enhance the source code for all parts of Gentoo.
By default, packages are only patched when necessary to fix bugs or provide interoperability within Gentoo. They are installed to the system by compiling source code provided by upstream projects into binary format (although support for precompiled binary packages is included too). Configuring Gentoo happens through text files.
For the above reasons and others: openness is built-in as a design principle.
Choice
O Gentoo é uma distribuição veloz e moderna com um projeto limpo e flexível. O Gentoo é construído em torno de um ecossistema de software livre e não esconde de seus usuários o que está "sob o capô do motor". O Portage, o sistema de gerenciamento de pacotes utilizado pelo Gentoo, é escrito em Python, o que significa que o usuário pode facilmente ver e modificar o código fonte. O sistema de pacotes do Gentoo usa código fonte (mas o suporte para pacotes pré-compilados também é incluído) e a configuração do Gentoo é feita através de arquivos texto comuns. Em outras palavras, tudo acontece de forma muito clara e aberta.
When installing Gentoo, choice is made clear throughout the Handbook. System administrators can choose two fully supported init systems (Gentoo's own OpenRC and Freedesktop.org's systemd), partition structure for storage disk(s), what file systems to use on the disk(s), a target system profile, remove or add features on a global (system-wide) or package specific level via USE flags, bootloader, network management utility, and much, much more.
As a development philosophy, Gentoo's authors try to avoid forcing users onto a specific system profile or desktop environment. If something is offered in the GNU/Linux ecosystem, it's likely available in Gentoo. If not, then we'd love to see it so. For new package requests please file a bug report or create your own ebuild repository.
Power
Being a source-based operating system allows Gentoo to be ported onto new computer instruction set architectures and also allows all installed packages to be tuned. This strength surfaces another Gentoo design principle: power.
A system administrator who has successfully installed and customized Gentoo has compiled a tailored operating system from source code. The entire operating system can be tuned at a binary level via the mechanisms included in Portage's make.conf file. If so desired, adjustments can be made on a per-package basis, or a package group basis. In fact, entire sets of functionality can be added or removed using USE flags.
É muito importante que todos entendam que são as escolhas que movem o Gentoo. Nós tentamos não forçar os usuários em nada que eles não gostam. Se alguém pensa ao contrário, por favor, reporte o bug.
Como a instalação é estruturada
A instalação do Gentoo pode ser vista como um procedimento de 10 passos, correspondendo ao conjunto dos próximos capítulos. Cada passo resulta em um certo estado:
Passo | Resultado |
---|---|
1 | O usuário está em um ambiente pronto para instalar o Gentoo |
2 | A conexão com a Internet está pronta para instalar o Gentoo |
3 | Os discos rígidos estão inicializados para receber a instalação do Gentoo |
4 | O ambiente de instalação está preparado e o usuário pronto para fazer chroot no novo ambiente |
5 | Os pacotes básicos, que são os mesmos em qualquer instalação do Gentoo, estão instalados |
6 | O kernel Linux está instalado |
7 | A maior parte dos arquivos de configuração do sistema Gentoo foram criados |
8 | As ferramentas necessárias do sistema estão instaladas |
9 | O gerenciador de boot adequado foi instalado e configurado |
10 | O recém instalado ambiente do Gentoo Linux está pronto para ser explorado. |
Sempre que é apresentada uma escolha a ser feita, o manual tentará explicar quais são os prós e contras de cada escolha, Apesar do texto continuar a partir de uma escolha default (identificada com "Default: " no título), as outras possibilidades serão também documentadas (marcadas como "Alternativa: " no título). Não pense que a escolha default é a recomendada pelo Gentoo. É apenas o que o Gentoo acredita que a maioria dos usuários irá usar.
Às vezes um passo opcional pode ser seguido. Tais passos são marcados com "Opcional: " e são, dessa forma, não necessários para instalar o Gentoo. Entretanto, alguns passos opcionais são dependentes de alguma escolha previamente feita. As instruções informarão ao leitor quando isso acontecer, tanto quando a decisão for feita e logo antes do passo opcional ser descrito.
Opções de Instalação do Gentoo
O Gentoo pode ser instalado de muitas maneiras. Ele pode ser baixado e instalado a partir de uma da mídias oficiais de instalação como as nossas imagens ISO inicializaveis. A mídia de instalação pode ser colocada em um pendrive ou acessada via boot pela rede. Como alternativa, o Gentoo pode ser instalado de uma mídia não oficial como uma distribuição já instalada ou um disco de boot não-Gentoo (como o Knoppix).
Este documento cobre a instalação usando a mídia de instalação oficial do Gentoo ou, em certos casos, netbooting.
Para ajuda com outras abordagens de instalação, incluindo o uso de mídias não-Gentoo, por favor leia o Guia de instalação alternativa.
Também provemos o documento Dicas & truques de instalação do Gentoo que pode ser de utilidade ler também.
Problemas
Se for encontrado um problema na instalação (ou na documentação de instalação), por favor visite nosso sistema de rastreamento de bugs e verifique se é um problema já conhecido. Se não for, por favor, crie um relatório do bug para o problema de modo que possamos resolvê-lo. Não tenha medo dos desenvolvedores para os quais os bugs são designados -- eles (geralmente) não comem pessoas.
Apesar deste documento ser específico para uma arquitetura, ele pode conter referências para outras arquiteturas também, pois grande parte do Manual do Gentoo usa um texto comum para todas as arquiteturas (a fim de evitar duplicação de esforços). Algumas referências foram mantidas ao mínimo, para evitar confusão.
Se houver alguma incerteza sobre um problema ser ou não um problema do usuário (algum erro cometido apesar de ter lido a documentação cuidadosamente) ou um problema do software (algum problema causado por nós, apesar de termos testado a instalação/documentação cuidadosamente) todos são bem-vindos ao canal #gentoo (webchat) no irc.libera.chat. É claro que todos são bem-vindos de qualquer forma uma vez que o canal de bate-papo abrange todo espectro do Gentoo.
Falando nisso, se houver qualquer questão adicional sobre o Gentoo, cheque o artigo Perguntas Frequentemente Feitas (FAQs). Também há FAQs nos Fóruns do Gentoo.
Requisitos de hardware
CPU (Porte Big Endian port) | MIPS3, MIPS4, MIPS5 ou CPU classe MIPS64 |
---|---|
CPU (Porte Little Endian) | MIPS4, MIPS5 ou CPU classe MIPS64 |
Memória | 128 MB |
Espaço em disco | 3.0 GB (excluindo área de swap) |
Área de swap | Pelo menos 256 MB |
Também cheque os Requirimentos de Hardware do MIPS
Notas de instalação
Em muitas arquiteturas, o processador passou por várias gerações, cada geração baseada nos fundamentos da anterior. O MIPS não é exceção. Há várias gerações de CPU sob a arquitetura MIPS. De modo a escolher o arquivo tar de stage com a imagem de netboot e CFLAGS apropriadas, é necessário conhecer a qual família a CPU do sistema pertence. Essas famílias são chamadas de Conjunto de Instruções da Arquitetura ("Instruction Set Architecture" -- ISA).
MIPS ISA | 32/64-bit | CPUs cobertas |
---|---|---|
MIPS 1 | 32-bit | R2000, R3000 |
MIPS 2 | 32-bit | R6000 |
MIPS 3 | 64-bit | R4000, R4400, R4600, R4700 |
MIPS 4 | 64-bit | R5000, RM5000, RM7000 R8000, R9000, R10000, R12000, R14000, R16000 |
MIPS 5 | 4-bit | Nenhuma até agora |
MIPS32 | 32-bit | AMD Alchemy series, 4kc, 4km, e muitas outras... Há algumas revisões na ISA MIPS32. |
MIPS64 | 64-bit | Broadcom SiByte SB1, 5kc ... etc... Há algumas revisões na ISA MIPS64. |
O nível ISA MIPS5 foi projetado pela Silicon Graphics em 1994, mas nunca foi usado em uma CPU real. Ela existe como parte da ISA MIPS64.
As ISAs MIPS32 e MIPS64 são fontes comuns de confusão. O nível ISA MIPS64 é na verdade um superconjunto da ISA MIPS5 e assim ele inclui todas as instruções da ISA MIPS5 e anteriores. MIPS32 é um subconjunto de 32 bits do MIPS64. Ele existe principalmente porque a maioria das aplicações apenas requer processamento de 32 bits.
Também, outro conceito importante a ser digerido é o conceito de "endian". Endian refere-se ao modo em que a CPU lê palavras da memória principal. Uma palavra pode ser lida como ou "big endian" (byte mais significativo primeiro), ou "little endian" (byte menos significativo primeiro). Máquinas Intel x86 são geralmente little endian, enquanto máquinas Apple e Sparc são big endian. No MIPS, podem ser ambos. Para separá-las, acrescentamos "el" ao nome da arquitetura para denotar little endian.
Arquitetura | 32/64-bit | Endian | Máquinas cobertas |
---|---|---|---|
mips | 32-bit | Big Endian | Silicon Graphics |
mipsel | 32-bit | Little Endian | Cobalt Servers |
mips64 | 64-bit | Big Endian | Silicon Graphics |
mips64el | 64-bit | Little Endian | Cobalt Servers |
Aqueles que quiserem aprender mais sobre ISAs, os sites abaixo podem ser úteis:
- Linux/MIPS Website: MIPS ISA
- Linux/MIPS Website: Endianness
- Linux/MIPS Website: Processors
- Wikipedia: Instruction Set
Visão geral do boot pela rede
Neste seção mostraremos o que é necessário para fazer boot pela rede de uma estação de trabalho Silicon Graphics ou de um dispositivo Cobalt Server. Este é apenas um guia rápido, não sendo feito para ser extensivo. Para mais informação, é recomendada a leitura do artigo Nós sem disco.
Dependendo da máquina, há uma certa quantidade de hardware necessária para fazer boot pela rede e instalar o Linux nela com sucesso.
- Em geral:
- DHCP/BOAMD Série Alchemy, 4kc, 4km, várias outras... Há algumas revisões na ISA MIPS32. Servidor OTP (recomendado o ISC DHCPd)
- Paciência -- muita
- Para estações de trabalho Silicon Graphics:
- Servidor TFTP (recomendado o tftp-hpa)
- Se for necessário usar o console serial:
- Cabo serial MiniDIN8 --> RS-232 (necessário apenas para sistemas IP22 e IP28)
- Cabo Null-modem
- Terminal compatível VT100 ou ANSI capaz de operar a 9600 bauds
- Para Cobalt Servers (NÃO o Qube original):
- Servidor NFS
- Cabo null-modem
- Terminal compatível VT100 ou ANSI capaz de operar a 115200 bauds
Máquinas SGI usam um conector MiniDIN 8 nas portas seriais. Aparentemente, cabos de modem da Apple funcionam bem como cabos seriais, mas com as máquinas da Apple vindo equipadas com portas USB e modens internos, esses cabos estão cada vez mais difíceis de achar. Um diagrama de conexões está disponível no Wiki Linux/MIPS, e a maioria das lojas de eletrônica deve ter os plugues necessários.
O terminal pode ser um terminal VT100/ANSI real, ou pode ser um PC rodando um software de emulação de terminal (tal como HyperTerminal, Minicom, seyon, Telex, xc, screen - qualquer um de sua preferência). Não importa qual a plataforma dessa máquina - apenas que ela tenha uma porta serial RS-232 disponível e o software apropriado.
Este guia NÃO cobre o Qube original. O servidor Qube original não dispõe de uma porta serial em sua configuração default e, assim, não é possível instalar o Gentoo nele sem a ajuda de uma chave de fenda e uma máquina extra.
Configurando TFTP e DHCP
Como mencionado anteriormente, este não é um guia completo, mas apenas uma configuração básica para que as coisas funcionem. Use este guia quando estiver instalando do zero ou use como sugestões adicionais a uma configuração que suporte boot pela rede.
Vale a pena notar que os servidores usados não precisam estar rodando o Gentoo Linux, eles podem muito bem estar usando FreeBSD ou qualquer outra plataforma do tipo Unix. Entretanto, este guia assume que está sendo usado o Gentoo Linux. Se desejado, é também possível usar TFTP/NFS em uma máquina separada do servidor DHCP.
A equipe do Gentoo/MIPS não pode ajudar com a configuração de outros sistemas operacionais como servidores de boot de rede.
Primeiro Passo -- configurar o DHCP. De modo ao servidor ISC DHCP responder às solicitações de requisição BOOTP (necessário pela SGI & Cobalt BOOTROM) primeiro habilite o BOOTP dinâmico na faixa de endereços em uso; depois configure uma entrada para cada cliente apontando para a imagem de boot.
root #
emerge --ask net-misc/dhcp
Uma vez instalado, crie o arquivo /etc/dhcp/dhcpd.conf. Aqui está uma configuração básica para servir de início.
# Diga ao dhcpd para desabilitar o DNS dinâmico.
# dhcpd não iniciará sem isso.
ddns-update-style none;
# Crie uma sub-rede:
subnet 192.168.10.0 netmask 255.255.255.0 {
# Faixa de endereços para inicializar os clientes. Não se esqueça do 'dynamic-bootp'!
pool {
range dynamic-bootp 192.168.10.1 192.168.10.254;
}
# Servidores DNS e default gateway -- substitua conforme apropriado
option domain-name-servers 203.1.72.96, 202.47.56.17;
option routers 192.168.10.1;
# Diga ao servidor DHCP que ele é autoritativo para esta sub-rede.
authoritative;
# Permita o uso de BOOTP nesta sub-rede.
allow bootp;
}
Com essa configuração pode-se adicionar qualquer número de clientes na cláusula de subnet.
Próximo passo -- Configurar o servidor TFTP. É recomendado o uso do tftp-hpa uma vez que é o único servidor TFTP que se sabe funcionar corretamente. Proceda instalando-o como mostrado abaixo:
root #
emerge --ask net-ftp/tftp-hpa
Isso irá criar o diretório /tftproot para armazenar as imagens de boot. Mova para outro lugar, se necessário. Para os propósitos deste guia, será assumido que foi mantido na localização default.
Fazendo boot de rede em estações SGI
Baixando uma imagem de boot de rede
Dependendo do objetivo da instalação, há diversas imagens possíveis disponíveis para download. Elas são nomeadas de acordo com o tipo do sistema e da CPU para a qual a imagem foi compilada. Os tipos de máquinas são os seguintes:
Nome-código | Máquinas |
---|---|
IP22 | Indy, *Indigo 2, Challenge S |
IP26 | *Indigo 2 Power |
IP27 | Origin 200, Origin 2000 |
IP28 | *Indigo 2 Impact |
IP30 | Octane |
IP32 | O2 |
Indigo 2 - É um erro comum confundir as IRIS Indigo (IP12 com CPU R3000 CPU ou IP20 com uma CPU R4000, nenhuma das quais roda Linux), a Indigo 2 (IP22, que roda Linux bem), a Indigo 2 Power baseada no R8000 (que não roda Linux de nenhuma maneira) e a Indigo 2 Impact baseada no R10000 (IP28, que é altamente experimental). Tenha em mente que se trata de máquinas diferentes.
Também, no arquivo, r4k refere-se à serie de processadores R4000, r5k à R5000, rm5k para a RM5200 e r10k para a R10000. As imagens estão disponíveis nos espelhos do Gentoo.
Configuração DHCP para um cliente SGI
Depois de baixar o arquivo, coloque a imagem descompactada no diretório /tftproot/ (use bzip2 -d para descompactar). Depois edite o arquivo /etc/dhcp/dhcpd.conf e adicione a entrada adequada para o cliente SGI.
subnet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx {
# ... configurações normais aqui ...
# Estação de trabalho SGI... troque 'sgi' pelo nome de host de sua máquina SGI.
host sgi {
# Endereço MAC da máquina SGI. Normalmente fica escrito na traseira ou parte de baixo da máquina
hardware ethernet 08:00:69:08:db:77;
# Servidor TFTP Server do qual será baixada (por default, mesmo que o servidor DHCP)
next-server 192.168.10.1;
# Endereço IP para fornecer à máquina SGI
fixed-address 192.168.10.3;
# Nome do arquivo da PROM a baixar e dar boot
filename "/gentoo-r4k.img";
}
}
Opções do kernel
Estamos terminando, mas há alguns pequenos ajustes ainda a serem feitos. Abra um console como usuário root.
Desabilite o "Path Maximum Transfer Unit" ou senão a PROM SGI não encontrará o kernel:
root #
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
root #
echo "2048 32767" > /proc/sys/net/ipv4/ip_local_port_range
root #
echo "2048 32767" > /proc/sys/net/ipv4/ip_local_port_range
Isso deve ser suficiente para permitir que o servidor Linux funcione corretamente com a PROM da SGI.
Iniciando os serviços
Neste ponto, inicie os serviços.
root #
/etc/init.d/dhcp start
root #
/etc/init.d/in.tftpd start
Se nada de errado ocorreu no passo anterior, tudo está pronto para ligar a estação de trabalho e prosseguir com o guia. Se o servidor DHCP não estiver subindo, por qualquer razão, tente rodar dhcpd na linha de comando e veja o que ele diz. Se estiver tudo bem, ele deve apenas entrar em execução em segundo plano, ou senão ele mostrará "exiting." logo abaixo de sua mensagem de erro.
Uma maneira fácil de verificar se o serviço tftp está rodando é digitar o comando abaixo e checar a saída:
root #
netstat -al | grep ^udp
udp 0 0 *:bootpc *:* udp 0 0 *:631 *:* udp 0 0 *:xdmcp *:* udp 0 0 *:tftp *:* <-- (procure por esta linha)
Inicializando a estação SGI pela rede
OK, tudo configurado, o DHCP está rodando assim como o TFTP. Agora é hora de ligar a máquina SGI. Ligue a unidade, quando a mensagem "Running power-on diagnostics" aparecer na tela, clique em "Stop For Maintenance" ou pressione Escape. Um menu similar ao abaixo irá aparecer.
Running power-on diagnostics
System Maintenance Menu 1 - Start System 2 - Install System Software 3 - Run Diagnostics 4 - Recover System 5 - Enter Command Monitor Option?
Tecle 5 para entrar no monitor de comandos. No monitor, inicie o processo BootP:
>>
bootp(): root=/dev/ram0
A partir deste ponto, a máquina deve começar a baixar a imagem e então, aproximadamente 20 segundos depois, começar a iniciar o Linux. Se tudo correr bem, um shell ash do busybox deve iniciar como mostrado abaixo e a instalação do Gentoo Linux pode continuar.
init started: BusyBox v1.00-pre10 (2004.04.27-02:55+0000) multi-call binary
Gentoo Linux; http://www.gentoo.org/
Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL
Gentoo/MIPS Netboot for Silicon Graphics Machines
Build Date: April 26th, 2004
* To configure networking, do the following:
* For Static IP:
* /bin/net-setup <IP Address> <Gateway Address> [telnet]
* For Dynamic IP:
* /bin/net-setup dhcp [telnet]
* If you would like a telnetd daemon loaded as well, pass "telnet"
* As the final argument to /bin/net-setup.
Please press Enter to activate this console.
Resolução de problemas
Se a máquina não cooperar e recusar a baixar a image, pode ser umas das duas coisas:
- As instruções não foram seguidas corretamente, ou
- Ela precisa de um pouco de persuasão (Não, abaixe essa marreta!)
Eis uma lista de coisas a checar:
- Se o dhcpd está entregando à máquina SGI um endereço IP. Deve haver mensagens sobre a requisição BOOTP nos logs do sistema. O tcpdump também é útil neste caso.
- Se as permissões configuradas corretamente na pasta do tftp (normalmente /tftproot/ - deve ter permissão de leitura para todos)
- Cheque os logs do sistema para ver o que o tftp está reportando (erros, talvez)
Se tudo foi checado no servidor, e timeouts e outros erros aparecerem na máquina SGI, tente entrar isto no console:
>>
resetenv
>>
unsetenv netaddr
>>
unsetenv dlserver
>>
init
>>
bootp(): root=/dev/ram0
Boot de rede em estações Cobalt
Visão geral do funcionando de boot pela rede
Diferentemente das máquinas SGI, servidores Cobalt usam NFS para transferir seus kernel para iniciar o boot. Dê boot na máquina segurando apertadas as teclas de seta para esquerda e seta para direita enquanto a máquina é ligada. A máquina vai então tentar obter um endereço IP por bootp, montar o diretório /nfsroot/ do servidor por NFS e então tentar baixar dar boot no arquivo vmlinux_raq-2800.gz (dependendo do modelo) que assume que seja um arquivo binário ELF padrão.
Baixando uma imagem de boot de rede do Cobalt
Em http://distfiles.gentoo.org/experimental/mips/historical/netboot/cobalt/ encontram-se as imagens de boot necessárias para se ter uma Cobalt rodando. Esses arquivos tem o nome no formato nfsroot-KERNEL-COLO-DATA-cobalt.tar - selecione o mais recente e descompacte-o em / como mostrado abaixo:
root #
tar -C / -xvf nfsroot-2.6.13.4-1.19-20051122-cobalt.tar
Configuração do servidor NFS
Como esta máquina usa NFS para baixar sua imagem, é necessário exportar o diretório /nfsroot/ no servidor. Instale o pacote net-fs/nfs-utils:
root #
emerge --ask net-fs/nfs-utils
Uma vez feito, coloque o seguinte no arquivo /etc/exports:
/nfsroot *(ro,sync)
Agora inicie o servidor NFS:
root #
/etc/init.d/nfs start
Se o servidor NFS já estava rodando, diga a ele para recarregar seu arquivo exports usando o comando exportfs:
root #
exportfs -av
Configuração DHCP para uma máquina Cobalt
A parte do DHCP é relativamente simples. Adicione o seguinte ao arquivo /etc/dhcp/dhcpd.conf:
subnet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx {
# ... coisas de sempre ...
# Configuracao para um servidor Cobalt
# Configure o nome da maquina aqui:
host qube {
# Caminho para o diretorio nfsroot.
# Isto é principalmente para quando usar a opção de boot do TFTP no CoLo
# Não deve ser necessário alterar isto.
option root-path "/nfsroot";
# Endereço MAC ethernet do servidor Cobalt
hardware ethernet 00:10:e0:00:86:3d;
# De qual servidor baixar a imagem
next-server 192.168.10.1;
# Endereço IP do servidor Cobalt
fixed-address 192.168.10.2;
# Localização do arquivo default.colo relativa ao /nfsroot
# Não deve ser necessário alterar isto.
filename "default.colo";
}
}
Iniciando os serviços
Agora inicie os serviços. Digite o seguinte:
root #
/etc/init.d/dhcp start
root #
/etc/init.d/nfs start
Se tudo correu bem no passo anterior então tudo está pronto para ligar a estação de trabalho e prosseguir com o guia. Se o servidor DHCP não estiver iniciando por algum motivo, tente rodar dhcpd na linha de comando e ver o que ele mostra - se estiver tudo certo, ele deve ir para o segundo plano ou senão, ele irá mostrar 'exiting' logo abaixo da mensagem de erro.
Fazendo boot pela rede na máquina Cobalt
Chegou a hora de ligar a máquina Cobalt. Ligue o cabo do modem e configure o terminal para usar 115200 bauds, sem paridade, 1 stop bit e emulação VT100. Uma vez feito isso, segure pressionadas as teclas de seta para esquerda e seta para direita enquanto ligar a máquina.
O painel traseiro deve mostrar "Net Booting" e alguma atividade de rede deve ser visível, logo seguida da entrada do CoLo. No painel traseiro, role o menu para baixo até a opção "Network (NFS)" e pressione Enter. Note que a máquina inicia o boot pelo console serial.
...
elf: 80080000 <-- 00001000 6586368t + 192624t elf: entry 80328040 net: interface down CPU revision is: 000028a0 FPU revision is: 000028a0 Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes. Primary data cache 32kB 2-way, linesize 32 bytes. Linux version 2.4.26-mipscvs-20040415 (root@khazad-dum) (gcc version 3.3.3...) Determined physical RAM map: memory: 08000000 @ 00000000 (usable) Initial ramdisk at: 0x80392000 (3366912 bytes) On node 0 totalpages: 32768 zone(0): 32768 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=ttyS0,115200 root=/dev/ram0 Calibrating delay loop... 249.85 BogoMIPS Memory: 122512k/131072k available (2708k kernel code, 8560k reserved, 3424k dat)
Um shell ash do buybox irá ser executado, como mostrado abaixo, de onde a instalação do Gentoo Linux pode continuar.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 280k freed
init started: BusyBox v1.00-pre10 (2004.04.27-02:55+0000) multi-call binary
Gentoo Linux; http://www.gentoo.org/
Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL
Gentoo/MIPS Netboot for Cobalt Microserver Machines
Build Date: April 26th, 2004
* To configure networking, do the following:
* For Static IP:
* /bin/net-setup <IP Address> <Gateway Address> [telnet]
* For Dynamic IP:
* /bin/net-setup dhcp [telnet]
* If you would like a telnetd daemon loaded as well, pass "telnet"
* As the final argument to /bin/net-setup.
Please press Enter to activate this console.
Resolução de problemas
Se a máquina não cooperar e recusar a baixar a image, pode ser umas das duas coisas:
- As instruções não foram seguidas corretamente, ou
- Ela precisa de um pouco de persuasão (Não, abaixe essa marreta!)
Eis uma lista de coisas a checar:
- Se o dhcpd está entregando à máquina Cobalt um endereço IP. Verifique mensagens sobre a requisição BOOTP nos logs do sistema. O tcpdump também é útil neste caso.
- Se as permissões foram configuradas corretamente na pasta /nfsroot/ - deve ter permissão de leitura para todos
- Verifique se o servidor NFS está rodando e exportando o diretório /nfsroot/. Verifique isso usando o comando exportfs -v no servidor.
Usando um CD de instalação
Em máquinas Silicon Graphics é possível dar boot de um CD de modo a instalar sistemas operacionais (essa é a maneira de se instalar o IRIX na verdade). Recentemente, imagens de CDs bootáveis para instalação do Gentoo tornaram-se possíveis. Esses CDs são criados para funcionar da mesma forma.
Até o momento, o Live CD do Gentoo/MIPS irá funcionar apenas nas estações SGI Indy, Indigo 2 e O2, equipadas com CPUs das séries R4000 e R5000, entretanto, outras plataformas podem ser adicionadas no futuro.
As imagens do Live CD podem ser encontradas no diretório experimental/mips/livecd/ em um espelho do Gentoo.
Essas imagens de CD são altamente experimentais até o momento e podem ou não funcionar. Por favor relate sucessos ou falhas através do Bugzilla, nesta discussão do fórum ou no canal IRC #gentoo-mips.
Detecção automática de rede
Talvez já esteja funcionando?
Se o sistema estiver conectado a uma rede Ethernet com um servidor DHCP, é muito provável que a configuração de rede já tenha sido feita automaticamente. Se for o caso, então os muitos comandos incluidos na mídia de instalação que dependem da rede tais como ssh, scp, ping, irssi, wget e links, entre outros, funcionarão imediatamente.
Usando DHCP
DHCP ("Dynamic Host Configuration Protocol" - Protocolo de Configuração Dinâmica de Host) torna possível obter informações de rede (endereço IP, máscara de rede, endereço de broadcast, servidores de nomes etc). Isso funciona apenas se houver um servidor DHCP na rede (ou se o provedor de Internet provê serviço DHCP). Para que uma interface de rede receba essa informação automaticamente, use dhcpcd:
DHCP requires that a server be running on the same Layer 2 (Ethernet) segment as the client requesting a lease. DHCP is often used on RFC1918 (private) networks, but is also used to acquire public IP information from ISPs.
Official Gentoo boot media runs dhcpcd automatically at startup. This behavior can be disabled by adding the
nodhcp
argument to the boot media kernel commandline.If it is not already running, dhcpcd can be started on enp1s0 with:
root #
dhcpcd eth0
Alguns administradores de rede requerem que o nome de host e o nome de domínio providos pelo servidor DHCP sejam usados pelo sistema. Nesse caso, use:
root #
dhcpcd -HD eth0
To stop dhcpcd, -x can be used:
root #
dhcpcd -x
sending signal Term to pid 10831 waiting for pid 10831 to exit
Dhcpcd usage
Testando a rede
A properly configured default route is a critical component of Internet connectivity, route configuration can be checked with:
root #
ip route
default via 192.168.0.1 dev enp1s0
If no default route is defined, Internet connectivity is unavailable, and additional configuration is required.
Basic internet connectivity can be confirmed with a ping:
root #
ping -c 3 1.1.1.1
It's helpful to start by pinging a known IP address instead of a hostname. This can isolate DNS issues from basic Internet connectivity issues.
Outbound HTTPS access and DNS resolution can be confirmed with:
root #
curl --location gentoo.org --output /dev/null
Se tudo funcionar, então o restante deste capítulo pode ser pulado para o próximo passo das instruções de instalação (Preparando os discos).
If curl reports an error, but Internet-bound pings work, DNS may need configuration.
If Internet connectivity has not been established, first interface information should be verified, then:
- net-setup can be used to assist in network configuration.
- Application specific configuration may be required.
- Manual network configuration can be attempted.
Determine os nomes das interfaces
If networking doesn't work out of the box, additional steps must be taken to enable Internet connectivity. Generally, the first step is to enumerate host network interfaces.
Como alternativa ao ifconfig, o comando ip pode ser usado para se determinar nomes de interfaces. O exemplo a seguir mostra a saída de ip addr (de um outro sistema, assim a informação mostrada é diferente do exemplo anterior):
The link argument can be used to display network interface links:
root #
ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 4: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether e8:40:f2:ac:25:7a brd ff:ff:ff:ff:ff:ff
The address argument can be used to query device address information:
root #
ip addr
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether e8:40:f2:ac:25:7a brd ff:ff:ff:ff:ff:ff inet 10.0.20.77/22 brd 10.0.23.255 scope global eno1 valid_lft forever preferred_lft forever inet6 fe80::ea40:f2ff:feac:257a/64 scope link valid_lft forever preferred_lft forever
The output of this command contains information for each network interface on the system. Entries begin with the device index, followed by the device name: enp1s0.
Se não for mostrada nenhuma interface quando o comando padrão ifconfig for usado, tente usar o mesmo comando com a opção
-a
. Essa opção força o comando a mostrar todas as interfaces de rede detectadas pelo sistema independentemente de estarem em estado ativo ou inativo. Se o ifconfig -a não mostrar nenhum resultado então o hardware está com problema ou o driver da interface não foi carregado no kernel. Ambas as situações estão além do escopo deste manual. Contate o canal #gentoo (webchat) para suporte.No restante deste documento, o manual assumirá que a interface de rede é chamada eth0.
Como resultado de mudanças em favor de nomes de interfaces de rede predizíveis, o nome da interface do sistema pode ser bem diferente do antigo nome eth0. Mídias recentes de instalação pode mostrar nomes de interface de rede como eno0, ens1 ou enp5s0. Procure o nome da interface na saída do comando ifconfig que tem um endereço IP relacionado à rede local.
Optional: Application specific configuration
The following methods are not generally required, but may be helpful in situations where additional configuration is required for Internet connectivity.
Opcional: Configuração de proxy
Se a Internet é acessada através de um proxy, então é necessário entrar com as informações do proxy durante a instalação. É muito fácil definir um proxy: apenas defina uma variável que contém as informações do servidor proxy.
Certain text-mode web browsers such as links can also make use of environment variables that define web proxy settings; in particular for the HTTPS access it also will require the https_proxy environment variable to be defined. While Portage will be influenced without passing extra run time parameters during invocation, links will require proxy settings to be set.
Na maioria dos casos, é suficiente definir as variáveis usando o nome do servidor. Como exemplo, vamos assumir que o proxy é chamado proxy.gentoo.org e a porta é 8080.
The
#
symbol in the following commands is a comment. It has been added for clarity only and does not need to be typed when entering the commands.Para configurar um proxy HTTP (para tráfego HTTP e HTTPS):
root #
export http_proxy="http://proxy.gentoo.org:8080"
Se o proxy requer um nome de usuário e senha, use a seguinte sintaxe para a variável:
http://usuário:senha@proxy.gentoo.org:8080
Start links using the following parameters for proxy support:
user $
links -http-proxy ${http_proxy} -https-proxy ${https_proxy}
Para configurar um proxy FTP:
root #
export ftp_proxy="ftp://proxy.gentoo.org:8080"
Start links using the following parameter for a FTP proxy:
user $
links -ftp-proxy ${ftp_proxy}
Para configurar um proxy rsync:
root #
export RSYNC_PROXY="proxy.gentoo.org:8080"
Alternativa: Usando PPP
If PPPoE is required for Internet access, the Gentoo boot media includes the pppoe-setup script to simplify ppp configuration.
During setup, pppoe-setup will ask for:
- The name of the Ethernet interface connected to the ADSL modem.
- The PPPoE username and password.
- DNS server IPs.
- Whether or not a firewall is needed.
root #
pppoe-setup
root #
pppoe-start
In the event of failure, credentials in /etc/ppp/pap-secrets or /etc/ppp/chap-secrets should be verified. If credentials are correct, PPPoE Ethernet interface selection should be checked.
Alternativa: Usando PPTP
Se for necessário suporte a PPTP, use pptpclient, que é provido pelos CDs de instalação. Mas primeiro certifique-se que a configuração está correta. Edite /etc/ppp/pap-secrets ou /etc/ppp/chap-secrets de modo que contenha a combinação correta de usuário e senha:
Edit /etc/ppp/pap-secrets or /etc/ppp/chap-secrets so it contains the correct username/password combination:
root #
nano -w /etc/ppp/chap-secrets
Depois ajuste o /etc/ppp/options.pptp se necessário:
root #
nano -w /etc/ppp/options.pptp
Quando tudo pronto, execute pptp (juntamente com as opções que não puderam ser incluídas em options.pptp) para conectar ao servidor:
root #
pptp <endereço ipv4 do servidor>
Preparando para acesso sem fio
Do not use WEP unless it is the only option. WEP provides essentially no security over an open network.
O suporte ao comando iw pode ser específico da arquitetura. Se o comando não estiver disponível, verifique se o pacote net-wireless/iw está disponível para essa arquitetura. O comando iw estará indisponível até que o pacote net-wireless/iw esteja instalado.
Quando usar uma conexão sem fio (802.11), as configurações sem fio precisam ser feitas antes de qualquer coisa. Para ver as configurações atuais da placa usa-se o iw. Executando o iw deve aparecer algo como:
root #
iw dev wlp9s0 info
Interface wlp9s0 ifindex 3 wdev 0x1 addr 00:00:00:00:00:00 type managed wiphy 0 channel 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz txpower 30.00 dBm
Para verificar a conexão atual:
root #
iw dev wlp9s0 link
Not connected.
ou
root #
iw dev wlp9s0 link
Connected to 00:00:00:00:00:00 (on wlp9s0) SSID: GentooNode freq: 2462 RX: 3279 bytes (25 packets) TX: 1049 bytes (7 packets) signal: -23 dBm tx bitrate: 1.0 MBit/s
Algumas interfaces sem fio podem ter o nome de interface tais como wlan0 ou ra0 em vez de eth0. Execute ip link para determinar o nome correto da interface.
Para a maioria dos usuários há apenas dois parâmetros necessários para a conexão, o ESSID (nome da rede sem fio) e, opcionalmente, a chave WEP.
- Primeiro, certifique-se que a interface está ativa:
root #
ip link set dev wlp9s0 up
- Para conexão com uma rede aberta de nome GentooNode:
root #
iw dev wlp9s0 connect -w GentooNode
- Para conexão usando uma chave WEP em hexadecimal, prefixe a chave com
d:
:
root #
iw dev wlp9s0 connect -w GentooNode key 0:d:1234123412341234abcd
- Para conexão usando uma chave WEP em ASCII:
root #
iw dev wlp9s0 connect -w GentooNode key 0:some-password
Se a rede sem fio estiver configurada com WPA ou WPA2, então é necessário usar o wpa_supplicant. Para mais informações sobre a configuração de rede sem fio no Gentoo Linux, por favor leia o capítulo sobre rede sem fio do Manual do Gentoo.
Verifique novamente a configuração da rede sem fio usando o iw dev wlp9s0 link. Uma vez que a rede sem fio estiver funcionando, prossiga com a configuração das opções de rede a nível de IP como descrita na próxima seção (Entendendo a terminologia de rede) ou use o comando net-setup como descrito anteriormente.
Configuração automática de rede
In cases where automatic network configuration is unsuccessful, the Gentoo boot media provides scripts to aid in network configuration. net-setup can be used to configure wireless network information and static IPs.
root #
net-setup eth0
O net-setup irá fazer algumas perguntas sobre o ambiente de rede. Quando terminar, a conexão de rede deve funcionar. Teste a conexão de rede como descrito anteriormente. Se os testes derem certo, parabéns! Pule o resto desta seção e continue com Preparando os discos.
Network status should be tested after any configuration steps are taken. In the event that configuration scripts do not work, manual network configuration is required.
Entendendo a terminologia de rede
If all of the above fails, the network must be configured manually. This is not particularly difficult, but should be done with consideration. This section serves to clarify terminology and introduce users to basic networking concepts pertaining to manually configuring an Internet connection.
Some CPE (Carrier Provided Equipment) combines the functions of a router, access point, modem, DHCP server, and DNS server into one unit. It's important to differentiate the functions of a device from the physical appliance.
Interfaces and addresses
Network interfaces are logical representations of network devices. An interface needs an address to communicate with other devices on the network. While only a single address is required, multiple addresses can be assigned to a single interface. This is especially useful for dual stack (IPv4 + IPv6) configurations.
For consistency, this primer will assume the interface enp1s0 will be using the address 192.168.0.2.
IP addresses can be set arbitrarily. As a result, it's possible for multiple devices to use the same IP address, resulting in an address conflict. Address conflicts should be avoided by using DHCP or SLAAC.
IPv6 typically uses StateLess Address AutoConfiguration (SLAAC) for address configuration. In most cases, manually setting IPv6 addresses is a bad practice. If a specific address suffix is preferred, interface identification tokens can be used.
Networks and CIDR
Once an address is chosen, how does a device know how to talk to other devices?
IP addresses are associated with networks. IP networks are contiguous logical ranges of addresses.
Classless Inter-Domain Routing or CIDR notation is used to distinguish network sizes.
- The CIDR value, often notated starting with a /, represents the size of the network.
- The formula 2 ^ (32 - CIDR) can be used to calculate network size.
- Once network size is calculated, usable node count must be reduced by 2.
- The first IP in a network is the Network address, and the last is typically the Broadcast address. These addresses are special and cannot be used by normal hosts.
The most common CIDR values are /24, and /32, representing 254 nodes and a single node respectively.
A CIDR of /24 is the de-facto default network size. This corresponds to a subnet mask of 255.255.255.0, where the last 8 bits are reserved for IP addresses for nodes on a network.
The notation: 192.168.0.2/24 can be interpreted as:
- The address 192.168.0.2
- On the network 192.168.0.0
- With a size of 254 (2 ^ (32 - 24) - 2)
- Usable IPs are in the range 192.168.0.1 - 192.168.0.254
- With a broadcast address of 192.168.0.255
- In most cases, the last address on a network is used as the broadcast address, but this can be changed.
Using this configuration, a device should be able to communicate with any host on the same network (192.168.0.0).
The Internet
Once a device is on a network, how does it know how to talk to devices on the Internet?
To communicate with devices outside of local networks, routing must be used. A router is simply a network device that forwards traffic for other devices. The term default route or gateway typically refers to whatever device on the current network is used for external network access.
It's a standard practice to make the gateway the first or last IP on a network.
If an Internet-connected router is available at 192.168.0.1, it can be used as the default route, granting Internet access.
To summarize:
- Interfaces must be configured with an address and network information, such as the CIDR value.
- Local network access is used to access a router on the same network.
- The default route is configured, so traffic destined for external networks is forwarded to the gateway, providing Internet access.
The Domain Name System
Remembering IPs is hard. The Domain Name System was created to allow mapping between Domain Names and IP addresses.
Linux systems use /etc/resolv.conf to define nameservers to be used for DNS resolution.
Many routers can also function as a DNS server, and using a local DNS server can augment privacy and speed up queries through caching.
Many ISPs run a DNS server that is generally advertised to the gateway over DHCP. Using a local DNS server tends to improve query latency, but most public DNS servers will return the same results, so server usage is largely based on preference.
Configuração manual de rede
Interface address configuration
When manually configuring IP addresses, the local network topology must be considered. IP addresses can be set arbitrarily; conflicts may cause network disruption.
To configure enp1s0 with the address 192.168.0.2 and CIDR /24:
root #
ip address add 192.168.0.2/24 dev enp1s0
The start of this command can be shortened to ip a.
Default route configuration
Configuring address and network information for an interface will configure link routes, allowing communication with that network segment:
root #
ip route
192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.2
This command can be shortened to ip r.
The default route can be set to 192.168.0.1 with:
root #
ip route add default via 192.168.0.1
DNS configuration
Nameserver info is typically acquired using DHCP, but can be set manually by adding nameserver
entries to /etc/resolv.conf.
If dhcpcd is running, changes to /etc/resolv.conf will not persist. Status can be checked with
ps x | grep dhcpcd
.nano is included in Gentoo boot media and can be used to edit /etc/resolv.conf with:
root #
nano -w /etc/resolv.conf
Lines containing the keyword nameserver
followed by a DNS server IP address are queried in order of definition:
nameserver 9.9.9.9
nameserver 149.112.112.112
nameserver 1.1.1.1
nameserver 1.0.0.1
DNS status can be checked by pinging a domain name:
root #
ping -c 3 gentoo.org
Once connectivity has been verified, continue with Preparing the disks.
Introdução aos dispositivos de bloco
Dispositivos de bloco
Vamos dar uma boa olhada nos aspectos relacionados a discos do Gentoo Linux e do Linux em geral, incluindo dispositivos de bloco, partições e sistemas de arquivos Linux. Uma vez que os meandros dos discos forem compreendidos, serão configurados as partições e sistemas de arquivos para a instalação do Gentoo Linux.
Para começar, vamos dar uma olhada nos dispositivos de bloco. As unidades SCSI e Serial ATA são rotuladas pelo sistema como: /dev/sda, /dev/sdb, /dev/sdc, etc. Em maquinas modernas, os discos rígidos NVMe baseados em PCI Express são identificados como /dev/nvme0n1, /dev/nvme0n2, etc.
A tabela abaixo ajudará os leitores a determinar onde encontrar um certo tipo de dispositivo de bloco no sistema:
Tipos de dispositivo | Identificador de dispositivo padrão | Notas do editor e considerações |
---|---|---|
SATA, SAS, SCSI, ou USB flash | /dev/sda | Encontrados em hardware por volta de 2007 até os dias atuais, esses dispositivos são geralmente identificados no Linux dessa forma. Esses tipos de dispositivos podem ser conectados pelas entradas SATA, SCSI, USB como armazenamento em bloco. Por exemplo, a primeira partição do primeiro dispositivo SATA device é chamada de /dev/sda1. |
NVM Express (NVMe) | /dev/nvme0n1 | A mais recente tecnologia de disco rigido, NVMe drives são conectados via PCI Express bus e possuem a velocidade de transferência de blocos mais rápida do mercado. Sistemas por volta de 2014 e recentes possuem suporte para NVMe no hardware. A primeira partição no primeiro dispositivo NVMe é chamada de /dev/nvme0n1p1. |
MMC, eMMC, e SD | /dev/mmcblk0 | Dispositivos embutidos MMC, cartões SD, e outros tipos de cartões de memória podem ser uteis para armazenar dados. Dito isso, muitos sistemas talvez não permitam iniciar a partir desses tipos de dispositivo. É sugerido que não se use esses dispositivos para iniciar uma instalação do Linux; em vez disso, considere usá-los com o objetivo de transferir arquivos, no qual eles foram projetados. Alternativamente, eles podem ser úteis para backups de curto prazo. |
Os dispositivos de bloco acima representam uma interface abstrata para o disco. Programas de usuários podem usar esses dispositivos de bloco para interagir com o disco sem se preocupar se são SATA, SCSI, ou de outro tipo. O programa pode simplesmente endereçar o armazenamento do disco como um grupo de blocos de 4096-bytes (4K) contínuos e acessíveis aleatoriamente.
Partições
Apesar de ser teoricamente possível usar um disco inteiro para alojar um sistema Linux, isso quase nunca é feito na prática. Em vez disso, dispositivos de blocos inteiros são divididos em dispositivos de blocos menores e mais gerenciáveis chamados partições.
Criando um esquema de particionamento
Quantas partições e de que tamanho?
O design do layout de partições é altamente dependente das demandas do sistema e do(s) sistema(s) de arquivos aplicados ao dispositivo. Caso exista muitos usuários, é aconselhável ter o /home/ em uma partição separada pois isso traz segurança e torna o backup e outros tipos de manutenção mais fáceis. Se o Gentoo estiver sendo instalado para ser um pequeno servidor de email, então o diretório /var/ deve ficar separado em uma outra partição pois todos os emails armazenados ficam no /var/. Servidores de jogos podem ter o /opt/ separado em uma outra partição, já que a maioria dos softwares do servidor são instalados lá. A razão dessas recomendações são similares à do diretório /home/: segurança, backups e manutenções.
In most situations on Gentoo, /usr and /var should be kept relatively large in size. /usr hosts the majority of applications available on the system and the Linux kernel sources (under /usr/src). By default, /var hosts the Gentoo ebuild repository (located at /var/db/repos/gentoo) which, depending on the file system, generally consumes around 650 MiB of disk space. This space estimate excludes the /var/cache/distfiles and /var/cache/binpkgs directories, which will gradually fill with source files and (optionally) binary packages respectively as they are added to the system.
A quantidade de partições e os seus tamanhos dependem muito de vários fatores que devem ser considerados para escolher a melhor opção para a circunstância. Separar as partições em volumes têm a seguinte vantagens:
- Escolha o sistema de arquivos de maior desempenho para cada partição ou volume.
- O sistema todo não ficará sem espaço se uma aplicação problemática encher todo o espaço de uma partição ou volume.
- Se necessário, a checagem do sistema de arquivos fica com o tempo reduzido, pois várias checagens podem ser feitas em paralelo (embora essa vantagem é mais percebida com múltiplos discos do que com múltiplas partições).
- A segurança pode ser aumentada montando algumas partições ou volumes como somente leitura,
nosuid
(bits setuid são ignorados),noexec
(bits de execução são ignorados), etc.
Contudo, múltiplas partições têm algumas desvantagens:
Há também o limite de 15 partições para SCSI e SATA, a menos que sejam utilizadas etiquetas GPT.
Installations that intend to use systemd as the service and init system must have the /usr directory available at boot, either as part of the root filesystem or mounted via an initramfs.
E o espaço de swap?
RAM size | Suspend support? | Hibernation support? |
---|---|---|
2 GB or less | 2 * RAM | 3 * RAM |
2 to 8 GB | RAM amount | 2 * RAM |
8 to 64 GB | 8 GB minimum, 16 maximum | 1.5 * RAM |
64 GB or greater | 8 GB minimum | Hibernation not recommended! Hibernation is not recommended for systems with very large amounts of memory. While possible, the entire contents of memory must be written to disk in order to successfully hibernate. Writing tens of gigabytes (or worse!) out to disk can can take a considerable amount of time, especially when rotational disks are used. It is best to suspend in this scenario. |
Não existe um valor perfeito para o espaço de swap. O propósito da partição de swap é prover armazenamento em disco ao kernel quando a memória interna (RAM) estiver acabando. Um espaço de swap permite ao kernel mover páginas de memória que provavelmente não serão necessárias tão logo para o disco (swap ou page-out), liberando memória na RAM para a tarefa atual. É claro que, se de repente essas páginas forem necessárias, elas serão trazidas de volta para a memória (page-in) o que irá demorar bem mais do que se fossem lidas direto na memória RAM (pois discos são muito lentos comparados com a memória interna).
Se o sistema não for executar aplicações que necessitem de muita memória ou se o sistema tiver uma grande quantidade de memória disponível, então provavelmente ele não vai precisar de muito espaço de swap. Porém, o espaço de swap é também usado para armazenar a memória inteira no caso de hibernação. Se o sistema for precisar de hibernação, então um espaço de swap maior será necessário, pelo menos do tamanho da memória RAM instalada no sistema.
Usando o fdisk
Máquinas SGI: Criando rótulo de disco SGI
Todos os discos em um sistema SGI requerem um rótulo de disco ("disk label") onde são armazenadas informações sobre as partições de disco. Ao se criar um novo rótulo de disco SGI serão criadas duas partições especiais no disco:
- Cabeçalho de volume SGI (9ª partição): Esta partição é importante. É nela que o gerenciador de boot ficará gravado e, em alguns casos, irá conter também a imagem dos kernels.
- Volume SGI (11ª partição): Esta partição é similar em propósito a terceira partição do rótulo de disco Sun "disco inteiro". Esta partição cobre o disco todo e deve ser mantida intocada. Ela não serve a nenhum propósito especial que não seja ajudar a PROM de alguma forma não documentada (ou ela é usada pelo IRIX de alguma maneira).
O cabeçalho de volume SGI deve iniciar no cilindro 0 ou o sistema não será capaz de inicializar pelo disco.
Abaixo é mostrada um trecho de uma sessão com o fdisk. Leia-a e ajuste-a às suas necessidades pessoais...
root #
fdisk /dev/sda
Alterne para o modo expert:
Command (m for help):
x
Usando a tecla m o menu completo de opções é mostrado:
Expert command (m for help):
m
Command action b move beginning of data in a partition c change number of cylinders d print the raw data in the partition table e list extended partitions f fix partition order g create an IRIX (SGI) partition table h change number of heads m print this menu p print the partition table q quit without saving changes r return to main menu s change number of sectors/track v verify the partition table w write table to disk and exit
Crie um rótulo de disco SGI:
Expert command (m for help):
g
Building a new SGI disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content will be irrecoverably lost.
Retorne ao menu principal:
Expert command (m for help):
r
Dê uma olhada no layout de partições atual:
Command (m for help):
p
Disk /dev/sda (SGI disk label): 64 heads, 32 sectors, 17482 cylinders Units = cylinders of 2048 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 9: /dev/sda1 0 4 10240 0 SGI volhdr 11: /dev/sda2 0 17481 35803136 6 SGI volume ----- Bootinfo ----- Bootfile: /unix ----- Directory Entries -----
Se o disco já possui um rótulo de disco SGI o fdisk não permitirá a criação de um novo rótulo. Há duas maneiras de se contornar isso. Uma é criar um rótulo de disco SUN ou MS-DOS, gravar as alterações no disco, e reiniciar o fdisk. A segunda é sobrescrever a tabela de partições com dados nulos com o seguinte comando:
dd if=/dev/zero of=/dev/sda bs=512 count=1
Redimensionando o cabeçalho de volume SGI
Este passo é geralmente necessário devido a um bug no fdisk. Por alguma razão, o cabeçalho do volume não é criado corretamente, resultando que ele inicia e termina no cilindro 0, o que impede que sejam criadas múltiplas partições. Para contornar esse problema, continue lendo.
Agora que o rótulo de disco SGI foi criado, as partições podem ser definidas. No exemplo acima duas partições já foram definidas. Essas são as partições especiais mencionadas anteriormente e não devem ser alteradas. Entretanto, para a instalação do Gentoo, precisaremos carregar um gerenciador de boot e, possivelmente, múltiplas imagens do kernel (dependendo do tipo do sistema) diretamente no cabeçalho de volume. O cabeçalho de volume em si pode armazenar até oito imagens de qualquer tamanho, cada uma podendo ter um nome de até oito caracteres.
O processo de aumentar o cabeçalho de volume não é exatamente simples; há alguns truques para fazê-lo. Não se pode simplesmente apagar e recriar o cabeçalho de volume devido ao comportamento estranho do fdisk. No exemplo mostrado abaixo, criaremos um cabeçalho de volume de 50MB em conjunto com uma partição /boot/ de 50MB. O layout real pode variar, pois este apenas para propósitos ilustrativos.
Crie uma nova partição:
Command (m for help):
n
Partition number (1-16): 1 First cylinder (5-8682, default 5): 51 Last cylinder (51-8682, default 8682): 101
Notou como o fdisk só permite a partição 1 ser recriada iniciando pelo menos no cilindro 5? Se tentássemos apagar e recriar o volume de cabeçalho SGI desse modo, teríamos o mesmo problema já encontrado. No nosso exemplo queremos que a partição /boot/ seja de 50MB, então a iniciamos no cilindro 51 (o cabeçalho de volume precisa iniciar no cilindro 0, lembra-se?) e a fazemos terminar no cilindro 101 o que dá aproximadamente 50M (+/- 1-5MB).
Apague a partição:
Command (m for help):
d
Partition number (1-16): 9
Agora recrie-a:
Command (m for help):
n
Partition number (1-16): 9 First cylinder (0-50, default 0): 0 Last cylinder (0-50, default 50): 50
Em caso de dúvidas no uso do fdisk, veja adiante nas instruções de particionamento em máquinas Cobalt. Os conceitos são exatamente os mesmos, apenas lembre-se de não alterar as partições de cabeçalho de volume e a do disco inteiro.
Uma vez feito isso, crie o restante de suas partições conforme necessário. Depois de todas as partições criadas, certifique-se de alterar o ID da partição de swap para 82, que é Linux Swap. Por default ela é 83, Linux Native.
Particionando drives Cobalt
Em máquinas Cobalt a BOOTROM espera encontrar um MBR MS-DOS, então particionar o drive é relativamente simples. Na verdade, isso é feito da mesma forma que para uma máquina x86. Entretanto, existem algumas diferenças que precisamos conhecer.
- O firmware da Cobalt espera que /dev/sda1 seja uma partição Linux formatada com EXT2 Revisão 0. Partições com EXT2 Revisão 1 não funcionarão! (A BOOTROM Cobalt entende apenas o EXT2r0)
- Essa partição deve conter uma imagem ELF compactada com gzip (vmlinux.gz) na raiz da partição, que é carregada como kernel
Por essa razão, é recomendado criar uma partição /boot/ de ~20MB formatada com EXT2r0 na qual serão instalados o CoLo e os kernels. Isso permite ao usuário usar um sistema de arquivos moderno (EXT3 ou reiserfs) no sistema de arquivos raiz.
No exemplo, assume-se que /dev/sda1 é criado para mais tarde ser montada como a partição /boot/. Para usar como raiz (/), tenha em mente as expectativas da PROM.
Então, continuando... Para criar as partições digite fdisk /dev/sda no prompt. Os principais comandos para se saber são estes:
'"`UNIQ--pre-00000029-QINU`"'
root #
fdisk /dev/sda
The number of cylinders for this disk is set to 19870. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1 - software that runs at boot time (e.g., old versions of LILO) 2 - booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK)
Comece apagando as partições existentes:
Command (m for help):
o
Building a new DOS disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. The number of cylinders for this disk is set to 19870. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1 - software that runs at boot time (e.g., old versions of LILO) 2 - booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Agora verifique se a tabela de partições está vazia usando o comando p:
Command (m for help):
p
Disk /dev/sda: 10.2 GB, 10254827520 bytes 16 heads, 63 sectors/track, 19870 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System
Crie a partição /boot:
Command (m for help):
n
Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-19870, default 1): Last cylinder or +size or +sizeM or +sizeK (1-19870, default 19870): +20M
Ao mostrar as partições, note a partição recém-criada:
Command (m for help):
p
Disk /dev/sda: 10.2 GB, 10254827520 bytes 16 heads, 63 sectors/track, 19870 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System /dev/sda1 1 40 20128+ 83 Linux
Agora criamos uma partição estendida cobrindo o restante do disco. Nessa partição estendida criaremos o resto (partições lógicas):
Command (m for help):
n
Command action e extended p primary partition (1-4) e Partition number (1-4): 2 First cylinder (41-19870, default 41): Using default value 41 Last cylinder or +size or +sizeM or +sizeK (41-19870, default 19870): Using default value 19870
Criamos agora as partições /, /usr, /var etc.
Command (m for help):
n
Command action l logical (5 or over) p primary partition (1-4) l First cylinder (41-19870, default 41):<Press ENTER> Using default value 41 Last cylinder or +size or +sizeM or +sizeK (41-19870, default 19870): +500M
Repita o processo conforme necessário.
Por fim, o espaço de swap. É recomendado ter pelo menos 250MB de swap.
Command (m for help):
n
Command action l logical (5 or over) p primary partition (1-4) l First cylinder (17294-19870, default 17294): <Press ENTER> Using default value 17294 Last cylinder or +size or +sizeM or +sizeK (1011-19870, default 19870): <Press ENTER> Using default value 19870
Ao se checar a tabela de partições tudo deve estar pronto, exceto por uma coisa.
Command (m for help):
p
Disk /dev/sda: 10.2 GB, 10254827520 bytes 16 heads, 63 sectors/track, 19870 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks ID System /dev/sda1 1 21 10552+ 83 Linux /dev/sda2 22 19870 10003896 5 Extended /dev/sda5 22 1037 512032+ 83 Linux /dev/sda6 1038 5101 2048224+ 83 Linux /dev/sda7 5102 9165 2048224+ 83 Linux /dev/sda8 9166 13229 2048224+ 83 Linux /dev/sda9 13230 17293 2048224+ 83 Linux /dev/sda10 17294 19870 1298776+ 83 Linux
Notou que a partição 10, a partição de swap, ainda é do tipo 83? Troquemos para o tipo correto:
Command (m for help):
t
Partition number (1-10): 10 Hex code (type L to list codes): 82 Changed system type of partition 10 to 82 (Linux swap)
Agora cheque:
Command (m for help):
p
Disk /dev/sda: 10.2 GB, 10254827520 bytes 16 heads, 63 sectors/track, 19870 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks ID System /dev/sda1 1 21 10552+ 83 Linux /dev/sda2 22 19870 10003896 5 Extended /dev/sda5 22 1037 512032+ 83 Linux /dev/sda6 1038 5101 2048224+ 83 Linux /dev/sda7 5102 9165 2048224+ 83 Linux /dev/sda8 9166 13229 2048224+ 83 Linux /dev/sda9 13230 17293 2048224+ 83 Linux /dev/sda10 17294 19870 1298776+ 82 Linux Swap
Gravamos a tabela de partições:
Command (m for help):
w
The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks.
Criando sistemas de arquivos
When using SSD or NVMe drive, it is wise to check for firmware upgrades. Some Intel SSDs in particular (600p and 6000p) require a firmware upgrade for possible data corruption induced by XFS I/O usage patterns. The problem is at the firmware level and not any fault of the XFS filesystem. The smartctl utility can help check the device model and firmware version.
Introdução
Agora que as partições foram corretamente criadas, é hora de criar um sistema de arquivos nelas. Na próxima seção os diversos sistemas de arquivos suportados pelo Linux são descritos. Leitores que já souberem qual sistema de arquivos irão usar podem continuar em Criando um sistema de arquivos em uma partição.
Sistemas de arquivos
Linux suporta dezenas de sistemas de arquivos. Alguns deles são só aconselháveis usar para fins específicos. Alguns são considerados mais estáveis na arquitetura mips - é recomendado se informar sobre os sistemas de arquivos e o estado do suporte de cada um antes de selecionar algum mais experimental para partições importantes. Ext4 é o sistema de arquivo recomendado para todos os propósitos e para todas as plataformas. Abaixo está uma lista não exaustiva
- btrfs
- Um sistema de arquivos de próxima geração que provê vários recursos avançados como instantâneos (snapshots), autocorreção através de checksums, compressão transparente, subvolumes e RAID integrado. Kernels com versão anterior à 5.4.y não garantem segurança ao serem utilizados junto com btrfs em produção porque as correções de sérios problemas só estão presentes em versões mais recentes do branch LTS do kernel. Corrupção de sistema de arquivos são comuns em branches mais antigas do kernel, em qualquer outra versão anterior à 4.4.y é especialmente inseguro e propenso a corrupção. Corrupção de sistemas de arquivo são mais comuns em kernels mais antigos (anteriores à 5.4.y) quando a compressão de arquivos está habilitada. Funcionalidades como RAID 5/6 e quota groups são inseguros em todas as versões do btrfs. Além disso, o btrfs pode falhar contra intuitivamente nas operações de sistema de arquivos retornando ENOSPC quando o comando df reporta espaço livre devido a uma fragmentação interna (espaço livre fixado pelos chunks de DATA + SYSTEM, mas necessário em chunks de METADATA). Além disso, desde uma única referência de 4K até uma extensão de 128M dentro de um btrfs podem causar espaço livre indisponível para alocação. Isso também pode fazer com que o btrfs retorne ENOSPC quando o espaço livre é informado pelo comando df. Instalando o pacote sys-fs/btrfsmaintenance e configurando um script para executar periodicamente pode ajudar a reduzir a possibilidade do erro ENOSPC por rebalancear o btrfs, mas isso não elimina o risco de ENOSPC acontecer quando há espaço livre. Algumas workloads talvez nunca irão se deparar com o erro ENOSPC enquanto outras talvez irão. Se o risco de ENOSPC acontecer em produção for inaceitável, você deve usar algo diferente. Se estiver usando btrfs, certifique-se de evitar configurações conhecidas por terem problemas. Com exceção do ENOSPC, informações sobre os problemas presentes no btrfs nas branches mais recentes do kernel estão disponíveis em btrfs wiki status page.
- ext4
- Inicialmente criado como uma derivação do ext3, o ext4 traz novos recursos, melhorias de desempenho e remoção de limites de tamanhos com mudanças moderadas no formato em disco. Ele pode cobrir volumes de até 1 EB com limite de tamanho de arquivo de 16TB. Em vez da alocação em bloco de mapa de bits clássico do ext2/3 o ext4 usa extensões, o que melhora o desempenho com arquivos grandes e reduz a fragmentação. O ext4 também provê algoritmos de alocação de blocos mais sofisticados (alocação atrasada e alocação múltipla de blocos), dando ao driver do sistema de arquivos mais formas de otimizar o layout dos dados no disco. O ext4 é o sistema de arquivos recomendado para propósitos gerais e plataformas em geral.
- f2fs
- O Sistema de Arquivos "Amigável a Flash" (Flash-Friendly File System) foi originalmente criado pela Samsung para uso com memória flash NAND. Ainda hoje (segundo trimestre de 2016), esse sistema de arquivos é considerado imaturo, mas é uma escolha decente quando o Gentoo estiver sendo instalado em cartões microSD, pendrives ou outro tipo de dispositivos baseados em flash.
- JFS
- Sistema de arquivos com journaling de alto desempenho da IBM. O JFS é um sistema de arquivos baseado em árvore B+ confiável e rápido, com bom desempenho em várias situações.
- XFS
- Um sistema de arquivos com metadados de journaling que vem com um robusto conjunto de recursos e é otimizado para escalabilidade. O XFS parece ser menos tolerante a vários problemas de hardware, mas foi continuamente atualizado incluindo funcionalidades modernas.
- VFAT
- Também conhecido como FAT32, é suportado pelo Linux, mas não tem suporte para configurações de permissões padrão UNIX. É mais utilizado para interoperabilidade/intercâmbio com outros sistemas operacionais (como Windows ou macOS) mas é também uma necessidade para alguns sistemas de firmware (como o UEFI). Usuários de sistemas UEFI vão precisar de uma EFI System Partition formatada em VFAT para inicializar o sistema.
- NTFS
- Este sistema de arquivos com "Nova Tecnologia" ("New Technology Filesystem") é o principal sistema de arquivos do Microsoft Windows desde o Windows NT 3.1. Assim como o vfat, ele não armazena permissões ou atributos estendidos necessários para correto funcionamento de um BSD ou Linux, por isso não deve ser usado como sistema de arquivos na maioria dos casos. Deve ser usado apenas para interoperabilidade/intercâmbio com sistemas Microsoft Windows (note a ênfase no apenas).
More extensive information on filesystems can be found in the community maintained Filesystem article.
Criando um sistema de arquivos em uma partição
Please make sure to emerge the relevant user space utilities package for the chosen filesystem before rebooting. There will be a reminder to do so near the end of the installation process.
Para criar um sistema de arquivos em uma partição ou volume, há utilitários disponíveis para o usuário para cada possível sistema de arquivos. Clique no nome do sistema de arquivo na tabela abaixo para informações adicionais para cada sistema de arquivo:
Sistema de arquivo | Comando para criação | Disponível no CD mínimo? | Pacote |
---|---|---|---|
btrfs | mkfs.btrfs | Sim | sys-fs/btrfs-progs |
ext4 | mkfs.ext4 | Sim | sys-fs/e2fsprogs |
f2fs | mkfs.f2fs | Sim | sys-fs/f2fs-tools |
jfs | mkfs.jfs | Sim | sys-fs/jfsutils |
reiserfs | mkfs.reiserfs | Sim | sys-fs/reiserfsprogs |
xfs | mkfs.xfs | Sim | sys-fs/xfsprogs |
vfat | mkfs.vfat | Sim | sys-fs/dosfstools |
NTFS | mkfs.ntfs | Sim | sys-fs/ntfs3g |
The handbook recommends new partitions as part of the installation process, but it is important to note running any mkfs command will erase any data contained within the partition. When necessary, ensure any data that exists within is appropriately backed up before creating a few filesystem.
Por exemplo, para ter a partição de sistema EFI (/dev/sda1) em FAT32 e a partição root (/dev/sda5) em ext4 como usado no exemplo de estrutura de partições, o seguintes comandos seriam usados:
root #
mkfs.ext4 /dev/sda5
EFI system partition filesystem
The EFI system partition (/dev/sda1) must be formatted as FAT32:
root #
mkfs.vfat -F 32 /dev/sda1
Legacy BIOS boot partition filesystem
Systems booting via legacy BIOS with a MBR/DOS disklabel can use any filesystem format supported by the bootloader.
For example, to format with XFS:
root #
mkfs.xfs /dev/sda1
Small ext4 partitions
Se usar o ext4 em uma partição pequena (menor que 8GB), então o sistema de arquivos deve ser criado com opções adequadas para reservar inodes suficientes. Isso pode ser resolvido usando um dos comandos a seguir, respectivamente:
root #
mkfs.ext4 -T small /dev/<dispositivo>
Isso normalmente irá quadruplicar o número de inodes de um dado sistema de arquivos já que o número de "bytes por inode" é reduzido de um para cada 16kB para um para cada 4kB.
Ativando a partição de swap
mkswap é o comando que é utilizado para inicializar as partições de swap:
root #
mkswap /dev/sda10
Para ativar a partição de swap, use swapon:
root #
swapon /dev/sda10
This 'activation' step is only necessary because the swap partition is newly created within the live environment. Once the system has been rebooted, as long as the swap partition is properly defined within fstab or other mount mechanism, swap space will activate automatically.
Montando a partição root
Installations which were previously started, but did not finish the installation process can resume the installation from this point in the handbook. Use this link as the permalink: Resumed installations start here.
Usuários que estiverem usando uma media de instalação não-Gentoo vão precisar criar os pontos de montagem com o comando:
root #
mkdir --parents /mnt/gentoo
root #
mkdir --parents /mnt/gentoo
For EFI installs only, the ESP should be mounted under the root partition location:
root #
mkdir --parents /mnt/gentoo
Continue creating additional mount points necessary for any additional (custom) partition(s) created during previous steps by using the mkdir command.
Agora que as partições foram inicializadas e contém um sistema de arquivos, é hora de montar essas partições. Use o comando mount, mas não se esqueça de criar os diretórios de montagem necessários para cada partição criada. Como exemplo montaremos as partições root e boot:
Mount the root partition:
root #
mount /dev/sda5 /mnt/gentoo
Continue mounting additional (custom) partitions as necessary using the mount command.
Se o /tmp/ precisar ficar em uma partição separada, certifique-se de alterar suas permissões depois de montar:
root #
chmod 1777 /mnt/gentoo/tmp
Mais tarde nestas instruções o sistema de arquivos proc (uma interface virtual com o kernel) e também outros pseudo sistemas de arquivos serão montados. Mas antes nós instalamos os arquivos de instalação do Gentoo.
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-multilib
No-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/gentoo
Ajustando 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 #
date
Mon 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 -g
Systems 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 100313162016
Usuá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/mips/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-mips-<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-mips-<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-mips-<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.asc
For 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 --import
Verify the signature of the tarball and, optionally, associated checksum files:
root #
gpg --verify stage3-mips-<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-owner
Certifique-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).
x
extract, instructs tar to extract the contents of the archive.p
preserve permissions.v
verbose output.f
file, provides tar with the name of the input archive.--xattrs-include='*.*'
Preserves extended attributes in all namespaces stored in the archive.--numeric-owner
Ensure 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.conf
Olhando 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="-mabi=32 -mips4 -pipe -O2"
# 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
Fazendo chroot
Copie as informações de DNS
Resta ainda uma coisa a ser feita antes de entrar no novo ambiente que é copiar sobre a informação de DNS em /etc/resolv.conf. Isso precisa ser feito para assegurar que a rede ainda funciona mesmo após entrar no novo ambiente. O /etc/resolv.conf contém os servidores de nomes da rede.
Para copiar essa informação, é recomendado passar a opção --dereference
do comando cp. Isso assegura que, se o /etc/resolv.conf for um link simbólico, que o arquivo alvo é copiado em vez do link simbólico em si. De outra forma, no novo ambiente o link simbólico apontaria para um arquivo não existente (pois é muito provável que o alvo do link não estará disponível dentro do novo ambiente).
root #
cp --dereference /etc/resolv.conf /mnt/gentoo/etc/
Montando os sistemas de arquivos necessários
Em alguns momentos, a raiz do Linux será alterada para a nova localidade. Para garantir que o novo ambiente funciona corretamente, alguns sistemas de arquivos precisam estar disponíveis lá também.
Os sistemas de arquivos que precisam estar disponíveis são:
- /proc/ que é um pseudo sistema de arquivos (ele se parece com arquivos normais, mas na verdade é gerado "no voo") do qual o kernel do Linux expõe informação para o ambiente
- /sys/ que é um pseudo sistema de arquivos, como o /proc/ o qual era para substituir, sendo mais estruturado que o /proc/
- /dev/ é um sistema de arquivos normal, parcialmente gerenciado pelo gerenciador de dispositivos do Linux (normalmente o
udev
), que contém todos os arquivos de dispositivos
A localidade /proc/ será montada em /mnt/gentoo/proc/ enquanto as outras duas são montadas como "bind". Isso significa que, por exemplo, /mnt/gentoo/sys/ será, na verdade, /sys/ (sendo na verdade apenas um segundo ponto de entrada para o mesmo sistema de arquivos) enquanto /mnt/gentoo/proc/ é uma nova montagem ("instância", para usar o termo) do sistema de arquivo.
If using Gentoo's install media, this step can be replaced with simply: arch-chroot /mnt/gentoo.
root #
mount --types proc /proc /mnt/gentoo/proc
root #
mount --rbind /sys /mnt/gentoo/sys
root #
mount --make-rslave /mnt/gentoo/sys
root #
mount --rbind /dev /mnt/gentoo/dev
root #
mount --make-rslave /mnt/gentoo/dev
root #
mount --bind /run /mnt/gentoo/run
root #
mount --make-slave /mnt/gentoo/run
As operações
--make-rslave
são necessárias para o suporte ao systemd mais tarde na instalação.Se usar uma mídia de instalação que não seja do Gentoo, os passos anteriores podem não ser suficientes. Algumas distribuições criam o /dev/shm como um link simbólico para o /run/shm/ que, após o chroot, torna-se inválido. Fazer do /dev/shm/ uma montagem tmpfs apropriada desde já pode corrigir isso:
root #
test -L /dev/shm && rm /dev/shm && mkdir /dev/shm
root #
mount --types tmpfs --options nosuid,nodev,noexec shm /dev/shm
Assegure-se também de usar o modo 1777:
root #
chmod 1777 /dev/shm
Entrando no novo ambiente
Agora que todas as partições estão inicializadas e o ambiente base está instalado, é hora de entrar no novo ambiente de instalação fazendo chroot nele. Isso significa que a sessão irá alterar sua "raiz" (o diretório mais alto que pode ser acessado) do ambiente atual de instalação (CD de instalação ou outra mídia) para o sistema de instalação (as partições inicializadas). Por isso o nome "change root" (trocar a "raiz") ou "chroot".
O chroot é feito em três passos:
- A localização raiz é trocada de / (na mídia de instalação) para /mnt/gentoo/ (nas partições) usando o comando chroot
- Algumas configurações (aquelas em /etc/profile) são carregadas na memória usando o comando source
- O sinal de pronto é trocado para nos ajudar a lembrar que aquela sessão está dentro do ambiente chroot
root #
chroot /mnt/gentoo /bin/bash
root #
source /etc/profile
root #
export PS1="(chroot) ${PS1}"
A partir deste ponto, todas as ações feitas afetam imediatamente o novo ambiente de instalação do Gentoo Linux. É claro que a instalação ainda está longe de ser concluída, sendo por isso que ainda temos algumas seções restantes!
Se a instalação do Gentoo for interrompida a partir deste ponto, deve ser possível 'retomar' a instalação neste ponto. Não há necessidade de reparticionar os discos novamente! Apenas monte a partição root e execute os passos acima iniciando em Copie as informações de DNS para reentrar no ambiente funcional. Isso também é útil para corrigir problemas com o gerenciador de boot. Maiores informações podem ser encontradas no artigo chroot.
Preparing for a bootloader
Now that the new environment has been entered, it is necessary to prepare the new environment for the bootloader. It will be important to have the correct partition mounted when it is time to install the bootloader.
UEFI systems
For UEFI systems, was formatted with the FAT32 filesystem and will be used as the EFI System Partition (ESP). Create a new directory (if not yet created), and then mount ESP there:
root #
mkdir
root #
mount
DOS/Legacy BIOS systems
For DOS/Legacy BIOS systems, the bootloader will be installed into the /boot directory, therefore mount as follows:
root #
mount /dev/sda1 /boot
Configurando o Portage
Instalando um instantâneo do repositório ebuild da web
O próximo passo é instalar um instantâneo do repositório principal do ebuild. O instantâneo contém uma coleção de arquivos que informa ao Portage sobre quais softwares estão disponíveis para instalação, quais perfis o administrador do sistema pode selecionar, ítens de notícias específicas de um pacote ou perfil etc.
O uso do comando emerge-webrsync é recomendado para os usuários que estão atrás de firewalls restritivos (porque ele usa os protocolos HTTP/FTP para baixar o instantâneo) e economiza banda de rede. Leitores que não tiverem restrições de rede ou de banda podem tranquilamente pular para a próxima seção.
Isso irá baixar o último instantâneo (que é liberado diariamente) de um dos espelhos do Gentoo e instalá-lo no sistema:
root #
emerge-webrsync
Durante essa operação, o emerge-webrsync pode reclamar que o diretório /var/db/repos/gentoo/ não existe. Isso já é esperado e não é motivo para preocupação - a ferramenta irá criar o diretório.
A partir deste ponto, o Portage pode avisar que sejam executadas algumas atualizações recomendadas. Isso é porque alguns pacotes do sistema instalados através do arquivo stage podem ter novas versões disponíveis; o Portage fica sabendo dos novos pacotes através do instantâneo do repositório. As atualizações de pacotes podem ser ignoradas de forma segura por enquanto; as atualizações podem ser postergadas até que a instalação do Gentoo estiver finalizada.
Opcional: Selecionando espelhos
Para baixar o código fonte rapidamente é recomendado selecionar um espelho rápido. O portage procura no arquivo make.conf pela variável GENTOO_MIRRORS e usa os espelhos configurados lá. É possível navegar pela lista de espelhos do Gentoo e procurar um espelho (ou espelhos) que está perto da sua localização física (pois esses frequentemente são os mais rápidos). Entretanto, nós fornecemos uma boa ferramenta chamada mirrorselect que provê ao usuário uma boa interface para selecionar os espelhos necessários. Simplesmente navegue até os espelhos escolhidos e tecle Espaço para selecionar um ou mais espelhos.
A tool called mirrorselect provides a pretty text interface to more quickly query and select suitable mirrors. Just navigate to the mirrors of choice and press Spacebar to select one or more mirrors.
root #
mirrorselect -i -o >> /mnt/gentoo/etc/portage/make.conf
Alternatively, a list of active mirrors are available online.
Opcional: Atualizando o repositório ebuild
É possível atualizar o repositório ebuild do Gentoo para a última versão. O comando emerge-webrsync anterior instalou um instantâneo do Portage bem recente (normalmente tão recente quanto 24 horas) de modo que este passo é totalmente opcional.
Supondo que há necessidade da última atualização dos pacotes (menos de 1 hora), use emerge --sync. Esse comando irá usar o protocolo rsync para atualizar o repositório ebuild do Gentoo (que foi baixada anteriormente através do emerge-webrsync) ao seu estado mais recente.
root #
emerge --sync
Em terminais lentos, tais como alguns "framebuffers" ou consoles seriais, é recomendado usar a opção --quiet
para agilizar o processo:
root #
emerge --sync --quiet
Lendo itens de notícias
Quando o repositório ebuild do Gentoo é sincronizada com o sistema, o Portage pode mostrar ao usuário mensagens similares a seguinte:
* IMPORTANT: 2 news items need reading for repository 'gentoo'.
* Use eselect news to read news items.
Ítens de notícias foram criados para prover um meio de comunicação para enviar mensagens aos usuários através da árvore do portage. Para gerenciá-las, use eselect news. A aplicação eselect é uma aplicação do Gentoo que provê uma interface de gerenciamento comum voltada para alterações e operações. Nesse caso, o eselect é acionado para usar seu módulo news
.
Para o módulo news
, três operações são mais utilizadas:
- Com
list
, é mostrada uma lista dos itens de notícias disponíveis - Com
read
, os itens de notícias podem ser lidos - Com
purge
, itens de notícias podem ser removidos depois de lidos e não forem ser mais relidos
root #
eselect news list
root #
eselect news read
Mais informações sobre o leitor de notícias estão disponíveis através de sua página de manual:
root #
man news.eselect
Escolhendo o perfil correto
Desktop profiles are not exclusively for desktop environments. They are also suitable for minimal window managers like i3 or sway.
Um perfil (profile) é uma peça fundamental para qualquer sistema Gentoo. Não apenas ele especifica valores padrões para o USE, CFLAGS e outras variáveis importantes, ele também trava o sistema em um dado conjunto de versões de pacotes. Essas configurações são mantidas pelos desenvolvedores do Portage do Gentoo.
Você pode ver qual perfil o sistema está usando com o eselect, agora usando com o módulo profile
:
root #
eselect profile list
Available profile symlink targets: [1] default/linux/mips/23.0 * [2] default/linux/mips/23.0/desktop [3] default/linux/mips/23.0/desktop/gnome [4] default/linux/mips/23.0/desktop/kde
A saída do comando é apenas um exemplo e evolui com o tempo.
Como pode ser visto, há também subperfis de desktops disponíveis para algumas arquiteturas.
Atualizações de perfis não devem ser empreendidas levianamente. Ao selecionar o perfil inicial, certifique-se de usar perfil correspondente a mesma versão que a inicialmente usado pelo stage3 (por ex. 17.0). Cada nova versão de perfil é anunciada através de um novo item de notícia contendo instruções para migração. Tenha certeza de ler e seguir as instruções antes de mudar para um novo perfil.
Depois de visualizar os perfis disponíveis para a arquitetura mips, os usuários podem selecionar um perfil diferente para o sistema:
root #
eselect profile set 2
O subperfil
developer
(desenvolvedor) é específico para o desenvolvimento do Gentoo Linux e não é destinado para uso por usuários casuais.Optional: Adding a binary package host
Since December 2023, Gentoo's Release Engineering team has offered an official binary package host (colloquially shorted to just "binhost") for use by the general community to retrieve and install binary packages (binpkgs).[1]
Adding a binary package host allows Portage to install cryptographically signed, compiled packages. In many cases, adding a binary package host will greatly decrease the mean time to package installation and adds much benefit when running Gentoo on older, slower, or low power systems.
Repository configuration
The repository configuration for a binhost is found in Portage's /etc/portage/binrepos.conf/ directory, which functions similarly to the configuration mentioned in the Gentoo ebuild repository section.
When defining a binary host, there are two important aspects to consider:
- The architecture and profile targets within the
sync-uri
value do matter and should align to the respective computer architecture (mips in this case) and system profile selected in the Choosing the right profile section. - Selecting a fast, geographically close mirror will generally shorten retrieval time. Review the mirrorselect tool mentioned in the Optional: Selecting mirrors section or review the online list of mirrors where URL values can be discovered.
[binhost]
priority = 9999
sync-uri = https://distfiles.gentoo.org/releases/<arch>/binpackages/<profile>/x86-64/
Installing binary packages
Portage will compile packages from code source by default. It can be instructed to use binary packages in the following ways:
- The
--getbinpkg
option can be passed when invoking the emerge command. This method of for binary package installation is useful to install only a particular binary package. - Changing the system's default via Portage's FEATURES variable, which is exposed through the /etc/portage/make.conf file. Applying this configuration change will cause Portage to query the binary package host for the package(s) to be requested and fall back to compiling locally when no results are found.
For example, to have Portage always install available binary packages:
# Appending getbinpkg to the list of values within the FEATURES variable
FEATURES="${FEATURES} getbinpkg"
# Require signatures
FEATURES="${FEATURES} binpkg-request-signature"
Please also run getuto for Portage to set up the necessary keyring for verification:
root #
getuto
Additional Portage features will be discussed in the the next chapter of the handbook.
Configurando as variáveis USE
A USE é uma das mais poderosas variáveis que o Gentoo provê aos seus usuários. Muitos programas podem ser compilados com ou sem suporte para certos itens. Por exemplo, alguns programas podem ser compilados com suporte ao GTK+ ou ao QT. Outros podem ser compilados com ou sem suporte ao SSL. Alguns programas podem até ser compilados com suporte a framebuffer (svgalib) em vez de suporte ao X11 (X-server).
A maioria das distribuições compilam seus pacotes com o máximo possível de suporte, aumentando o tamanho dos programas e o tempo de carga, sem contar o enorme número de dependências. Com o Gentoo, os usuários podem definir com quais opções um pacote deve ser compilado. É aqui que a USE entra em cena.
Na variável USE os usuários definem palavras-chave que serão mapeadas em opções de compilação. Por exemplo, ssl
irá compilar suporte ao SSL em programas que o suportam. -X
irá remover suporte ao servidor X (note o sinal de menos na frente). gnome gtk -kde -qt5
irá compilar programas com suporte ao GNOME (e GTK+) mas não ao KDE (e Qt), fazendo o sistema ajustado para o GNOME (se a arquitetura o suportar).
Os padrões para as configurações USE estão armazenados nos arquivos make.defaults do perfil do Gentoo usado pelo sistema. O Gentoo usa um (complexo) sistema de herança para seus perfis, no qual ainda não nos aprofundamos neste estágio. O modo mais fácil de checar as configurações USE ativas é executar emerge --info e selecionar a linha que começa com USE:
root #
emerge --info | grep ^USE
USE="X acl alsa amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri ..."
O exemplo acima está truncado, a lista real das variáveis USE é muito, muito maior.
Uma descrição completa das flags USE disponíveis pode ser encontrada no sistema em /var/db/repos/gentoo/profiles/use.desc.
root #
less /var/db/repos/gentoo/profiles/use.desc
Dentro do comando less, a rolagem pode ser feita usando as teclas ↑ e ↓, e sair pressionando q.
Como exemplo, mostramos uma configuração USE para um sistema baseado no KDE com suporte a DVD, ALSA e gravação de CD:
root #
nano -w /etc/portage/make.conf
USE="-gtk -gnome qt5 kde dvd alsa cdr"
Quando a USE é definida em /etc/portage/make.conf ela é "adicionada" (ou "removida" se a flag iniciar com o sinal -) da lista padrão. Usuários que quiserem ignorar toda a configuração padrão USE e gerenciá-la completamente por conta devem iniciar a definição USE com -*
:
USE="-* X acl alsa"
Mesmo sendo possível, definir
-*
(como no exemplo acima) é desencorajado pois USE flags default cuidadosamente escolhidas podem ter sido configuradas em alguns ebuild para evitar conflitos e outros erros.CPU_FLAGS_*
Some architectures (including AMD64/X86, ARM, PPC) have a USE_EXPAND variable called CPU_FLAGS_<ARCH>, where <ARCH> is replaced with the relevant system architecture name.
Do not be confused! AMD64 and X86 systems share some common architecture, so the proper variable name for AMD64 systems is CPU_FLAGS_X86.
This is used to configure the build to compile in specific assembly code or other intrinsics, usually hand-written or otherwise extra,
and is not the same as asking the compiler to output optimized code for a certain CPU feature (e.g. -march=
).
Users should set this variable in addition to configuring their COMMON_FLAGS as desired.
A few steps are needed to set this up:
root #
emerge --ask --oneshot app-portage/cpuid2cpuflags
Inspect the output manually if curious:
root #
cpuid2cpuflags
Then copy the output into package.use:
root #
echo "*/* $(cpuid2cpuflags)" > /etc/portage/package.use/00cpu-flags
VIDEO_CARDS
The VIDEO_CARDS USE_EXPAND variable should be configured appropriately depending on the available GPU(s). Setting VIDEO_CARDS is not required for a console only install.
Below is an example of a properly set VIDEO_CARDS variable. Substitute the name of the driver(s) to be used.
VIDEO_CARDS="amdgpu radeonsi"
Details for various GPU(s) can be found at the AMDGPU, Intel, Nouveau (Open Source), or NVIDIA (Proprietary) articles.
Opcional: Configurando a variável ACCEPT_LICENSE
Starting with Gentoo Linux Enhancement Proposal 23 (GLEP 23), a mechanism was created to allow system administrators the ability to "regulate the software they install with regards to licenses... Some want a system free of any software that is not OSI-approved; others are simply curious as to what licenses they are implicitly accepting."[2] With a motivation to have more granular control over the type of software running on a Gentoo system, the ACCEPT_LICENSE variable was born.
O Gentoo vem com um valor predefinido nos perfis, por exemplo:
user $
portageq envvar ACCEPT_LICENSE
@FREE
Os grupos de licenças definidos no repositório Gentoo, gerenciados pelo Projeto de Licenças do , são:
Nome do Grupo | Descrição |
---|---|
@GPL-COMPATIBLE | Licenças compatíveis com a GPL aprovadas pela Fundação Software Livre (FSF - Free Software Foundation) [a_license 1] |
@FSF-APPROVED | Licenças de software livre aprovadas pela FSF (inclui @GPL-COMPATIBLE) |
@OSI-APPROVED | Licenças aprovadas pela Iniciativa do Software Aberto (OSI - Open Source Initiative) [a_license 2] |
@MISC-FREE | Miscelânea de licenças que são provavelmente software livre, isto é, seguem a Definição de Software Livre (Free Software Definition) [a_license 3] mas que não são aprovadas pela FSF ou OSI |
@FREE-SOFTWARE | Combina @FSF-APPROVED, @OSI-APPROVED e @MISC-FREE |
@FSF-APPROVED-OTHER | Licenças aprovadas pela FSF para "documentação livre" e "trabalhos de uso prático além de software e documentação" (incluindo fontes) |
@MISC-FREE-DOCS | Miscelânea de licenças para documentos livres e outros trabalhos (incluindo fontes) que seguem a definição de livre [a_license 4] mas NÃO são listadas em @FSF-APPROVED-OTHER |
@FREE-DOCUMENTS | Combina @FSF-APPROVED-OTHER e @MISC-FREE-DOCS |
@FREE | Combina @FREE-SOFTWARE e @FREE-DOCUMENTS |
@BINARY-REDISTRIBUTABLE | Inclui @FREE e outros softwares livremente distribuíveis de código fechado que não tem um Acordo de Licença para o Usuário Final (EULA - End-User License Agreement) |
@EULA | Acordos de Licença que tentam tirar seus direitos. São mais restritivas do que "todos os direitos reservados" ou requerem aprovação explícita |
Some common license groups include:
Name | Description |
---|---|
@GPL-COMPATIBLE |
GPL compatible licenses approved by the Free Software Foundation [a_license 5] |
@FSF-APPROVED |
Free software licenses approved by the FSF (includes @GPL-COMPATIBLE )
|
@OSI-APPROVED |
Licenses approved by the Open Source Initiative [a_license 6] |
@MISC-FREE |
Misc licenses that are probably free software, i.e. follow the Free Software Definition [a_license 7] but are not approved by either FSF or OSI |
@FREE-SOFTWARE |
Combines @FSF-APPROVED , @OSI-APPROVED , and @MISC-FREE .
|
@FSF-APPROVED-OTHER |
FSF-approved licenses for "free documentation" and "works of practical use besides software and documentation" (including fonts) |
@MISC-FREE-DOCS |
Misc licenses for free documents and other works (including fonts) that follow the free definition [a_license 8] but are NOT listed in @FSF-APPROVED-OTHER .
|
@FREE-DOCUMENTS |
Combines @FSF-APPROVED-OTHER and @MISC-FREE-DOCS .
|
@FREE |
Metaset of all licenses with the freedom to use, share, modify and share modifications. Combines @FREE-SOFTWARE and @FREE-DOCUMENTS .
|
@BINARY-REDISTRIBUTABLE |
Licenses that at least permit free redistribution of the software in binary form. Includes @FREE .
|
@EULA |
License agreements that try to take away your rights. These are more restrictive than "all-rights-reserved" or require explicit approval |
- ↑ https://www.gnu.org/licenses/license-list.html
- ↑ https://www.opensource.org/licenses
- ↑ https://www.gnu.org/philosophy/free-sw.html
- ↑ https://freedomdefined.org/
- ↑ https://www.gnu.org/licenses/license-list.html
- ↑ https://www.opensource.org/licenses
- ↑ https://www.gnu.org/philosophy/free-sw.html
- ↑ https://freedomdefined.org/
Currently set system wide acceptable license values can be viewed via:
user $
portageq envvar ACCEPT_LICENSE
@FREE
As visible in the output, the default value is to only allow software which has been grouped into the @FREE
category to be installed.
Specific licenses or licenses groups for a system can be defined in the following locations:
- System wide within the selected profile - this sets the default value.
- System wide within the /etc/portage/make.conf file. System administrators override the profile's default value within this file.
- Per-package within a /etc/portage/package.license file.
- Per-package within a /etc/portage/package.license/ directory of files.
Isso pode ser customizado para todo o sistema alterando o arquivo /etc/portage/make.conf. O valor default irá aceitar licenças aprovadas explicitamente pela Fundação Software Livre (FSF - Free Software Foundation), pela Iniciativa de de Código Aberto (OSI - Open Source Initiative) ou que seguem a Definição de Software Livre (Free Software Definition):
ACCEPT_LICENSE="-* @FREE"
Configurações por pacote podem ser adicionadas se necessárias ou desejadas, por exemplo:
app-arch/unrar unRAR
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
sys-firmware/intel-microcode intel-ucode
root #
mkdir /etc/portage/package.license
Software license details for an individual Gentoo package are stored within the LICENSE variable of the associated ebuild. One package may have one or many software licenses, therefore it be necessary to specify multiple acceptable licenses for a single package.
app-arch/unrar unRAR
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
sys-firmware/intel-microcode intel-ucode
A variável LICENSE em uma ebuild é apenas uma indicação para os desenvolvedores e usuários do Gentoo. Ela não tem valor legal e não há garantias de que reflita a realidade. Desse modo, não confie cegamente nela, mas cheque o pacote em si cuidadosamente, incluindo todos os arquivos que usar.
Atualizando o conjunto @world
O passo seguinte é necessário de modo ao sistema poder aplicar atualizações ou mudanças de USE flag que apareceram desde que o stage3 foi criado e de qualquer seleção de perfil:
- A profile target different from the stage file has been selected.
- Additional USE flags have been set for installed packages.
Readers who are performing an 'install Gentoo speed run' may safely skip @world set updates until after their system has rebooted into the new Gentoo environment.
Readers who are performing a slow run can have Portage perform updates for package, profile, and/or USE flag changes at the present time:
root #
emerge --ask --verbose --update --deep --newuse @world
Removing obsolete packages
It is important to always depclean after system upgrades to remove obsolete packages. Review the output carefully with emerge --depclean --pretend to see if any of the to-be-cleaned packages should be kept if personally using them. To keep a package which would otherwise be depcleaned, use emerge --noreplace foo.
root #
emerge --ask --pretend --depclean
If happy, then proceed with a real depclean:
root #
emerge --ask --depclean
Se um perfil de ambiente completo de desktop foi selecionado, o tempo necessário para o processo de instalação pode ser bastante longo. Aqueles sem muito tempo para a instalação podem seguir a seguinte 'regra geral': quanto menor o nome do perfil, menos específico o conjunto @world; quanto menos específico o conjunto @world, menos pacotes o sistema irá requerer. Em outras palavras:
- selecionar
default/linux/amd64/13.0
irá requerer bem poucos pacotes para atualizar, enquanto - selecionar
default/linux/amd64/13.0/desktop/gnome/systemd
irá requerer muitos pacotes para a instalação uma vez que o sistema de inicialização será trocado do OpenRC para systemd e o ambiente de trabalho GNOME será instalado.
Fuso horário
This step does not apply to users of the musl libc. Users who do not know what that means should perform this step.
Por favor evite os fusos horários /usr/share/zoneinfo/Etc/GMT* pois seus nomes não correspondem aos fusos esperados. Por exemplo, GMT-8 é na verdade GMT+8.
Selecione o fuso horário para o sistema. Veja os fusos horários disponíveis em /usr/share/zoneinfo/, e então escreva-o no arquivo /etc/timezone.
root #
ls /usr/share/zoneinfo
root #
ls -l /usr/share/zoneinfo/Europe/
total 256 -rw-r--r-- 1 root root 2933 Dec 3 17:19 Amsterdam -rw-r--r-- 1 root root 1742 Dec 3 17:19 Andorra -rw-r--r-- 1 root root 1151 Dec 3 17:19 Astrakhan -rw-r--r-- 1 root root 2262 Dec 3 17:19 Athens -rw-r--r-- 1 root root 3664 Dec 3 17:19 Belfast -rw-r--r-- 1 root root 1920 Dec 3 17:19 Belgrade -rw-r--r-- 1 root root 2298 Dec 3 17:19 Berlin -rw-r--r-- 1 root root 2301 Dec 3 17:19 Bratislava -rw-r--r-- 1 root root 2933 Dec 3 17:19 Brussels ...
Suppose the timezone of choice is Europe/Brussels.
OpenRC
The desired timezone name can be written to /etc/timezone:
root #
echo "Brazil/East" > /etc/timezone
A seguir, reconfigure o pacote sys-libs/timezone-data, o que irá atualizar o arquivo /etc/localtime para nós, baseado no /etc/timezone. O arquivo /etc/localtime é usado pela biblioteca C do sistema para saber em qual fuso horário o sistema está.
root #
emerge --config sys-libs/timezone-data
The /etc/localtime file is used by the system C library to know the timezone the system is in.
systemd
A slightly different approach is employed when using systemd. A symbolic link is generated:
root #
ln -sf ../usr/share/zoneinfo/Europe/Brussels /etc/localtime
Later, when systemd is running, the timezone and related settings can be configured with the timedatectl command.
Configurando locais
This step does not apply to users of the musl libc. Users who do not know what that means should perform this step.
Locale generation
A maioria dos usuários irá querer usar apenas um ou dois locais em seus sistemas.
Locais especificam não apenas a língua que o sistema deve usar para interagir com o usuário, mas também as regras para ordenar strings, mostrar data e hora etc.
Os locais que um sistema deve suportar devem ser entrados em /etc/locale.gen.
root #
nano -w /etc/locale.gen
Os seguintes locais são um exemplo para se obter inglês (Estados Unidos) e alemão (Alemanha) com os correspondentes formatos de caracteres (como o UTF-8).
en_US ISO-8859-1
en_US.UTF-8 UTF-8
de_DE ISO-8859-1
de_DE.UTF-8 UTF-8
Sugerimos fortemente usar pelo menos um local UTF-8 pois algumas aplicações podem requerê-lo.
O próximo passo é executar locale-gen. Isso irá regerar todos os locais especificados no arquivo /etc/locale.gen.
root #
locale-gen
Para verificar que os locais selecionados estão agora disponíveis, execute locale -a.
On systemd installs, localectl can be used, e.g. localectl set-locale ... or localectl list-locales.
Locale selection
Uma vez feito, é agora hora de ajustar a configuração geral de local do sistema. Novamente usamos o eselect para isso, agora com o módulo locale
.
Com o eselect locale list, os alvos disponíveis são mostrados.
root #
eselect locale list
Available targets for the LANG variable: [1] C [2] POSIX [3] en_US [4] en_US.iso88591 [5] en_US.utf8 [6] de_DE [7] de_DE.iso88591 [8] de_DE.iso885915 [9] de_DE.utf8 [ ] (free form)
Com eselect locale set VALOR o local correto pode ser ajustado:
root #
eselect locale set 9
Manualmente, isso pode ser conseguido através do arquivo /etc/env.d/02locale:
LANG="de_DE.UTF-8"
LC_COLLATE="C"
Certifique-se que um local foi configurado, ou o sistema irá mostrar mensagens de aviso e erro durante a construção do kernel e outras implantações de software mais tarde na instalação.
Agora recarregue o ambiente:
root #
env-update && source /etc/profile && export PS1="(chroot) ${PS1}"
Nós fizemos um Guia de localização completo para ajudar o usuário através do processo. Outro artigo interessante é o guia UTF-8 com informações muito específicas para habilitar o UTF-8 no sistema.
References
Opcional: Instalando firmware
Firmware
Linux Firmware
Alguns drivers requerem que firmware adicionais sejam instalados no sistema antes para funcionarem. Isso ocorre normalmente com interfaces de rede, especialmente as interfaces de rede sem fio. Também placas de vídeo modernas de fabricantes como AMD, NVidia e Intel, quando usando drivers open source, frequentemente precisam de arquivos de firmware externos. A maioria dos firmwares estão empacotados em sys-kernel/linux-firmware:
It is recommended to have the sys-kernel/linux-firmware package installed before the initial system reboot in order to have the firmware available in the event that it is necessary:
root #
emerge --ask sys-kernel/linux-firmware
Installing certain firmware packages often requires accepting the associated firmware licenses. If necessary, visit the license handling section of the Handbook for help on accepting licenses.
It is important to note that kernel symbols that are built as modules (M) will load their associated firmware files from the filesystem when they are loaded by the kernel. It is not necessary to include the device's firmware files into the kernel's binary image for symbols loaded as modules.
Microcode
In addition to discrete graphics hardware and network interfaces, CPUs also can require firmware updates. Typically this kind of firmware is referred to as microcode. Newer revisions of microcode are sometimes necessary to patch instability, security concerns, or other miscellaneous bugs in CPU hardware.
Microcode updates for AMD CPUs are distributed within the aforementioned sys-kernel/linux-firmware package. Microcode for Intel CPUs can be found within the sys-firmware/intel-microcode package, which will need to be installed separately. See the Microcode article for more information on how to apply microcode updates.
Kernel configuration and compilation
É chegada a hora de configurar e compilar os fontes do kernel. Há duas formas de se fazer isso:
Ranked from least involved to most involved:
- O kernel é manualmente configurado e compilado, ou
- é usada uma ferramenta chamada
genkernel
para automaticamente compilar e instalar o kernel Linux
O núcleo em torno do qual todas as distribuições são criadas é o kernel Linux. Ele é a camada entre os programas de usuários e o hardware do sistema. O Gentoo provê aos seus usuários diversos possíveis fontes do kernel. Uma listagem completa está disponível na Página de visão geral do kernel.
Kernel installation tasks such as, copying the kernel image to /boot or the EFI System Partition, generating an initramfs and/or Unified Kernel Image, updating bootloader configuration, can be automated with installkernel. Users may wish to configure and install sys-kernel/installkernel before proceeding. See the Kernel installation section below for more more information.
Instalando os fontes
This section is only relevant when using the following genkernel (hybrid) or manual kernel management approach.
The use of sys-kernel/installkernel is not strictly required, but highly recommended. When this package is installed, the kernel installation process will be delegated to installkernel. This allows for installing several different kernel versions side-by-side as well as managing and automating several tasks relating to kernel installation described later in the handbook. Install it now with:
root #
emerge --ask sys-kernel/installkernel
When installing and compiling the kernel for mips-based systems, Gentoo recommends the sys-kernel/mips-sources package.
Choose an appropriate kernel source and install it using emerge:
root #
emerge --ask sys-kernel/mips-sources
Isso irá instalar os fontes do kernel Linux em /usr/src/ no qual um link simbólico chamado linux estará apontando para o fonte do kernel instalado:
It is conventional for a /usr/src/linux symlink to be maintained, such that it refers to whichever sources correspond with the currently running kernel. However, this symbolic link will not be created by default. An easy way to create the symbolic link is to utilize eselect's kernel module.
For further information regarding the purpose of the symlink, and how to manage it, please refer to Kernel/Upgrade.
First, list all installed kernels:
root #
eselect kernel list
Available kernel symlink targets: [1] linux-6.6.21-gentoo
In order to create a symbolic link called linux, use:
root #
eselect kernel set 1
root #
ls -l /usr/src/linux
lrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-6.6.21-gentoo
Padrão: Configuração manual
Introdução
In case it was missed, this section requires the kernel sources to be installed. Be sure to obtain the relevant kernel sources, then return here for the rest of section.
Configurar manualmente um kernel é geralmente visto como o procedimento mais difícil que um usuário Linux pode fazer. Nada mais falso -- depois de configurar algumas vezes o kernel ninguém irá se lembrar que era difícil.
Porém, uma coisa é verdade: é vital conhecer o sistema quando um kernel é configurado manualmente. A maioria das informações pode ser coletada fazendo emerge no sys-apps/pciutils que contém o comando lspci:
root #
emerge --ask sys-apps/pciutils
Dentro do chroot, é seguro ignorar qualquer aviso da pcilib (como pcilib: cannot open /sys/bus/pci/devices) que o lspci possa emitir.
Uma outra fonte de informação do sistema é executar o lsmod para ver quais módulos do kernel o CD de instalação usa pois isso pode dar dicas sobre o que habilitar.
Agora vá para o diretório dos fontes do kernel e execute make menuconfig. Isso irá mostrar uma tela de configuração baseada em menus.
root #
cd /usr/src/linux
root #
make menuconfig
A configuração do kernel do Linux tem muitas, muitas seções. Vamos primeiro mostrar algumas opções que devem ser ativadas (ou senão o Gentoo não irá funcionar, ou não funcionar adequadamente sem alguns ajustes). Existe também o Guia de configuração do kernel do Gentoo no wiki do Gentoo que poderá também ajudar.
Ativando as opções necessárias
When using sys-kernel/gentoo-sources, it is strongly recommend the Gentoo-specific configuration options be enabled. These ensure that a minimum of kernel features required for proper functioning is available:
Gentoo Linux --->
Generic Driver Options --->
[*] Gentoo Linux support
[*] Linux dynamic and persistent device naming (userspace devfs) support
[*] Select options required by Portage features
Support for init systems, system and service managers --->
[*] OpenRC, runit and other script based systems and managers
[*] systemd
Naturally the choice in the last two lines depends on the selected init system (OpenRC vs. systemd). It does not hurt to have support for both init systems enabled.
When using sys-kernel/vanilla-sources, the additional selections for init systems will be unavailable. Enabling support is possible, but goes beyond the scope of the handbook.
Enabling support for typical system components
Certifique-se de que todos os drivers que forem vitais para a inicialização do sistema (tais como controladores SCSI etc) são compilados no kernel e não como módulos, ou senão o sistema não será capaz de inicializar completamente.
Em seguida selecione o tipo exato do processador. É também recomendado habilitar os recursos MCE (se disponíveis) de modo que os usuários possam ser notificados sobre quaisquer problemas de hardware. Em algumas arquiteturas (tais como a x86_64), esses erros não são impressos pelo dmesg, mas em /dev/mcelog. Isso requer o pacote app-admin/mcelog.
Selecione também Maintain a devtmpfs file system to mount at /dev assim os arquivos de dispositivos críticos estarão disponíveis logo durante o processo de inicialização (CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT):
Device Drivers --->
Generic Driver Options --->
[*] Maintain a devtmpfs filesystem to mount at /dev
[ ] Automount devtmpfs at /dev, after the kernel mounted the rootfs
Verifique se o suporte a discos SCSI foi ativado (CONFIG_BLK_DEV_SD):
Device Drivers --->
SCSI device support --->
<*> SCSI disk support
Device Drivers --->
<*> Serial ATA and Parallel ATA drivers (libata) --->
[*] ATA ACPI Support
[*] SATA Port Multiplier support
<*> AHCI SATA support (ahci)
[*] ATA BMDMA support
[*] ATA SFF support (for legacy IDE and PATA)
<*> Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support (ata_piix)
Verify basic NVMe support has been enabled:
Device Drivers --->
<*> NVM Express block device
Device Drivers --->
NVME Support --->
<*> NVM Express block device
It does not hurt to enable the following additional NVMe support:
[*] NVMe multipath support
[*] NVMe hardware monitoring
<M> NVM Express over Fabrics FC host driver
<M> NVM Express over Fabrics TCP host driver
<M> NVMe Target support
[*] NVMe Target Passthrough support
<M> NVMe loopback device support
<M> NVMe over Fabrics FC target driver
< > NVMe over Fabrics FC Transport Loopback Test driver (NEW)
<M> NVMe over Fabrics TCP target support
Vá agora para File Systems (Sistemas de Arquivos) e selecione suporte para os sistemas de arquivos que você usa. Não compile o sistema de arquivo que é usado como sistema de arquivo raiz como módulo, ou senão o sistema Gentoo não será capaz de montar a partição. Selecione também "Virtual memory" (Memória virtual) e "/proc file system" (sistema de arquivo /proc). Selecione uma ou mais das seguintes opções segundo as necessidades do sistema: (CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_FS, CONFIG_MSDOS_FS, CONFIG_VFAT_FS, CONFIG_PROC_FS, and CONFIG_TMPFS):
File systems --->
<*> Second extended fs support
<*> The Extended 3 (ext3) filesystem
<*> The Extended 4 (ext4) filesystem
<*> Reiserfs support
<*> JFS filesystem support
<*> XFS filesystem support
<*> Btrfs filesystem support
DOS/FAT/NT Filesystems --->
<*> MSDOS fs support
<*> VFAT (Windows-95) fs support
Pseudo Filesystems --->
[*] /proc file system support
[*] Tmpfs virtual memory file system support (former shm fs)
Se for usado PPPoE para conectar à Internet, ou um modem com discagem foi usado, então habilite as seguintes opções (CONFIG_PPP, CONFIG_PPP_ASYNC, e CONFIG_PPP_SYNC_TTY):
Device Drivers --->
Network device support --->
<*> PPP (point-to-point protocol) support
<*> PPP support for async serial ports
<*> PPP support for sync tty ports
As duas opções de compactação não vão atrapalhar mas definitivamente não são necessárias, assim como a opção de PPP sobre Ethernet (PPP over Ethernet), que pode apenas ser usada pelo ppp quando configurado para usar PPPoE em modo kernel.
Não se esqueça de incluir suporte no kernel para as placas de rede (ethernet ou sem fio).
A maioria dos sistemas tem múltiplos núcleos à disposição, então é importante ativar a opção "Symmetric multi-processing support" (suporte a multi-processamento simétrico) (CONFIG_SMP):
Processor type and features --->
[*] Symmetric multi-processing support
Em sistemas com vários núcleos, cada núcleo conta como um processador.
Se forem usados dispositivos de entrada USB (como teclado ou mouse) ou outros dispositivos USB, não se esqueça de habilitá-los também (CONFIG_HID_GENERIC and CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD):
Device Drivers --->
HID support --->
-*- HID bus support
<*> Generic HID driver
[*] Battery level reporting for HID devices
USB HID support --->
<*> USB HID transport layer
[*] USB support --->
<*> xHCI HCD (USB 3.0) support
<*> EHCI HCD (USB 2.0) support
<*> OHCI HCD (USB 1.1) support
Optional: Signed kernel modules
To automatically sign the kernel modules enable CONFIG_MODULE_SIG_ALL:
[*] Enable loadable module support
-*- Module signature verification
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
Optionally change the hash algorithm if desired.
To enforce that all modules are signed with a valid signature, enable CONFIG_MODULE_SIG_FORCE as well:
[*] Enable loadable module support
-*- Module signature verification
[*] Require modules to be validly signed
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
To use a custom key, specify the location of this key in CONFIG_MODULE_SIG_KEY, if unspecified the kernel build system will generate a key. It is recommended to generate one manually instead. This can be done with:
root #
openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pem
OpenSSL will ask some questions about the user generating the key, it is recommended to fill in these questions as detailed as possible.
Store the key in a safe location, at the very least the key should be readable only by the root user. Verify this with:
root #
ls -l kernel_key.pem
-r-------- 1 root root 3164 Jan 4 10:38 kernel_key.pem
If this outputs anything other then the above, correct the permissions with:
root #
chown root:root kernel_key.pem
root #
chmod 400 kernel_key.pem
-*- Cryptographic API --->
Certificates for signature checking --->
(/path/to/kernel_key.pem) File name or PKCS#11 URI of module signing key
To also sign external kernel modules installed by other packages via linux-mod-r1.eclass
, enable the modules-sign USE flag globally:
USE="modules-sign"
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Optionally, when using custom signing keys.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # Only required if the MODULES_SIGN_KEY does not also contain the certificate
MODULES_SIGN_HASH="sha512" # Defaults to sha512
The MODULES_SIGN_KEY and MODULES_SIGN_CERT may be different files. For this example the pem file generated by OpenSSL includes both the key and the accompanying certificate, and thus both variables are set to the same value.
Optional: Signing the kernel image (Secure Boot)
When signing the kernel image (for use on systems with Secure Boot enabled) it is recommended to set the following kernel config options:
General setup --->
Kexec and crash features --->
[*] Enable kexec system call
[*] Enable kexec file based system call
[*] Verify kernel signature during kexec_file_load() syscall
[*] Require a valid signature in kexec_file_load() syscall
[*] Enable ""image"" signature verification support
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
[*] Enable loadable module support
-*- Module signature verification
[*] Require modules to be validly signed
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
Security options --->
[*] Integrity subsystem
[*] Basic module for enforcing kernel lockdown
[*] Enable lockdown LSM early in init
Kernel default lockdown mode (Integrity) --->
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
[*] Digital signature verification using multiple keyrings
[*] Enable asymmetric keys support
-*- Require all keys on the integrity keyrings be signed
[*] Provide keyring for platform/firmware trusted keys
[*] Provide a keyring to which Machine Owner Keys may be added
[ ] Enforce Machine Keyring CA Restrictions
Where ""image"" is a placeholder for the architecture specific image name. These options, from the top to the bottom: enforces that the kernel image in a kexec call must be signed (kexec allows replacing the kernel in-place), enforces that kernel modules are signed, enables lockdown integrity mode (prevents modifying the kernel at runtime), and enables various keychains.
On arches that do not natively support decompressing the kernel (e.g. arm64 and riscv), the kernel must be built with its own decompressor (zboot):
Device Drivers --->
Firmware Drivers --->
EFI (Extensible Firmware Interface) Support --->
[*] Enable the generic EFI decompressor
After compilation of the kernel, as explained in the next section, the kernel image must be signed. First install app-crypt/sbsigntools and then sign the kernel image:
root #
emerge --ask app-crypt/sbsigntools
root #
sbsign /usr/src/linux-x.y.z/path/to/kernel-image --cert /path/to/kernel_key.pem --key /path/to/kernel_key.pem --out /usr/src/linux-x.y.z/path/to/kernel-image
For this example the same key that was generated to sign the modules is used to sign the kernel image. It is also possible to generate and use a second sperate key for signing the kernel image. The same OpenSSL command as in the previous section may be used again.
Then proceed with the installation.
To automatically sign EFI executables installed by other packages, enable the secureboot USE flag globally:
USE="modules-sign secureboot"
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Optionally, to use custom signing keys.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # Only required if the MODULES_SIGN_KEY does not also contain the certificate.
MODULES_SIGN_HASH="sha512" # Defaults to sha512
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Optionally, to boot with secureboot enabled, may be the same or different signing key.
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"
The SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT may be different files. For this example the pem file generated by OpenSSL includes both the key and the accompanying certificate, and thus both variables are set to the same value.
When generating an Unified Kernel Image with systemd's
ukify
the kernel image will be signed automatically before inclusion in the unified kernel image and it is not necessary to sign it manually.
Preparando a configuração
Nas máquinas Origin 200/2000, Indigo2 Impact (R10000), Octane/Octane2 e O2, é necessário um kernel 64 bits para dar boot. Para essas máquinas, faça emerge sys-devel/kgcc64 para criar compilador cruzado ("cross-compiler") para a compilação de kernels 64 bits.
Muitos dos sistemas suportados tem arquivo .configs de exemplo no fonte do kernel. Nem todos os sistemas tem arquivo de configuração distribuído dessa forma. Aqueles que tem podem ser configurados usando os comandos descritos na tabela abaixo.
Sistema | Comando de configuração |
---|---|
Servidores Cobalt | make cobalt_defconfig |
Indy, Indigo2 (R4k), Challenge S | make ip22_defconfig |
Origin 200/2000 | make ip27_defconfig |
Indigo2 Impact (R10k) | make ip28_defconfig |
O2 | make ip32_defconfig |
Todas as imagens de instalação do Gentoo provêm o arquivo de opções de configuração do kernel como parte da imagem em si, acessível como /proc/config.gz. Ele pode ser usado em muitos casos. É melhor, entretanto, que os fontes do kernel correspondam os mais próximo possível do kernel em execução. Para extraí-lo, simplesmente use o zcat como mostrado abaixo.
root #
zcat /proc/config.gz > .config
Essa configuração do kernel é feita para uma imagem de boot de rede. Isto é, ela espera encontrar uma imagem de sistema de arquivo root por perto, seja como um diretório para initramfs ou um dispositivo de loopback para initrd. Ao executar o make menuconfig, não se esqueça de ir em General Setup e desabilitar as opções para initramfs.
Customizando a configuração
Uma vez encontrado o arquivo de configuração, copie-o para o diretório dos fontes do kernel e renomeie-o para .config. A partir daí, rode make oldconfig para que tudo seja atualizado conforme as instruções acima, e customize a configuração antes de compilar.
root #
cd /usr/src/linux
root #
cp /path/to/example-config .config
root #
make oldconfig
Por enquanto apenas tecle ENTER (ou Return) em cada prompt para aceitar os defaults...
root #
make menuconfig
Na seção Hackeando o Kernel há uma opção chamada "Você Está Usando um Compilador Cruzado?". Ela instrui aos arquivos Makefile do kernel para acrescentar "mips-linux-" (ou mipsel-linux ... etc) ao gcc como comandos ao compilar o kernel. Isso deve ser desligado, mesmo em compilação cruzada. Em vez disso, se for necessário o uso de um compilador cruzado, especifique o prefixo usando a variável CROSS_COMPILE como mostrado na próxima seção.
Existe um problema conhecido com o JFS e o ALSA em sistemas Octane no qual o ALSA não funciona. Dada a natureza experimental do JFS no MIPS, recomenda-se evitar o uso do JFS por enquanto.
Compilando e instalando
Agora que o kernel está configurado, é hora de compilá-lo e instalá-lo. Saia da configuração e inicie o processo de compilação:
Em máquinas de 64 bits, especifique CROSS_COMPILE=mips64-unknown-linux-gnu- (ou mips64el-... se for um sistema little endian) para usar o compilador de 64 bits.
Para compilar nativamente:
root #
make vmlinux modules modules_install
Para compilação cruzada na máquina-alvo, ajuste mips64-unknown-linux-gnu- de acordo:
root #
make vmlinux modules modules_install CROSS_COMPILE=mips64-unknown-linux-gnu-
Quando compilando em outra máquina, tal como uma x86, use os seguintes comandos para compilar o kernel e instalar os módulos em um diretório específico para ser transferido para a máquina-alvo:
root #
make vmlinux modules CROSS_COMPILE=mips64-unknown-linux-gnu-
root #
make modules_install INSTALL_MOD_PATH=/somewhere
Quando compilar um kernel de 64 bits para a Indy, Indigo2 (R4000), Challenge S ou O2, use o alvo vmlinuz.32 em vez de vmlinux, ou a máquina não serã capaz de dar boot. Isso é para contornar o fato da PROM não entender o formato ELF64.
root #
make vmlinux.32
É possível habilitar a compilação paralela usando
make -jX
com X sendo o número de tarefas em paralelo que o processo de compilação é permitido disparar. Isso é similar às instruções sobre o /etc/portage/make.conf vistas anteriormente, com a variável MAKEOPTS.O comando acima irá criar o vmlinux.32, que é o kernel final.
Quando o kernel terminar de ser compilado, copie sua imagem para o /boot/.
Em servidores Cobalt, o gerenciador de boot esperará encontrar uma imagem de kernel compactada. Lembre-se de compactar o arquivo com gzip -9 após colocá-lo em /boot/.
root #
cp vmlinux /boot/kernel-6.6.21-gentoo
Em servidores Cobalt, compacte a imagem do kernel:
root #
gzip -9v /boot/kernel-6.6.21-gentoo
Alternativa: Usando o genkernel
In case it was missed, this section requires the kernel sources to be installed. Be sure to obtain the relevant kernel sources, then return here for the rest of section.
Genkernel should only be considered by users that have a required need that only Genkernel can meet, otherwise it is recommended to use the Distribution kernel or manually compile your own as it will make maintaining a Gentoo system a lot more simple. An example of why genkernel is more difficult to manage is the lack of integration with sys-kernel/installkernel. This means a user will not get the same level of automation as provided by the other methods, such as Unified Kernel Images will need to be created manually when using Genkernel.
Genkernel provides a generic kernel configuration file and will compile the kernel and initramfs, then install the resulting binaries to the appropriate locations. This results in minimal and generic hardware support for the system's first boot, and allows for additional update control and customization of the kernel's configuration in the future.
Be informed: while using genkernel to maintain the kernel provides system administrators with more update control over the system's kernel, initramfs, and other options, it will require a time and effort commitment to perform future kernel updates as new sources are released. Those looking for a hands-off approach to kernel maintenance should use a distribution kernel.
For additional clarity, it is a misconception to believe genkernel automatically generates a custom kernel configuration for the hardware on which it is run; it uses a predetermined kernel configuration that supports most generic hardware and automatically handles the make commands necessary to assemble and install the kernel, the associate modules, and the initramfs file.
Binary redistributable software license group
If the linux-firmware package has been previously installed, then skip onward to the to the installation section.
As a prerequisite, due to the firwmare
USE flag being enabled by default for the sys-kernel/genkernel package, the package manager will also attempt to pull in the sys-kernel/linux-firmware package. The binary redistributable software licenses are required to be accepted before the linux-firmware will install.
This license group can be accepted system-wide for any package by adding the @BINARY-REDISTRIBUTABLE
as an ACCEPT_LICENSE value in the /etc/portage/make.conf file. It can be exclusively accepted for the linux-firmware package by adding a specific inclusion via a /etc/portage/package.license/linux-firmware file.
If necessary, review the methods of accepting software licenses available in the Installing the base system chapter of the handbook, then make some changes for acceptable software licenses.
If in analysis paralysis, the following will do the trick:
root #
mkdir /etc/portage/package.license
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
Installation
Agora vamos ver como usar o genkernel. Primeiro faça emerge do pacote sys-kernel/genkernel:
root #
emerge --ask sys-kernel/genkernel
Generation
Agora, compile os fontes do kernel executando genkernel all. Note que, como genkernel all compila um kernel com suporte para quase todo tipo de hardware, a compilação pode demorar para terminar!
Se a partição de boot não usa ext2 ou ext3 como sistema de arquivos, pode ser necessário configurar manualmente o kernel usando genkernel --menuconfig all e adicionar suporte para esse sistema de arquivo em particular no kernel (não como módulo). Usuários de LVM2 provavelmente irão querer adicionar
--lvm
como argumento também.Users of LVM2 should add
--lvm
as an argument to the genkernel command below.root #
genkernel all
Quando o genkernel terminar, estarão criados um kernel, um conjunto completo de módulos e um ramdisk inicial (initrd). Usaremos o kernel e o initrd quando configurarmos o gerenciador de boot mais tarde neste documento. Anote os nomes do kernel e do initrd pois essas informações são utilizadas quando o arquivo de configuração do gerenciador de boot for editado. O initrd será executado imediatamente após o boot para fazer a autodetecção de hardware (como no CD de instalação) antes do sistema "real" inicializar.
root #
ls /boot/kernel* /boot/initramfs*
Kernel installation
Installkernel
Installkernel may be used to automate, the kernel installation, initramfs generation, unified kernel image generation and/or bootloader configuration among other things. sys-kernel/installkernel implements two paths of achieving this: the traditional installkernel originating from Debian and systemd's kernel-install. Which one to choose depends, among other things, on the system's bootloader. By default systemd's kernel-install is used on systemd profiles, while the traditional installkernel is the default for other profiles.
If unsure, follow the 'Traditional layout' subsection below.
systemd-boot
When using systemd-boot (formerly gummiboot) as the bootloader, systemd's kernel-install must be used. Therefore ensure the systemd and the systemd-boot USE flags are enabled on sys-kernel/installkernel, and then install the relevant package for systemd-boot.
On OpenRC systems:
sys-apps/systemd-utils boot kernel-install
sys-kernel/installkernel systemd systemd-boot
root #
emerge --ask sys-apps/systemd-utils
On systemd systems:
sys-apps/systemd boot
sys-kernel/installkernel systemd-boot
root #
emerge --ask sys-apps/systemd
GRUB
Users of GRUB can use either systemd's kernel-install or the traditional Debian installkernel. The systemd USE flag switches between these implementations. To automatically run grub-mkconfig when installing the kernel, enable the grub USE flag.
sys-kernel/installkernel grub
root #
emerge --ask sys-kernel/installkernel
Traditional layout, other bootloaders (e.g. lilo, etc.)
The traditional /boot layout (for e.g. LILO, etc.) is used by default if the grub, systemd-boot and uki USE flags are not enabled. No further action is required.
Building an initramfs
In certain cases it is necessary to build an initramfs - an initial ram-based file system. The most common reason is when important file system locations (like /usr/ or /var/) are on separate partitions. With an initramfs, these partitions can be mounted using the tools available inside the initramfs. The default configuration of the Project:Distribution Kernel requires an initramfs.
Without an initramfs, there is a risk that the system will not boot properly as the tools that are responsible for mounting the file systems require information that resides on unmounted file systems. An initramfs will pull in the necessary files into an archive which is used right after the kernel boots, but before the control is handed over to the init tool. Scripts on the initramfs will then make sure that the partitions are properly mounted before the system continues booting.
If using genkernel, it should be used for both building the kernel and the initramfs. When using genkernel only for generating an initramfs, it is crucial to pass
--kernel-config=/path/to/kernel.config
to genkernel or the generated initramfs may not work with a manually built kernel. Note that manually built kernels go beyond the scope of support for the handbook. See the kernel configuration article for more information.Installkernel can automatically generate an initramfs when installing the kernel if the dracut USE flag is enabled:
sys-kernel/installkernel dracut
Alternatively, dracut may be called manually to generate an initramfs. Install sys-kernel/dracut first, then have it generate an initramfs:
root #
emerge --ask sys-kernel/dracut
root #
dracut --kver=6.6.21-gentoo
The initramfs will be stored in /boot/. The resulting file can be found by simply listing the files starting with initramfs:
root #
ls /boot/initramfs*
Optional: Building an Unified Kernel Image
An Unified Kernel Image (UKI) combines, among other things, the kernel, the initramfs and the kernel command line into a single executable. Since the kernel command line is embedded into the unified kernel image it should be specified before generating the unified kernel image (see below). Note that any kernel command line arguments supplied by the bootloader or firmware at boot are ignored when booting with secure boot enabled.
An unified kernel image requires a stub loader, currently the only one available is systemd-stub. To enable it:
For systemd systems:
sys-apps/systemd boot
For OpenRC systems:
sys-apps/systemd-utils boot kernel-install
Installkernel can automatically generate an unified kernel image using either dracut or ukify, by enabling the respective flag. The uki USE flag should be enabled as well to install the generated unified kernel image to the $ESP/EFI/Linux directory on the EFI system partition (ESP).
For dracut:
sys-kernel/installkernel dracut uki
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
For ukify:
sys-apps/systemd ukify # For systemd systems
sys-apps/systemd-utils ukify # For OpenRC systems
sys-kernel/installkernel dracut ukify uki
some-kernel-command-line-arguments
Note that while dracut can generate both an initramfs and an unified kernel image, ukify can only generate the latter and therefore the initramfs must be generated separately with dracut.
Generic Unified Kernel Image
The prebuilt sys-kernel/gentoo-kernel-bin can optionally install a prebuilt generic unified kernel image containing a generic initramfs that is able to boot most systemd based systems. It can be installed by enabling the generic-uki USE flag, and configuring installkernel to not generate a custom initramfs or unified kernel image:
sys-kernel/gentoo-kernel-bin generic-uki
sys-kernel/installkernel -dracut -ukify uki
Secure Boot
The generic Unified Kernel Image optionally distributed by sys-kernel/gentoo-kernel-bin is already pre-signed. How to sign a locally generated unified kernel image depends on whether dracut or ukify is used. Note that the location of the key and certificate should be the same as the SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT as specified in /etc/portage/make.conf.
For dracut:
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
uefi_secureboot_key="/path/to/kernel_key.pem"
uefi_secureboot_cert="/path/to/kernel_key.pem"
For ukify:
[UKI]
SecureBootPrivateKey=/path/to/kernel_key.pem
SecureBootCertificate=/path/to/kernel_key.pem
Rebuilding external kernel modules
External kernel modules installed by other packages via linux-mod-r1.eclass
must be rebuilt for each new kernel version. When the distribution kernels are used this may be automated by enabling the dist-kernel flag globally.
*/* dist-kernel
External kernel modules may also be rebuilt manually with:
root #
emerge --ask @module-rebuild
Módulos do kernel
Configurando os módulos
É opcional listar manualmente os módulos de hardware. udev irá normalmente carregar todos os módulos de hardware que forem detectados ou conectados na maioria dos casos. Entretanto, não causa problema que módulos carregados automaticamente sejam listados. As vezes, algum hardware mais exótico requer alguma ajuda para carregar seus drivers.
Liste os módulos que precisem ser carregados no arquivo /etc/modules-load.d/*.conf, um módulo por linha. Opções extra para os módulos, se necessárias, devem ser configuradas nos arquivos /etc/modprobe.d/*.conf.
Para visualizar todos os módulos disponíveis, execute o seguinte comando find. Não se esqueça de substituir "<kernel version>" pela versão do kernel recém compilada:
root #
find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' | less
Force loading particular kernel modules
Por exemplo, para carregar automaticamente o módulo 3c59x.ko (que é o driver para uma placa de rede específica da família 3Com), edite o arquivo /etc/modules-load.d/network.conf e entre com o nome do módulo nele. O nome real do arquivo não é significativo para o carregador.
root #
mkdir -p /etc/modules-load.d
root #
nano -w /etc/modules-load.d/network.conf
Note that the module's .ko file suffix is insignificant to the loading mechanism and left out of the configuration file:
3c59x
Continue a instalação em Configurando o sistema.
Informação do sistema de arquivos
Nomes de sistemas de arquivos e UUIDs
Tanto o MBR (BIOS) quanto o GPT incluem suporte para nomes e UUIDs do tipo "sistema de arquivo". Esses atributos podem ser definidos em /etc/fstab como alternativa para o comando mount usar quanto tentar encontrar e montar dispositivos de blocos. Nomes de sistemas de arquivos e UUIDs são identificados pelos prefixos LABEL e UUID e podem ser vistos com o comando blkid.
root #
blkid
Se o sistema de arquivo em uma partição é eliminado, o nome do sistema de arquivos os valores UUID serão alterados ou removidos.
Por sua unicidade, leitores usando tabelas de partição do tipo MBR são recomendados usar UUIDs em vez de nomes para definir os volumes a serem montados em /etc/fstab.
UUIDs of the filesystem on a LVM volume and its LVM snapshots are identical, therefore using UUIDs to mount LVM volumes should be avoided.
Nomes de partição e UUIDs
Usuários que tomaram a rota GPT tem algumas opções mais 'robustas' disponíveis para definir as partições em /etc/fstab. Nomes de partições e UUIDs podem ser usados em dispositivos formatados com GPT para identificar de forma única as partições dos dispositivos de bloco, independentemente de qual sistema de arquivos foi escolhida para a partição em si. Nomes e UUIDs são identificados pelos prefixos PARTLABEL e PARTUUID respectivamete e podem ser facilmente visualizados no terminal executando o comando blkid:
Output for an amd64 EFI system using the Discoverable Partition Specification UUIDs may like the following:
root #
blkid
Enquanto nem sempre seja verdade para nomes de partições, usar uma UUID para identificar uma partição em fstab provê uma garantia que o carregador de boot não irá se confundir quando procurar um dado volume, mesmo se o dispositivo de arquivo de bloco mudar no futuro. Usar os velhos padrões de arquivos de dispositivos de bloco (/dev/sd*N) para definir partições no fstab é arriscado para sistemas que são reiniciados frequentemente e tem dispositivos de blocos SATA adicionados e removidos regularmente.
A nomeação de dispositivos de arquivo de bloco depende de um número de fatores incluindo como e em qual ordem os discos estão conectados ao sistema. Eles podem também aparecer em ordem diferente dependendo de quais dispositivos são detectados pelo kernel durante os estágios iniciais de boot. Com isto em mente, a não ser que alguém tenha intenção de constantemente ajustar a ordem dos discos, usar os dispositivos de arquivos de bloco padrão é uma abordagem simples e direta.
Sobre o fstab
No Linux todas as partições usadas pelo sistema devem ser listadas em /etc/fstab. Esse arquivo contém os pontos de montagem das partições (onde elas se encontram na estrutura do sistema de arquivos), como elas devem ser montadas, quais opções especiais (automáticas ou não, se os usuários podem montá-las ou não, etc.)
Criando o arquivo fstab
If the init system being used is systemd, the partition UUIDs conform to the Discoverable Partition Specification as given in Preparing the disks, and the system uses UEFI, then creating an fstab can be skipped, since systemd auto-mounts partitions that follow the spec.
O arquivo /etc/fstab usa uma sintaxe do tipo tabela. Cada linha consiste de seis campos separados por espaço (espaço, tabulação ou ambos). Cada campo tem seu próprio significado:
- O primeiro campo mostra o dispositivo especial de bloco ou sistema de arquivo remoto a ser montado. Diversos tipos de identificadores de dispositivos para nós de dispositivos especiais de bloco, incluindo o caminho para os arquivos de dispositivos, nomes e UUIDs de sistemas de arquivos, nomes de partição e UUIDs.
- O segundo campo mostra o ponto de montagem no qual a partição deve ser montada;
- O terceiro campo mostra o tipo de sistema de arquivo usado pela partição;
- O quarto campo mostra as opções de montagem usadas pelo mount quando ele montar a partição. Como cada tipo de sistema de arquivos tem suas opções de montagem próprias, os usuários são encorajados a ler a página de manual do mount (man mount) para uma listagem completa. Opções múltiplas são separadas por vírgulas;
- O quinto campo é usado pelo
dump
para determinar se ele deve checar a necessidade de backup. É normalmente deixado como 0 (zero); - O sexto campo é usado pelo fsck para determinar a ordem na qual os sistemas de arquivos devem ser checados se o sistema de arquivo foi desativado adequadamente. O sistema de arquivo raiz deve conter 1 enquanto os demais devem conter 2 (ou 0 se a checagem não for necessária).
O arquivo /etc/fstab default fornecido pelo Gentoo não é um arquivo fstab válido mas apenas um modelo.
root #
nano -w /etc/fstab
DOS/Legacy BIOS systems
Vamos dar uma olhada em como criar as opções para a partição /boot/. Isto é apenas um exemplo, e deve ser modificado de acordo com as decisões de particionamento feitas anteriormente na instalação. Em nosso exemplo de particionamento para mips, o /boot/ é normalmente a partição /dev/sda1, com um sistema de arquivos ext2. Ela precisa ser checada durante o boot, então poderíamos escrever:
/dev/sda1 /boot ext2 defaults 0 2
Alguns usuários podem não querer sua partição /boot/ montada automaticamente para aumentar a segurança do sistema. Essas pessoas devem substituir defaults por noauto. Isso significa que esses usuários precisarão montar manualmente essa partição toda vez que precisarem usá-la.
Adicione regras que correspondam ao esquema de particionamento decidido anteriormente e acrescente regras para dispositivos como drives de CD-ROM e, é claro, se forem usadas outras partições ou drives, para esses também.
Abaixo é mostrado um exemplo mais elaborado de um arquivo /etc/fstab:
/dev/sda1 /boot ext2 defaults,noatime 0 2
/dev/sda10 none swap sw 0 0
/dev/sda5 / ext4 noatime 0 1
/dev/cdrom /mnt/cdrom auto noauto,user 0 0
/dev/cdrom /mnt/cdrom auto noauto,user 0 0 }}
UEFI systems
Below is an example of an /etc/fstab file for a system that will boot via UEFI firmware:
# Adjust for any formatting differences and/or additional partitions created from the "Preparing the disks" step
0 2
/dev/sda10 none sw 0 0
/dev/sda5 / xfs defaults,noatime 0 1
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
/dev/cdrom /mnt/cdrom auto noauto,user 0 0
DPS UEFI PARTUUID
Below is an example of an /etc/fstab file for a disk formatted with a GPT disklabel and Discoverable Partition Specification (DPS) UUIDs set for UEFI firmware:
# Adjust any formatting difference and additional partitions created from the "Preparing the disks" step.
# This example shows a GPT disklabel with Discoverable Partition Specification (DSP) UUID set:
PARTUUID=c12a7328-f81f-11d2-ba4b-00a0c93ec93b 0 2
PARTUUID=0657fd6d-a4ab-43c4-84e5-0933c84b4f4f none sw 0 0
PARTUUID= / xfs defaults,noatime 0 1
Quando auto
é usado no terceiro campo, ele faz com que o comando mount tente reconhecer o tipo de sistema de arquivo. Isso é recomendado para mídias removíveis uma vez que podem ser formatadas com algum sistema de arquivo qualquer. A opção user
no quarto campo faz possível a montagem do CD para usuários não root.
To improve performance, most users would want to add the noatime
mount option, which results in a faster system since access times are not registered (those are not needed generally anyway). This is also recommended for systems with solid state drives (SSDs). Users may wish to consider lazytime
instead.
Due to degradation in performance, defining the
discard
mount option in /etc/fstab is not recommended. It is generally better to schedule block discards on a periodic basis using a job scheduler such as cron or a timer (systemd). See Periodic fstrim jobs for more information.Certifique-se que o arquivo /etc/fstab está correto, salve-o e saia do editor para continuar.
Informação de rede
It is important to note the following sections are provided to help the reader quickly setup their system to partake in a local area network.
For systems running OpenRC, a more detailed reference for network setup is available in the advanced network configuration section, which is covered near the end of the handbook. Systems with more specific network needs may need to skip ahead, then return here to continue with the rest of the installation.
For more specific systemd network setup, please review see the networking portion of the systemd article.
Informação de host e domínio
Uma das escolhas que o usuário deve fazer é dar nome ao seu PC. Isso parece bem fácil, mas muitos usuários têm dificuldades em encontrar um nome apropriado para seu PC com Linux. Para acelerar as coisas, saiba que essa decisão não é definitiva - ela pode ser alterada mais tarde. Nos exemplos abaixo, é usado o nome de host "tux" dentro do domínio "homenetwork".
Set the hostname (OpenRC or systemd)
root #
echo tux > /etc/hostname
systemd
To set the system hostname for a system currently running systemd, the hostnamectl utility may be used. During the installation process however, systemd-firstboot command must be used instead (see later on in handbook).
For setting the hostname to "tux", one would run:
root #
hostnamectl hostname tux
View help by running hostnamectl --help or man 1 hostnamectl.
Network
There are many options available for configuring network interfaces. This section covers a only a few methods. Choose the one which seems best suited to the setup needed.
DHCP via dhcpcd (any init system)
Most LAN networks operate a DHCP server. If this is the case, then using the dhcpcd program to obtain an IP address is recommended.
To install:
root #
emerge --ask net-misc/dhcpcd
To enable and then start the service on OpenRC systems:
root #
rc-update add dhcpcd default
root #
rc-service dhcpcd start
To enable the service on systemd systems:
root #
systemctl enable dhcpcd
With these steps completed, next time the system boots, dhcpcd should obtain an IP address from the DHCP server. See the Dhcpcd article for more details.
netifrc (OpenRC)
Configurando a rede
Durante a instalação do Gentoo Linux, a rede já foi configurada. Porém, a configuração foi para o CD de instalação e não para o ambiente instalado. Agora a configuração de rede será feita para o sistema Gentoo Linux instalado.
Informações mais detalhadas sobre configuração de rede, incluindo tópicos avançados como bonding, bridging, 802.1Q VLANs e redes sem fio são cobertas na seção de Configuração de Rede no Gentoo.
Toda a configuração de rede está reunida no arquivo /etc/conf.d/net. Ele usa uma sintaxe direta mas talvez não muito intuitiva. Mas não tema, tudo está explicado abaixo. Um exemplo completamente comentado que cobre muitas configurações diferentes está disponível em /usr/share/doc/netifrc-*/net.example.bz2.
Primeiro instale o pacote net-misc/netifrc:
root #
emerge --ask --noreplace net-misc/netifrc
O DHCP é usado por default. Para o DHCP funcionar, é necessário instalar um cliente DHCP. Isso é descrito adiante em Ferramentas do Sistema Necessárias.
Se a conexão de rede precisa ser configurada por causa de opções específicas do DHCP ou porque o DHCP não é utilizado, então edite /etc/conf.d/net:
root #
nano -w /etc/conf.d/net
Configure ambas as variáveis config_eth0 e routes_eth0 para entrar com a informação de endereço IP e de roteamente:
É assumido que a interface de rede é chamada eth0. Isso, porém, é muito dependente do sistema. É recomendado assumir que a interface é nomeada da mesma forma que quando o sistema foi inicializado pela mídia de instalação se a mídia de instalação for razoavelmente recente. Mais informações podem ser encontradas em Nomes de Interface de Rede.
config_eth0="192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255"
routes_eth0="default via 192.168.0.1"
Para usar DHCP, defina config_eth0:
config_eth0="dhcp"
Por favor veja os arquivos /usr/share/doc/netifrc-*/net.example.bz2 para uma lista de todas as opções disponíveis. Certifique-se de também ler a página de manual (man page) se opções específicas do DHCP precisarem ser configuradas.
Se o sistema tem várias interfaces de rede, então repita os passos acima para config_eth1, config_eth2, etc.
Agora salve a configuração e saia para continuar.
Iniciando automaticamente a rede durante o boot
Para que as interfaces de rede sejam ativadas durante o boot, elas precisam ser adicionadas no runlevel default.
root #
cd /etc/init.d
root #
ln -s net.lo net.eth0
root #
rc-update add net.eth0 default
Se o sistema tem várias interfaces de rede, então os arquivos net.* precisam ser criados assim como fizemos com o net.eth0.
Se após a inicialização do sistema descobrirmos que o nome que usamos para a interface de rede (que está atualmente documentada como eth0) está errado, então execute os seguintes passos para corrigir isso:
- Corrija o arquivo /etc/conf.d/net com o nome correto da interface de rede (tal como
enp3s0
em vez deeth0
). - Crie um novo link simbólico (como /etc/init.d/net.enp3s0).
- Remova o link simbólico antigo (rm /etc/init.d/net.eth0).
- Adicione o novo ao runlevel default.
- Remova o antigo usando rc-update del net.eth0 default.
O arquivo hosts
Agora informe ao Linux sobre seu ambiente de rede. Isso é definido no arquivo /etc/hosts e é utilizado na resolução de nomes de hosts em endereços IP para os hosts que não são resolvidos pelo servidor de nomes.
root #
nano -w /etc/hosts
# This defines the current system and must be set
127.0.0.1 tux.homenetwork tux localhost
# Optional definition of extra systems on the network
192.168.0.5 jenny.homenetwork jenny
192.168.0.6 benny.homenetwork benny
Salve e saia do editor para continuar.
Informações do sistema
Senha do root
Configure a senha do root usando o comando passwd.
root #
passwd
A conta de root é uma toda poderosa, então escolha uma senha forte. Depois uma conta de usuário comum será criada para operações diárias.
Configuração de início e boot
OpenRC
Gentoo (ao menos quando usa OpenRC) usa /etc/rc.conf para configurar os serviços, início, desligamento do sistema. Abra /etc/rc.conf e aproveite todos os comentários no arquivo. Reveja as configurações e mude onde for necessário.
root #
nano -w /etc/rc.conf
Em seguida, abra /etc/conf.d/keymaps para manipular a configuração de teclado. Edite-o para configurar e escolher o teclado correto.
root #
nano -w /etc/conf.d/keymaps
Tenha um cuidado especial com a variável keymap. Se o mapa de teclado errado for selecionado, resultados estranhos aparecerão durante a digitação.
Finalmente, edite /etc/conf.d/hwclock para definir as opções de relógio. Edite-o de acordo com suas preferências.
root #
nano -w /etc/conf.d/hwclock
Se o relógio de hardware não estiver usando UTC é necessário incluir clock="local"
no arquivo. Senão o sistema pode apresentar comportamento errático do relógio.
systemd
First, it is recommended to run systemd-machine-id-setup and then systemd-firstboot which will prepare various components of the system are set correctly for the first boot into the new systemd environment. The passing the following options will include a prompt for the user to set a locale, timezone, hostname, root password, and root shell values. It will also assign a random machine ID to the installation:
root #
systemd-machine-id-setup
root #
systemd-firstboot --prompt
Next users should run systemctl to reset all installed unit files to the preset policy values:
root #
systemctl preset-all --preset-mode=enable-only
It's possible to run the full preset changes but this may reset any services which were already configured during the process:
root #
systemctl preset-all
These two steps will help ensure a smooth transition from the live environment to the installation's first boot.
Sistema de log
OpenRC
Algumas ferramentas estão ausentes do arquivo stage3 porque diversos outros pacotes fornecem a mesma funcionalidade. Agora depende do usuário escolher quais instalar.
A primeira ferramente sobre a qual precisamos nos decidir é a que provê serviço de log para o sistema. Unix e Linux tem uma história excelente de capacidade de serviço de log - se necessário, tudo o que acontece no sistema pode ser logado nos arquivos de log. Isso acontece através do serviço de log.
O Gentoo oferece vários utilitários de logs do sistema. Entre eles estão incluídos:
- app-admin/sysklogd - Oferece o conjunto tradicional de serviços de log do sistema. É o sistema de log default e funciona bem sem precisar de configuração, o que faz deste pacote uma boa opção para iniciantes.
- app-admin/syslog-ng - Um sistema de log avançado. Requer configurações adicionais para qualquer coisa além de gerar log para um arquivo. Usuários mais avançados podem escolher este pacote baseados no seu potencial de registro de logs; entretanto, configurações adicionais são necessárias para qualquer tipo de registro inteligente de log.
- app-admin/metalog - Um sistema de log altamente configurável.
Outros também estão disponíveis através do Portage - o número de pacotes disponíveis aumenta diariamente.
Se for usado o sysklogd ou syslog-ng, é recomendado instalar e configurar o pacote logrotate em seguida uma vez que esses sistemas de log não oferece nenhum mecanismo de rotação dos arquivos de log.
Para instalar o sistema de log de sua escolha, faça emerge dele e o adicione ao runlevel default usando rc-update. O exemplo a seguir instala o pacote app-admin/sysklogd.
root #
emerge --ask app-admin/sysklogd
root #
rc-update add sysklogd default
systemd
While a selection of logging mechanisms are presented for OpenRC-based systems, systemd includes a built-in logger called the systemd-journald service. The systemd-journald service is capable of handling most of the logging functionality outlined in the previous system logger section. That is to say, the majority of installations that will run systemd as the system and service manager can safely skip adding a additional syslog utilities.
See man journalctl for more details on using journalctl to query and review the systems logs.
For a number of reasons, such as the case of forwarding logs to a central host, it may be important to include redundant system logging mechanisms on a systemd-based system. This is a irregular occurrence for the handbook's typical audience and considered an advanced use case. It is therefore not covered by the handbook.
Opcional: Cron daemon
OpenRC
Em seguida o cron daemon. Embora ele seja opcional e não requerido em todo sistema, é prudente instalar um.
Um cron daemon executa comandos agendados. É muito útil se algum comando necessita ser executado regularmente (por exemplo, diária, semanal ou mensalmente).
All cron daemons support high levels of granularity for scheduled tasks, and generally include the ability to send an email or other form of notification if a scheduled task does not complete as expected.
O Gentoo oferece diversos crons daemons possíveis, incluindo o sys-process/bcron, o sys-process/dcron, o sys-process/fcron e o sys-process/cronie. Instalar um desses é similar a instalar o sistema de log. O exemplo abaixo usa o pacote sys-process/cronie:
- sys-process/cronie - cronie is based on the original cron and has security and configuration enhancements like the ability to use PAM and SELinux.
- sys-process/dcron - This lightweight cron daemon aims to be simple and secure, with just enough features to stay useful.
- sys-process/fcron - A command scheduler with extended capabilities over cron and anacron.
- sys-process/bcron - A younger cron system designed with secure operations in mind. To do this, the system is divided into several separate programs, each responsible for a separate task, with strictly controlled communications between parts.
cronie
The following example uses sys-process/cronie:
root #
emerge --ask sys-process/cronie
root #
rc-update add cronie default
root #
rc-update add cronie default
Alternative: dcron
root #
emerge --ask sys-process/dcron
Se o dcron ou o fcron for usado, um comando adicional de inicialização precisa ser executado:
root #
crontab /etc/crontab
Alternative: fcron
root #
emerge --ask sys-process/fcron
If fcron is the selected scheduled task handler, an additional emerge step is required:
root #
emerge --config sys-process/fcron
Alternative: bcron
bcron is a younger cron agent with built-in privilege separation.
root #
emerge --ask sys-process/bcron
systemd
Similar to system logging, systemd-based systems include support for scheduled tasks out-of-the-box in the form of timers. systemd timers can run at a system-level or a user-level and include the same functionality that a traditional cron daemon would provide. Unless redundant capabilities are necessary, installing an additional task scheduler such as a cron daemon is generally unnecessary and can be safely skipped.
Opcional: Indexação de arquivos
De modo a indexar o sistema de arquivos para obter a capacidade de localizar arquivos rapidamente, instale o pacote sys-apps/mlocate.
root #
emerge --ask sys-apps/mlocate
Opcional: Acesso remoto
opensshd's default configuration does not allow root to login as a remote user. Please create a non-root user and configure it appropriately to allow access post-installation if required, or adjust /etc/ssh/sshd_config to allow root.
Para ser capaz de acessar o sistema remotamente após a instalação, adicione o script de inicialização sshd o runlevel default:
OpenRC
root #
rc-update add sshd default
Se for necessário acesso ao console serial (o que é possível em caso de servidores remotos), descomente a seção de console serial em /etc/inittab:
Uncomment the serial console section in /etc/inittab:
root #
nano -w /etc/inittab
# SERIAL CONSOLES s0:12345:respawn:/sbin/agetty 9600 ttyS0 vt100 s1:12345:respawn:/sbin/agetty 9600 ttyS1 vt100
systemd
To enable the SSH server, run:
root #
systemctl enable sshd
To enable serial console support, run:
root #
systemctl enable getty@tty1.service
Optional: Shell completion
Bash
Bash is the default shell for Gentoo systems, and therefore installing completion extensions can aid in efficiency and convenience to managing the system. The app-shells/bash-completion package will install completions available for Gentoo specific commands, as well as many other common commands and utilities:
root #
emerge --ask app-shells/bash-completion
Post installation, bash completion for specific commands can managed through eselect. See the Shell completion integrations section of the bash article for more details.
Time synchronization
It is important to use some method of synchronizing the system clock. This is usually done via the NTP protocol and software. Other implementations using the NTP protocol exist, like Chrony.
To set up Chrony, for example:
root #
emerge --ask net-misc/chrony
OpenRC
On OpenRC, run:
root #
rc-update add chronyd default
systemd
On systemd, run:
root #
systemctl enable chronyd.service
Alternatively, systemd users may wish to use the simpler systemd-timesyncd SNTP client which is installed by default.
root #
systemctl enable systemd-timesyncd.service
Ferramentas de sistemas de arquivos
Dependendo dos sistemas de arquivos usados, é necessário instalar os utilitários de sistemas de arquivos (para checagem da integridade do sistema de arquivos, criar sistemas de arquivos adicionais etc). Note que as ferramentas para gerenciar os sistemas de arquivos ext2, ext3 ou ext4 (sys-fs/e2fsprogs) já foram instaladas como parte conjunto @system.
A tabela seguinte lista as ferramentas para instalar se um dado sistema de arquivo for usado:
Sistema de arquivo | Pacote |
---|---|
Ext2, 3 e 4 | sys-fs/e2fsprogs |
XFS | sys-fs/xfsprogs |
ReiserFS | sys-fs/reiserfsprogs |
JFS | sys-fs/jfsutils |
VFAT (FAT32, ...) | sys-fs/dosfstools |
Btrfs | sys-fs/btrfs-progs |
It's recommended that sys-block/io-scheduler-udev-rules is installed for the correct scheduler behavior with e.g. nvme devices:
root #
emerge --ask sys-block/io-scheduler-udev-rules
Para mais informações sobre sistemas de arquivos no Gentoo, veja o artigo Sistemas de Arquivos.
Utilitários de rede
Se não houver necessidade de nenhum utilitário adicional de rede, continue imediatamente na seção Configurando um gerenciador de boot.
Instalando um cliente DHCP
Embora opcional, a maioria dos usuários irá precisar de um cliente DHCP para usar o servidor DHCP em suas redes. Aproveite esta oportunidade para instalar um cliente DHCP. Se este passo for esquecido, o sistema pode não ser capaz de usar a rede tornando impossível baixar o cliente DHCP mais tarde.
De modo ao sistema automaticamente obter um endereço IP para uma ou mais interfaces usando os scripts netifrc, é necessário instalar um cliente DHCP. Recomendamos o uso do net-misc/dhcpcd embora muitos outros clientes DHCP estejam disponíveis no repositório do Gentoo:
root #
emerge --ask net-misc/dhcpcd
Opcional: Instalando um cliente PPPoE
Se for usado PPP para conexão à Internet, instale o pacote net-dialup/ppp:
root #
emerge --ask net-dialup/ppp
Opcional: Instalar utilitários para a rede sem fio
Se o sistema for se conectar em redes sem fio, instale o pacote net-wireless/iw para redes abertas ou com WEP e/ou o pacote net-wireless/wpa_supplicant para redes WPA ou WPA2. O pacote iw também é uma ferramenta básica de diagnóstico para pesquisa de redes sem fio.
root #
emerge --ask net-wireless/iw net-wireless/wpa_supplicant
Agora continue em Configurando o gerenciador de boot.
arcload para máquinas Silicon Graphics
O arcload foi criado para máquinas que requerem kernel de 64 bits e desse modo não podem usar o arcboot (que não pode ser facilmente compilado como um binário de 64 bits). Ele também contorna peculiaridades que aparecem ao se carregar o kernel diretamente do cabeçalho de volume. Vamos proceder com a instalação:
root #
emerge arcload dvhtool
Depois de terminado, encontre o binário arcload em /usr/lib/arcload/. Dois arquivos existem lá:
- sashARCS: O binário de 32 bits para sistemas Indy, Indigo2 (R4k), Challenge S e O2 systems
- sash64: O binário de 64 bits para sistemas Octane/Octane2, Origin 200/2000 e Indigo2 Impact
- sashARCS: The 32-bit binary for Indy, Indigo2 (R4k), Challenge S and O2 systems
- sash64: The 64-bit binary for Octane/Octane2, Origin 200/2000 and Indigo2 Impact systems
Use o dvhtool
para instalar o binário apropriado para o sistema no volume de cabeçalho:
Para usuários Indy/Indigo2/Challenge S/O2:
root #
dvhtool --unix-to-vh /usr/lib/arcload/sashARCS sashARCS
Para usuários Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000:
root #
dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64
O nome "sashARCS" ou "sash64" não precisam ser utilizados, a menos que a instalação seja feita no cabeçalho de volume de um CD de boot. Para boot normal de um disco rígido, pode ser usado qualquer nome que o usuário quiser.
Agora use o dvhtool
para checar que estão no cabeçalho de volume:
root #
dvhtool --print-volume-directory
----- directory entries ----- Entry #0, name "sash64", start 4, bytes 55859
O arquivo arc.cf tem uma sintaxe parecida com C. Para detalhes completos sobre como o configurar, veja a página do arcload no wiki Linux/MIPS. Resumindo, defina algumas opções, que são habilitadas ou desabilitadas durante o boot usando a variável OSLoadFilename.
# Configuração do ARCLoad
# Algumas configurações default
append "root=/dev/sda5";
append "ro";
append "console=ttyS0,9600";
# Definição principal. ip28 pode ser alterado se desejado.
ip28 {
# Definição de um kernel funcional
# Selecione este setando OSLoadFilename="ip28(working)"
working {
description "SGI Indigo2 Impact R10000\n\r";
image system "/working";
}
# Definição de um novo kernel
# Selecione este setando OSLoadFilename="ip28(new)"
new {
description "SGI Indigo2 Impact R10000 - Testing Kernel\n\r";
image system "/new";
}
# Para debugar um kernel
# Selecione este setando OSLoadFilename="ip28(working,debug)"
# or OSLoadFilename="ip28(new,debug)"
debug {
description "Debug console";
append "init=/bin/bash";
}
}
A partir do arcload-0.5, o arc.cf e os kernel podem residir ou no cabeçalho de volume ou em uma partição. Para utilizar esse novo recurso, coloque os arquivos na partição /boot/ (ou / se a partição de boot não for separada). O arcload usa o código do driver do sistema de arquivos do popular gerenciador de boot grub e por isso suporta o mesmo conjunto de sistemas de arquivos.
root #
dvhtool --unix-to-vh arc.cf arc.cf
root #
dvhtool --unix-to-vh /usr/src/linux/vmlinux new
CoLo para Cobalt MicroServers
Instalando o CoLo
Servidores Cobalt possuem um firmware muito mais limitado instalado no chip. A BOOTROM do Cobalt é primitiva em comparação com a PROM SGI e tem um número de sérias limitações.
- Há um limite de 675kB (aproximadamente) para o kernel. O tamanho atual do Linux 2.4 torna quase impossível criar um kernel desse tamanho. O Linux 2.6 e 3.x estão totalmente fora de questão.
- Kernel de 64 bits não são suportados pelo firmware de fábrica (são altamente experimentais em máquinas Cobalt atualmente)
- O shell é no máximo bem básico
Para superar essas limitações, um firmware alternativo, chamado CoLo (Cobalt Loader) foi desenvolvido. Essa é uma imagem de BOOTROM que pode tanto ser gravada no chip dentro do servidor Cobalt, ou carregada a partir de um firmware existente.
Este guia explicará como configurar o CoLo de modo a ele ser carregado pelo firmware de fábrica. Esse é o único modo realmente recomendado e seguro de configurar o CoLo.
Se desejado, o CoLo pode ser gravado na BOOTPROM do servidor para substituir completamente o firmware original, porém você estará totalmente por sua conta nessa empreitada. Caso alguma coisa dê errada, remova fisicamente a BOOTPROM e reprograme-a com o firmware de fábrica. Se isso soa assustador então NÃO grave a BOOTPROM da máquina. Não assumimos nenhuma responsabilidade por qualquer coisa que aconteça se este aviso for ignorado.
Vamos agora instalar o CoLo. Primeiro, faça emerge do pacote.
root #
emerge --ask sys-boot/colo
Com isso instalado, dê uma olhada no diretório /usr/lib/colo/ para encontrar dois arquivos:
- colo-chain.elf (o "kernel" para o firmware de fábrica carregar) e
- colo-rom-image.bin (uma imagem de ROM para ser gravada na BOOTPROM)
- colo-chain.elf - the "kernel" for the stock firmware to load.
- colo-rom-image.bin - a ROM image for flashing into the BOOTROM.
Começamos montando /boot/ e colocando uma cópia compactada de colo-chain.elf em /boot/, onde o sistema espera encontrá-la.
root #
gzip -9vc /usr/lib/colo/colo-chain.elf > /boot/vmlinux.gz
Configurando o CoLo
Quando o sistema der boot, ele irá carregar o CoLo que mostrará um menu no display LCD traseiro. A primeira opção (e default, que é assumida após cerca de 5 segundos) é dar boot no disco rígido. O sistema então tenta montar a primeira partição Linux que encontrar e executar o script default.colo. A sintaxe é documentada na documentação do CoLo (veja /usr/share/doc/colo-X.YY/README.shell.gz, onde X.YY é a versão instalada) e é muito simples.
Apenas uma dica: ao instalar um novo kernel, é recomendado criar duas imagens: kernel.gz.working -- um kernel que sabe-se que funciona, e kernel.gz.new -- o kernel recém-compilado. É possível usar links simbólicos para apontar para os kernels "novo" e "funcionando", ou simplesmente renomeie as imagens do kernel.
#:CoLo:#
mount hda1
load /kernel.gz.working
execute root=/dev/sda5 ro console=ttyS0,115200
O CoLo não executará scripts que não iniciem com a linha
#:CoLo:#
. Pense nisso como o equivalente de usar #!/bin/sh
em shell scripts.Também é possível perguntar, por exemplo, qual kernel e configuração dar boot, com um limite de tempo default. A configuração abaixo faz exatamente isso, pergunta ao usuário qual kernel deseja dar boot e executa a imagem selecionada. vmlinux.gz.new e vmlinux.gz.working podem ser as imagens reais do kernel, ou apenas links simbólicos para imagens do kernel no disco. O argumento "50" especifica que ele deve prosseguir com a primeira opção ("working") após 5 segundos (50 décimos de segundo).
#:CoLo:#
lcd "Mounting hda1"
mount hda1
select "Qual kernel?" 50 Working New
goto {menu-option}
var image-name vmlinux.gz.working
goto 3f
@var image-name vmlinux.gz.working
goto 2f
@var image-name vmlinux.gz.new
@lcd "Carregando Linux" {image-name}
load /{image-name}
lcd "Booting..."
execute root=/dev/sda5 ro console=ttyS0,115200
boot
Veja a documentação em /usr/share/doc/colo-VERSION para maiores detalhes.
Configuração para console serial
OK, a instalação do Linux como está agora daria boot normalmente, mas assume que o usuário estará logado em um terminal físico. Em máquinas Cobalt isso é particularmente ruim - não existem terminais físicos.
Aqueles que tiverem o privilégio de possuir um chipset de vídeo suportado podem pular esta seção se assim desejado.
Primeiro, usando um editor e abra o arquivo /etc/inittab. Abaixo no arquivo, verifique o seguinte:
# SERIAL CONSOLE
#c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102
# TERMINALS
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux
# What to do at the "Three Finger Salute".
ca:12345:ctrlaltdel:/sbin/shutdown -r now
Primeiro, retire o sinal de comentário da linha c0. Por default, ela é configurada para usar uma taxa de bauds de terminal de 9600 bps. Nos servidores Cobalt ela pode ser trocada para 115200 para casar a taxa de bauds da BOOT PROM. Abaixo está como essa seção ficará. Em uma máquina sem monitor (servidores Cobalt, por ex.) recomendamos também por em comentário as linhas de terminais locais (c1 até c6) uma vez que elas têm o hábito de não se comportarem bem quando não podem abrir o /dev/ttyX.
# SERIAL CONSOLE
c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102
# TERMINALS -- These are useless on a headless qube
#c1:12345:respawn:/sbin/agetty 38400 tty1 linux
#c2:12345:respawn:/sbin/agetty 38400 tty2 linux
#c3:12345:respawn:/sbin/agetty 38400 tty3 linux
#c4:12345:respawn:/sbin/agetty 38400 tty4 linux
#c5:12345:respawn:/sbin/agetty 38400 tty5 linux
#c6:12345:respawn:/sbin/agetty 38400 tty6 linux
Agora, por fim... temos que dizer ao sistema que a porta serial local pode ser confiada como um terminal seguro. O arquivo que precisamos alterar é o /etc/securetty. Ele contém uma lista de terminais nos quais o sistema confia. Simplesmente acrescentamos duas linhas, permitindo que a linha serial seja usada para login do root.
root #
echo 'ttyS0' >> /etc/securetty
Em outro momento, o Linux também chama a linha de /dev/tts/0 -- então a adicionamos também:
root #
echo 'tts/0' >> /etc/securetty
Ajustando a PROM SGI
Configurações genéricas da PROM
Com o carregador de boot instalado, depois de fazer o reboot (que discutiremos em breve), vá ao menu de manutenção do sistema (System Maintenance Menu) e selecione Enter Command Monitor (5) como feito anteriormente para dar boot pela rede no sistema.
1. Start System
2. Install System Software
3. Run Diagnostics
4. Recover System
5. Enter Command Monitor
Forneça a localização do Cabeçalho de Volume:
>>
setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)
Automaticamente dar boot no Gentoo:
>>
setenv AutoLoad Yes
Configure a zona horária:
>>
setenv TimeZone BRT
Use o console serial - usuários de adaptador gráfico devem usar "g" em vez de "d1":
>>
setenv console d1
Ajuste a taxa de bauds do console serial. Isso é opcional, 9600 é a configuração default embora possa-se usar taxas de até 38400 se desejado:
>>
setenv dbaud 9600
Agora, as configurações seguintes dependem de como o sistema é inicializado:
Configurações para boot diretamente do Cabeçalho de Volume
Apresentado apenas para deixar este documento completo. É recomendado que os usuários instalem o arcload em vez de usar este método.
Isto funciona apenas na Indy, Indigo2 (R4k) e Challenge S.
Configure o dispositivo de root para a partição root do Gentoo, tal como /dev/sda3:
>>
setenv OSLoadPartition <root device>
Para listar os kernels disponíveis, digite "ls".
>>
setenv OSLoader <kernel name>
>>
setenv OSLoadFilename <kernel name>
Declare os parâmetros do kernel a serem passados:
>>
setenv OSLoadOptions <kernel parameters>
Para experimentar um kernel sem fazer confusão com os parâmetros do kernel, use o comando boot -f da PROM:
root #
boot -f new root=/dev/sda5 ro
Configurações do arcload
O arcload usa a opção OSLoadFilename para especificar quais opções configurar do arquivo arc.cf. O arquivo de configuração é essencialmente um script, com os blocos de níveis superiores definindo as imagens de boot para diferentes sistemas e, dentro deles, configurações opcionais. Assim, definindo OSLoadFilename=mysys(serial) busca as configurações do bloco mysys e então configura opções adicionais redifinidas em serial.
No exemplo acima temos um bloco de sistema definido, ip28, com as opções "working" (funcionando), "new" (novo) e "debug" (depurar) disponíveis. Definimos nossas variáveis da PROM assim:
Seleciona arcload como gerenciador de boot:- sash64 ou sashARCS:
>>
setenv OSLoader sash64
Usa a imagem de kernel "working", definida na seção "ip28" do arc.cf:
>>
setenv OSLoadFilename ip28(working)
A partir do arcload-0.5, os arquivos não precisam mais ser colocados no cabeçalho de volume - em vez disso eles podem ser colocados em uma partição. Para dizer ao arcload onde procurar por seus arquivos de configuração e kernels, deve-se configurar a variável OSLoadPartition da PROM. O valor exato a ser definido depende de onde o disco reside no bus SCSI. Use a variável da PROM SystemPartition como guia - apenas o número da partição deve ser necessário ajustar.
Partições são numeradas iniciando em 0, não em 1 como no Linux.
Para carregar do cabeçalho de volume, use a partição 8.
>>
setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(8)
Ou especifique a partição e o tipo de sistema de arquivos:
>>
setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(0)[ext2]
Reiniciando o sistema
Saia do ambiente chroot e desmonte todas as partições montadas. Então digite o comando mágico que dá início ao verdadeiro teste final: reboot.
root #
exit
cdimage ~#
cd
cdimage ~#
umount -l /mnt/gentoo/dev{/shm,/pts,}
cdimage ~#
umount /mnt/gentoo{/boot,/sys,/proc,}
cdimage ~#
reboot
Claro, não esqueça de remover o CD de boot ou o sistema irá reinicializar pelo CD em vez do novo sistema Gentoo.
Uma vez reiniciado o sistema no ambiente recém-instalado finalize com Finalizando a instalação do Gentoo.
Administração de usuários
Adicionando um usuário para uso do dia-a-dia
Trabalhar como usuário root em um sistema Unix/Linux é perigoso e deve ser evitado o máximo possível. Assim, é muito recomendado adicionar um usuário para uso no dia-a-dia.
Os grupos que o usuário é membro definem quais atividades o usuário pode fazer. A tabela seguinte lista um número de grupos importantes:
Grupo | Descrição |
---|---|
audio | Ser capaz de acessar dispositivos de audio. |
cdrom | Ser capaz de acessar diretamente dispositivos óticos. |
floppy | Ser capaz de acessar drives de disquetes. |
games | Ser capaz de jogar jogos. |
portage | Ser capaz de acessar os recursos restritos do Portage. |
usb | Ser capaz de acessar dispositivos USB. |
video | Ser capaz de acessar dispositivos de captura de video ou usar aceleração de hardware. |
wheel | Ser capaz de usar su. |
Por exemplo, para criar um usuário chamado larry que é membro dos grupos wheel, users, e audio, faça login como root (apenas o root pode criar usuários) e execute useradd:
Login:
root
Password: (Enter the root password)
When setting passwords for standard user accounts, it is good security practice to avoid using the same or a similar password as set for the root user.
Handbook authors recommended to use a password at least 16 characters in length, with a value fully unique from every other user on the system.
root #
useradd -m -G users,wheel,audio -s /bin/bash larry
root #
passwd larry
Password: (Enter the password for larry) Re-enter password: (Re-enter the password to verify)
Temporarily elevating privileges
Se um usuário precisar realizar alguma tarefa como root, ele pode usar su - para ter temporariamente privilégios de root. Outra forma é usar o pacote sudo que é, se configurado corretamente, muito seguro.
Disabling root login
To prevent possible threat actors from logging in as root, deleting the root password and/or disabling root login can help improve security.
To disable root login:
root #
passwd -l root
To delete the root password and disable login:
root #
passwd -dl root
Limpeza do disco
Removendo os arquivos tar
Com a instalação do sistema Gentoo terminada e o sistema reiniciado, se tudo deu certo, podemos agora remover do disco os arquivos tar stage3 baixados. Lembre-se que eles foram baixados no diretório /.
The files are located in the / directory and can be removed with the following command:
root #
rm /stage3-*.tar.*
Aonde ir a partir daqui
Para onde ir a partir daqui? Há muitos caminhos a explorar... O Gentoo provê a seus usuários muitas possibilidades e também muitos recursos documentados (e outros nem tanto) a explorar aqui no wiki e outros subdomínios relacionados ao Gentoo (veja a seção Gentoo online abaixo).
Documentação
It is important to note that, due to the number of choices available in Gentoo, the documentation provided by the handbook is limited in scope - it mainly focuses on the basics of getting a Gentoo system up and running and basic system management activities. The handbook intentionally excludes instructions on graphical environments, details on hardening, and other important administrative tasks. That being stated, there are more sections of the handbook to assist readers with more basic functions.
Leitores devem com certeza dar uma olhada na próxima parte do Manual do Gentoo entitulada Trabalhando com o Gentoo que explica como manter seu sistema atualizado, como instalar pacotes de software adicionais, detalhes sobre as USE flags, o sistema de inicialização OpenRC etc, e vários outros tópicos informativos relacionados ao gerenciamento de um sistema Gentoo após a instalação.
Além do manual, o leitor também é encorajado a explorar outros cantos do Gentoo wiki para encontrar documentação adicional provida pela comunidade. A equipe do wiki do Gentoo oferece também uma Visão geral da documentação que lista uma seleção de artigos do wiki por categoria. Por exemplo, ela faz referência ao Guia de localização para fazer um sistema sentir-se mais em casa (particularmente útil para usuários que falam Inglês como segunda língua).
The majority of users with desktop use cases will setup graphical environments in which to work natively. There are many community maintained 'meta' articles for supported desktop environments (DEs) and window managers (WMs). Readers should be aware that each DE will require slightly different setup steps, which will lengthen add complexity to bootstrapping.
Many other Meta articles exist to provide our readers with high level overviews of available software within Gentoo.
Gentoo online
Os leitores devem notar que todos os sites online do Gentoo são governados pelo código de conduta do Gentoo. Ser ativo na comunidade Gentoo é um privilégio, não um direito, e os usuários devem estar cientes que o código de conduta existe por uma razão.
Com a exceção da rede IRC (Internet Relay Chat) hospedada pelo Freenode a as listas de discussão, a maioria dos sites web requerem uma conta para cada site de modo a fazer perguntas, abrir uma discussão ou reportar um bug.
Fóruns e IRC
Todos usuários são bem-vindos em nossos Fóruns do Gentoo ou em um dos nossos canais IRC. É fácil pesquisar nos fóruns se problemas encontrados em uma nova instalação do Gentoo foram encontrados anteriormente e resolvidos. É muito grande a probabilidade de outros usuários iniciantes no Gentoo terem os mesmos problemas. É recomendado pesquisar nos fóruns e no wiki antes de pedir ajuda nos canais de suporte do Gentoo.
Listas de discussão
Diversas listas de discussão estão disponíveis aos membros da comunidade que preferem solicitar ajuda ou informações por email em vez de criar uma conta de usuário nos fóruns ou IRC. O usuário deve seguir as instruções de movo a se inscrever em uma lista específica.
Bugs
É possível que depois de algum tempo pesquisando no wiki, fóruns e solicitando suporte por IRC e listas de discussão, não se encontre a solução para algum problema. Normalmente isso é um sinal para abrir um bug no site do Bugzilla.
Guia de desenvolvimento
Usuários que desejarem aprender mais sobre como desenvolver o Gentoo podem ver o Guia de desenvolvimento. Esse guia provê instruções sobre escrever ebuilds, trabalhar com eclasses e fornece definições para diversos conceitos gerais por trás do desenvolvimento do Gentoo.
Considerações finais
O Gentoo é uma distribuição robusta, flexível e excelentemente mantida. A comunidade de desenvolvedores fica feliz em receber sugestões sobre como fazer do Gentoo uma distribuição ainda melhor.
Como lembrete, qualquer sugestão sobre este manual deve seguir as diretrizes detalhadas na seção Como posso ajudar a melhorar o Manual? no início do manual.
Estamos ansiosos para saber como nossos usuários utilizam o Gentoo!