Manual:MIPS/Blocos/Bootloader

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:MIPS/Blocks/Bootloader and the translation is 72% complete.
Outdated translations are marked like this.


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

FILE arc.cfUm arc.cf exemplo
# 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.

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

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.
FILE default.coloUm exemplo de configuração do CoLo
#:CoLo:#
mount hda1
load /kernel.gz.working
execute root=/dev/sda5 ro console=ttyS0,115200
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).

FILE default.coloConfiguração baseada em menu
#: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.

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:

FILE /etc/inittabTrecho do arquivo inittab
# 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.

FILE /etc/inittabTrecho de exemplo do inittab
# 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.

CODE Menu after boot
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

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]


Retrieved from "https://wiki.gentoo.org/index.php?title=Handbook:MIPS/Blocks/Bootloader/pt-br&oldid=1279492"