# Linux - Guia prático para administradores de sistemas/Inicialização do sistema
## Objetivo

O propósito deste capítulo é explicar como um servidor utilizando o GNU/Linux é inicializado desde a etapa de inicialização do hardware, até o momento que o processo init é inicializado, os scripts de inicialização são executados e o servidor esteja completamente operacional, o processo getty iniciado à espera de logins.

## Inicializando o Sistema

O processo de inicialização de sistemas, independentemente do sistema operacional, depende em muito do tipo de hardware em uso. Em dispositivos baseados na arquitetura x86 (intel) quando o computador é inicializado ou reinicializado o processador (CPU) executa uma operação em uma área ( endereço ) conhecido na memória não volátil (flash RAM).
No caso de PCs (Personal Computers) baseados na arquitetura x86, o processo de inicialização (boot) se inicia na BIOS, no endereço 0xFFFF0. O primeiro passo da BIOS é executar o Power On Self Test (POST) que tem como principal função a verificação do hardware e a enumeração e inicialização dos dispositivos locais.
Para inicializar o sistema operacional, a BIOS irá então procurar por dispositivos ativos e válidos que estejam listados (em ordem de preferência) na CMOS (boot device). Os dispositivos de boot podem ser floppy disks, hard disks, flash drivers, dispositivos de rede, etc.
De maneira geral, o Linux é inicializado a partir de um disco rígido, onde a MBR ( Master Boot Record ) contém o boot loader, mas não o kernel. A MBR é apenas um setor de 512 bytes, localizado no cilindro 0, setor 1 do seu disco rígido, e portanto não teria condições de abrigar um kernel Linux, mesmo que comprimido. Portanto na MBR apenas reside o suficiente para carregar o primeiro estágio do boot loader.

## Boot Loader - Estágio 1

O primeiro estágio do boot loader, ou primary boot loader, localizado nos setores restantes do primeiro cilindro. A única função do primary boot loader é encontrar o secondary boot loader, ou o segundo estágio do boot loader, e carregá-lo na memória. O objetivo do primeiro estágio é usar um programa pequeno que lê em um unico sistema de arquivos. No GRUB esse estágio é conhecido como 1.5 o e o estágio 1 é o código que é escrito no MBR .

## Boot Loader - Estágio 2

O segundo estágio de boot tem como função carregar o kernel do Linux na memória, e opcionalmente um arquivo que simula a memoria RAM (RAM image file).
Os 2 estágios do boot loader combinados formam o LILO ( Linux Loader ) ou o GRUB ( GRand Unified Bootloader ). Iremos nos focar no GRUB, devido ao fato deste ser um gerenciador de boot mais novo, e que corrigiu algumas das falhas do LILO.
No estágio 2 é possível listar e escolher entre diversos tipos de kernel instalados (definidos em /boot/grub/menu.lst), e inclusive passar parâmetros de boot durante a inicialização do sistema.
Quando o segundo estágio estiver carregado na memória o sistema de arquivos é consultado, a imagem do kernel e a imagem initrd são carregados na memória, e quando esse processo é concluído, o boot loader invoca o kernel.

## Carregando o Kernel

A imagem do kernel não é propriamente um executável, porém contém uma série de rotinas que permitem que o kernel que se encontra comprimido (zlib) seja expandido, e carregado na memória.
Não pretendemos aqui esmiuçar todas as etapas desse processo, no entanto é importante notar que durante a carga do kernel, a ram image que foi carregada durante o estágio 2 do boot loader é montado temporariamente como root file system, contendo todos os drivers necessários para que o kernel tenha acesso aos diversos dispositivos que ele precise.
Esse mecanismo permite que tenhamos imagens de kernel pequenas, e device drivers compilados como módulos e carregados, quando necessários, através de um arquivo que pode ser montado como um sistema de arquivos existente apenas na memória. Tal artifício permite que o kernel seja completamente carregado sem que um disco físico seja de fato acessado. Em uma etapa futura da carga do kernel, esse sistema de arquivos temporários será substituído pelo root file system padrão.
Esse mecanismo garante uma grande flexibilidade a sistemas Linux uma vez que permite inclusive que o próprio root file system resida em um servidor remoto (NFS).

## Threads do Kernel

Após a inicialização básica, o kernel cria também vários processos no espaço de usuário. Estes aparecem na listagem de diretórios entre colchetes, a exemplo do [kswapd], [kjournald], etc. Destes processos que aparecem no inicio da listagem de processos, normalmente com números identificadores baixos, 1 (init), 2, 3..., apenas o init é um processo de usuário completo, os demais são na verdade partes do kernel que por razões de escalonamento foram organizados para se parecer com processos. Assim que as threads do kernel são criadas, o papel destes na inicialização termina, e o processo de ativação de todos os outros serviços fica a cargo do init através de scripts de inicialização.
A nomenclatura do processo na coluna CMD corresponde a [NomeDoProcesso/Numero], onde Numero significa o processador em que o processo está alocado.

