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

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

Manual:MIPS/Instalação/Gerenciador de Boot

From Gentoo Wiki (test)
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:MIPS/Installation/Bootloader and the translation is 100% complete.
MIPS Handbook
Installation
About the installation
Choosing the media
Configuring the network
Preparing the disks
Installing stage3
Installing base system
Configuring the kernel
Configuring the system
Installing tools
Configuring the bootloader
Finalizing
Working with Gentoo
Portage introduction
USE flags
Portage features
Initscript system
Environment variables
Working with Portage
Files and directories
Variables
Mixing software branches
Additional tools
Custom package repository
Advanced features
Network configuration
Getting started
Advanced configuration
Modular networking
Wireless
Adding functionality
Dynamic management



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

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
Nota
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.

Collapse
Filearc.cfUm arc.cf exemplo

'"`UNIQ--pre-00000002-QINU`"'

This is a deprecated template. Help us update this template!

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.

Nota
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.
Aviso
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)

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.

Nota
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.
Collapse
Filedefault.coloUm exemplo de configuração do CoLo

'"`UNIQ--pre-00000005-QINU`"'

This is a deprecated template. Help us update this template!

Nota
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).

Collapse
Filedefault.coloConfiguração baseada em menu

'"`UNIQ--pre-00000008-QINU`"'

This is a deprecated template. Help us update this template!

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.

Nota
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:

Collapse
File/etc/inittabTrecho do arquivo inittab

'"`UNIQ--pre-0000000B-QINU`"'

This is a deprecated template. Help us update this template!

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.

Collapse
File/etc/inittabTrecho de exemplo do inittab

'"`UNIQ--pre-0000000E-QINU`"'

This is a deprecated template. Help us update this template!

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.

Collapse
CodeMenu after boot

'"`UNIQ--pre-00000011-QINU`"'

This is a deprecated template. Help us update this template!

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

Nota
Apresentado apenas para deixar este documento completo. É recomendado que os usuários instalem o arcload em vez de usar este método.
Nota
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.

Nota
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 -R /mnt/gentoo
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.