O processo de boot e os arquivos de inicialização Entendendo como o Linux funciona

Quando você liga o micro, o primeiro software que é carregado é o BIOS da placa mãe, que faz a contagem da memória RAM, uma detecção rápida dos dispositivos instalados e por fim carrega o sistema operacional principal a partir do HD, CDROM, disquete, rede, ou o que seja. Este procedimento inicial é chamado de POST (Power-on self test).

Seria bom se a função do BIOS se limitasse a isso, mas na verdade ele continua residente, mesmo depois que o sistema operacional é carregado.

Na época do MS-DOS era bem conhecida a divisão entre memória real (os primeiros 640 KB da memória RAM) e memória extendida (do primeiro MB em diante, englobando quase toda a memória instalada). O MS-DOS rodava em modo real, onde o processador trabalha simulando um 8088 (o processador usado no XT) que era capaz de acessar apenas 640 KB de memória. Mesmo os processadores modernos conservam este modo de operação, mas os sistemas operacionais modernos rodam inteiramente em modo protegido, onde são usados todos os recursos da máquina.

O espaço entre os primeiros 640 KB, onde termina a memória real e os 1024 KB onde começa a memória extendida é justamente reservado para o BIOS da placa mãe. Ele é originalmente gravado de forma compactada num chip de memória flash instalado na placa mãe e fica descompactado neste espaço reservado (chamado de shadow RAM) durante o uso.

O BIOS oferece funções prontas para acessar o HD, acionar recursos de gerenciamento de energia e muitas outras coisas. Mas, os sistemas operacionais quase não utilizam estas funções, pois existem muitas diferenças na forma como BIOS de diferentes placas mãe trabalham, e em muitos casos as funções simplesmente não funcionam ou produzem erros inesperados.

Os fabricantes de placas mãe disponibilizam upgrades de BIOS freqüentemente para corrigir estes problemas, mas a maior parte dos usuários nem chega a procura-los. Fazendo com que exista um enorme contingente de placas bugadas por aí, com problemas no ACPI, DMA e outros outros recursos básicos.

Existe até mesmo um projeto para substituir o BIOS da placa mãe por uma versão compacta do Kernel do Linux, que executa as mesmas funções, mas de uma forma mais confiável e flexível: http://www.linuxbios.org/

De qualquer forma, depois de fazer seu trabalho, o BIOS carrega o sistema operacional, lendo o primeiro setor do disco rígido o "Master Boot Record" (MBR), também conhecido como trilha zero ou trilha MBR.

No MBR vai o gerenciador de boot. Os dois mais usados no Linux são o lilo e o grub.

Na verdade, no MBR mesmo vai apenas um bootstrap, um pequeno software que instrui o BIOS a carregar o executável do lilo ou grub em um ponto específico do HD. Lembre-se que o MBR propriamente dito ocupa um único setor do HD, apenas 512 bytes. Não é possível armazenar muita coisa diretamente nele.

O gerenciador de boot utiliza os primeiros 446 bytes do MBR. Os 66 bytes restantes são usados para armazenar a tabela de partições, que guarda informações sobre onde cada partição começa e termina. Alguns vírus e acidentes em geral podem danificar os dados armazenados na tabela de partição, fazendo com que pareça que o HD foi formatado, mas na maioria dos casos os dados continuam lá.

Voltando ao tema inicial, o gerenciador de boot tem a função de carregar o kernel e, a partir dele todo o restante do sistema. O lilo e o grub podem ser configurados ainda para carregar o Windows ou outros sistema instalados em dual boot. Muitas distribuições configuram isso automaticamente durante a instalação.

Inicialmente, o kernel é um arquivo compactado e somente-leitura, o arquivo /boot/vmlinuz. Ele é descompactado em uma área reservada da memória RAM e roda a partir dalí, aproveitando o fato de que a memória RAM é muito mais rápida que o HD.

Este executável principal do kernel nunca é alterado durante o uso normal do sistema, ele muda apenas quando você recompila o kernel manualmente ou instala uma nova versão.

Se você prestou atenção quando citei a necessidade de usar um initrd quando a partição raiz do sistema está formatada num sistema de arquivos que não está compilado diretamente no kernel, deve ter notado uma contradição aqui. Afinal é o que está sendo feito até agora.

Nem o BIOS, nem o lilo possuem suporte a reiserfs e o Kernel precisa ser carregado antes que ele tenha a chance de carregar o initrd. E além do mais, para carregar o initrd, o próprio Kernel precisa ler o arquivo dentro da partição.

Isto tudo funciona por que tanto o BIOS quanto o lilo não procuram entender o sistema de arquivos em que o HD está formatado. Pode ser EXT2, ReiserFS, XFS, ou o que seja, para eles não faz diferença. Eles simplesmente leêm os uns e zeros gravados numa área específica do HD e assim carregam o kernel e o initrd. Eles não fazem alterações nos dados gravados, por isso este "acesso direto" não traz possibilidade de danos às estruturas do sistema de arquivos.

Depois de carregado, a primeira coisa que o kernel faz é montar a partição raiz, onde o sistema está instalado, inicialmente como somente leitura. Neste estágio ele carrega o init, o software que inicia o boot normal do sistema, lendo os scripts de inicialização e carregando os módulos e softwares especificados neles.

O arquivo de configuração do init é o /etc/inittab. Ele é geralmente o primeiro arquivo de configuração lido durante o boot. A principal tarefa dele é carregar os demais scripts de inicialização, usados para carregar os demais componentes do sistema e fazer todas as operações de checagem, necessárias durante o boot.

No /etc/inittab do Debian por exemplo, você verá a linha:

# Boot-time system configuration/initialization script. si::sysinit:/etc/init.d/rcS

Esta linha executa o script /etc/init.d/rcS. Se você examiná-lo também, vai encontrar o seguinte:

for i in /etc/rcS.d/S??*
do
...
$i start
....
done

Os "..." indicam partes dos script que removi para deixar apenas as partes que interessam aqui. Estas linhas são um shell script, que vai executar os scripts dentro da pasta /etc/rcS.d. Esta pasta contém scripts que devem ser executados sempre, a cada boot e são responsáveis por etapas fundamentais do boot.

Alguns exemplos de scripts e programas que são executados nesta etapa são:

• keymap.sh: Carrega o layout do teclado que será usado no modo texto. Você não gostaria que seu teclado estivesse com as teclas trocadas para o Russo quando precisar arrumar qualquer coisa no modo texto, não é? ;-) O KDE possui um configurador próprio, o kxkb, que é configurado dentro do painel de controle. O layout usado pelo kxkb subscreve o configurado pelo keymap.sh

• checkroot.sh: Este script roda o fsck, reiserfsck ou outro programa adequado para verificar a estrutura da partição raiz (a partição onde o sistema está instalado), corrigindo erros causados por desligamentos incorretos do sistema. Este processo é análogo ao scandisk do Windows. Só depois da verificação é que a partição raiz passa a ser acessada em modo leitura e escrita.

• modutils: Este é o script que lê os arquivos /etc/modules e /etc/modules.conf, ativando a placa de som, rede e todos os outros dispositivos de hardware "não essenciais", para os quais o suporte não foi habilitado diretamente no Kernel.

• checkfs.sh: Este script é parecido com o checkroot.sh, ele se destina a checar as demais partições do HD.

• mountall.sh: É aqui que é lido o arquivo /etc/fstab e as demais partições, unidades de rede e tudo mais que estiver especificado nele é ativado. Se você estiver usando uma partição home separada ou um compartilhamento de rede via NFS para guardar arquivos, por exemplo, é a partir deste ponto que eles ficarão disponíveis.

• networking: Ativa a rede, carregando a configuração de IP, DNS, gateway, etc. ou obtendo a configuração via DHCP. A configuração da rede é geralmente armazenada dentro da pasta /etc/sysconfig/network-scripts/ ou no arquivo /etc/network/interfaces.

De acordo com a distribuição usada, são carregados neste ponto outros serviços, para ativar suporte a placas PCMCIA, placas ISA, ou outros tipos de hardware, ativar o suporte a compartilhamentos de rede e assim por diante. É possível executar praticamente qualquer tipo de comando ou programa nesta etapa, justamente por isso os passos executados durante o boot mudam de distribuição para distribuição, de acordo com o que os desenvolvedores consideram mais adequado. A idéia aqui é apenas dar uma base, mostrando alguns passos essenciais que são sempre executados.

Depois desta rodada inicial, são executados os scripts correspondentes ao runlevel padrão do sistema, que é configurado no /etc/inittab, na linha:

# The default runlevel.
id:5:initdefault:

O número (5 no exemplo) indica o runlevel que será usado, que pode ser um número de 1 a 5. Cada runlevel corresponde a uma pasta, com um conjunto diferente de scripts de inicialização. É uma forma de ter vários "profiles", para uso do sistema em diferentes situações.

A configuração mais comum é a seguinte:

• Runlevel 1 - Single user. É um modo de recuperação onde nem o modo gráfico, nem o suporte a rede, nem nenhum outro serviço "não essencial" é carregado, de forma a minimizar a possibilidade de problemas. A idéia é que o sistema "dê boot" para que você possa corrigir o que está errado. Atualmente, uma forma mais prática para corrigir problemas é dar boot com uma distribuição em live-CD (como o Kurumin), onde você tem acesso à internet e vários programas, montar a partição onde o sistema está instalado e corrigir o problema a partir daí.

• Runlevel 3 - Boot em modo texto. Neste modo todos os serviços são carregados, com exceção do gerenciador de boot (KDM ou GDM), que é responsável por carregar o modo gráfico. Este modo é muito usado em servidores.

• Runlevel 5 - É o modo padrão na maioria das distribuições, onde você tem o sistema "completo", com modo gráfico e todos os demais serviços. Uma exceção importante é o Slackware, onde o modo gráfico é carregado no runlevel 4.

Por exemplo, usando o runlevel 5, são carregados os scripts dentro da pasta /etc/rc5.d, enquanto que usando o runlevel 3, são carregados os scripts dentro da pasta /etc/rc3.d. Nada impede que você modifique a organização dos arquivos manualmente, de forma a fazer o X carregar também no runlevel 3, ou qualquer outra coisa que quiser. São apenas pastas com scripts e links simbólicos dentro, nenhuma caixa preta.

Página 04 de 07   ApresentaçãoOs componentes do sistemaMódulos O processo de boot e os arquivos de inicialização Ativando e desativando serviçosXA árvore genealógica das distribuições

Blog:
	» Gostou do texto? Veja nossos livros impressos: Hardware | Redes | Servidores | Kurumin 7 ... ou encontre o que procura usando a busca: