Manual:MIPS/Instalaçã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 dvhtoolDepois 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 sashARCSPara usuários Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000:
root #dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64O 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.
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 newCoLo 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/coloCom 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.gzConfigurando 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.
default.coloUm exemplo de configuração do CoLo#: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).
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.
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:
/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.
/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/securettyEm outro momento, o Linux também chama a linha de /dev/tts/0 -- então a adicionamos também:
root #echo 'tts/0' >> /etc/securettyAjustando 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 YesConfigure a zona horária:
>>setenv TimeZone BRTUse o console serial - usuários de adaptador gráfico devem usar "g" em vez de "d1":
>>setenv console d1Ajuste 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 9600Agora, 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 roConfiguraçõ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 sash64Usa 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 #exitcdimage ~#cd
cdimage ~#umount -l /mnt/gentoo/dev{/shm,/pts,}
cdimage ~#umount /mnt/gentoo{/boot,/sys,/proc,}
cdimage ~#rebootClaro, 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.