## O Processo INIT

Após a carga e inicialização, o kernel inicia o primeiro programa em user space. Até esse momento, nenhuma outra aplicação baseada em blibliotecas padrão C é executada.
De modo geral, em desktops e servidores linux padrão, após a carga do kernel, o programa /sbin/init é executado, porém isso não é obrigatório. Dispositivos embarcados, por exemplo, não requerem uma inicialização extensiva através do init. É possível por exemplo, após a inicialização do kernel, iniciar um utilitário shell e a partir deste iniciar os processos necessários.
O arquivo de configuração que determina o funcionamento do processo init é o /etc/inittab, entretando pelo fato desse arquivo não ter uma sintaxe fácil de compreender, as distribuições Linux atuais utilizam-se deste para, a partir de um processo (/etc/init.d/rc), determinar o conjunto de scripts que deverão ser executados, dependendo do runlevel escolhido.
Por padrão esses scripts são armazenados sob a estrutura de diretórios /etc/rc.d/rc[0-6,S].d/ e são na verdade scripts simples, baseados em sh (base na verdade) com a função de além de realizar configurações simples durante o processo de boot (hostname, endereço ip, rotas, etc) também são responsáveis por iniciar, parar e reiniciar os daemons que devem ficar em execução no servidor.
No decorrer do processo init, o programa getty é invocado e executado a partir do arquivo de configuração /etc/inittab com a finalidade de abrir conexões ttys (sejam dispositivos reais ou virtuais localizados em /dev) como por exemplo: consoles virtuais, portas seriais, portas do modem, dentre outros, e iniciar a autenticação do usuário chamando o processo login, o qual fica no estado de espera, aguardando o nome do usuário e senha. Caso as informações estejem corretas, uma conexão tty será liberada para o usuário autenticado.

## Níveis de Execução (runlevel)

0 - Nível em que o sistema está completamente desligado
1 ou S - representa o modo de monousuário
2 - Primeiro modo multiusuário (sem rede)
3 - Modo multiusuário
4 - Não Usado ( "definível" )
5 - Modo multiusuário (X11)
6 - Reboot (Nível onde o sistema ficará reinicializando)

## GRUB : O GRand Unified Boot Loader

O GRUB é o gerenciador de boot mais popular nos dias atuais, e também o padrão das maiores distribuições Linux existentes ( Suse, RedHat, Fedora ). A vantagem mais perceptível do GRUB é que ele transformou o processo usual de 2 estágios em um processo de 3 estágios (1, 1.5 e 2), onde no estágio intermediário ( 1.5 ) o boot loader toma conhecimento do sistema de arquivos onde o kernel reside e não mais acesso a um setor "raw" do disco rígido. Não requer, como o LILO, que o setor de boot seja atualizado a cada modificação no arquivo de configuração. Após o GRUB ser instalado no setor de boot (MBR) com o comando grub-install o seu arquivo de configuração será lido a cada inicialização, o que garante uma maior flexibilidade a esse gerenciador de boot.
O GRUB não faz distinção entre discos IDE e SCSI, ou seja, existe uma referência na ordem de como os discos são reconhecidos na BIOS influenciando na nomenclatura dos dispositivos válidos no GRUB, por exemplo, se um servidor tiver 02 discos rígidos IDE, 01 SCSI e 01 floppy disk, o GRUB identificará da seguinte forma:
--> Primeiro disco: IDE ( hd0 )
--> Segundo disco: IDE ( hd1)
--> Terceiro disco: SCSI ( hd2 )
--> Floppy Disk: ( fd0 )
Nesse exemplo, caso o segundo disco tenha 02 partições, a representação pelo GRUB será: (hd1,0) e (hd1,1).
Como instalar o GRUB no disco master da controladora IDE primária?
Exemplo de um arquivo de configuração GRUB (/boot/grub/grub.conf)

## Scripts de Inicialização

Exemplo do script de inicialização do sshd:
Observação: O campo # Default-Start, no exemplo abaixo, significa que os valores padrões para a inicialização do serviço de sshd pelo script de inicialização, serão os níveis de execução 3 e 5. No campo # Default-Stop, informa que esse serviço estará parado quando os níveis de execução forem 0, 1, 2 e 6.

## Ativando , desativando e listando scripts de inicialização

Para listar os scripts passíveis de utilização, ativos ou não basta usar o seguinte comando:
Ativando e desativando o serviço sendmail: