Opa! Lá vamos nós para mais um tópico a ser discutido para a prova 201. E hoje eu irei falar sobre o Sistema de Inicialização do Linux. Mas antes, para quem tiver curiosidade, segue o link do livro que estou utilizando como guia em meus estudos.

Novamente digo: se alguém ler este texto e encontrar algo que discorde, não tenha entendido, ou apenas um erro gramatical e queira corrigir, pois fique a vontade para corrigir! Devido à própria característica do texto, que é redigido e publicado no mesmo dia, eu posso cometer enganos.

Vamos ao que interessa afinal! Neste segundo post, irei tratar dos seguintes objetivos de prova:

• Customizar o Sistema de Inicialização e os processos de boot
• Realizar a recuperação de um sistema

Objetivo 1: Customização do Sistema de Inicialização e Processos de Boot

Irei pressupor que conceitos como scripts de inicialização, parâmetros de boot e como modificar o nível de execução do Init já são conhecidos pelos leitores. Na prova 201 é cobrada a customização dos processos de inicialização.

Quando o kernel monta o sistema de arquivos raíz, ele executa o /sbin/init. Este programa irá ler o arquivo /etc/inittab que irá definir tudo que ele terá que fazer de agora em diante.

/etc/inittab

O arquivo /etc/inittab descreve quais, como e quando os processos serão executados durante o boot do sistema. Na LPI, tanto a LPIC-1 como a LPIC-2, são cobrados tópicos abordando o sistema de inicialização System V, que é hoje utilizado na maior parte das distribuições Linux. O System V define que existem 7 níveis de execução.

• 0 – Sistema desligado
• 1 – Sistema mono-usuário
• 2 – Sistema multi-usuário sem acesso a recursos de rede
• 3 – Sistema multi-usuário com acesso a recursos de rede
• 4 – Não padronizado/utilizado
• 5 – Sistema multi-usuário com acesso a recursos de rede e ambiente gráfico
• 6 – Sistema em modo de reinicialização

Em um sistema Debian, este padrão é seguido. Basicamente existe um modo mono-usuário (nível 1), um modo padrão (nível 2) e outros níveis em modo multi-usuário (níveis 3 a 5). Os níveis 0 e 6 permanecem com o mesmo sentido em ambos os sistemas.

No arquivo /etc/inittab a primeira informação obtida é o nível de execução padrão para quando a máquina está sendo inicializada. O nível padrão é obtido através do trecho do arquivo abaixo.

id:3:initdefault:

Depois que o nível de execução é carregado, é possível modificá-lo através dos comandos executados como root: init ou telinit. Sendo que o segundo é um link simbólico para o primeiro.

Continuando com a descrição do arquivo, existe outro trecho que merece especial atenção.

si::sysinit:/etc/rc.d/rc.sysinit

Essa linha indica qual o script de inicialização que o init utilizará para realizar as primeiras verificações em seu sistema. Antes mesmo que os scripts do nível sejam executados, o arquivo /etc/rc.d/rc.sysinit será. Esse script será executado em todos os níveis, pois não existe entre os sinais “::” algum número de identificação para o nível. Debian também utiliza um sistema de inicialização nos níveis, porém, em vez de utilizar um único arquivo, como o RedHat, ele utiliza um diretório contendo diversos scripts, assim como nos níveis de execução. Sendo assim, podemos dizer que o script do RedHat é monolítico e do Debian modular. Falaremos com mais detalhes depois sobre estes scripts.

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

Essas linhas, identificadas por “l0” até “l6”, levam o Init a executar os scripts presentes no nível de destino. Os scripts estão localizados em /etc/rc.d/rcX.d, sendo “X” o número do nível.

As próximas linhas no arquivo definem ações para interrupções comuns geradas no teclado, como a sequência de teclas Ctrl+Alt+Del ou a reação do sistema no caso de falha do UPS (Uninterruptile Power Supply) de abastecimento de energia do sistema.

pf::powerfail:/sbin/shutdown -f -h +2 “Power Failure; System Shutting Down”
pr:12345:powerokwait:/sbin/shutdown -c “Power Restored; Shutdown Cancelled”

No exemplo acima, ao detectar uma falha no suprimento de energia do UPS, o sistema irá realizar o desligamento do sistema em dois minutos com a mensagem “Power Failure; System Shutting Down”. Porém, se o suprimento de energia for reestabelecido e ainda estivermos em algum dos níveis de 1 à 5, então o desligamento agendado será cancelado.

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

A linha acima indica que caso seja pressionada a seqüência de teclas Ctral+Alt+Del, será realizado um desligamento do sistema no mesmo instante.

1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

Com estas linhas acima, é configurada a utilização de seis terminais virtuais de acesso. mingetty é a aplicação responsável por realizar a autenticação dos usuários em uma interface Modo Texto. Para adicionar ou remover os terminais disponíveis aos usuários, basta criar ou remover alguma das linhas. Repare que a numeração “2345” indica que apenas nos níveis 2, 3, 4 e 5 estes terminais estarão disponíveis.

Scripts de Inicialização do Sistema

Como todos sabem, os scripts de inicialização dos daemons estão sob o diretório /etc/init.d. Esses scripts são executados pelos links simbólicos localizados nos diretórios correspondentes ao nível de execução ou nos scripts de inicialização, que são chamados /etc/rc.d/rc.sysinit no RedHat e /etc/init.d/rcS no Debian.

No Debian, o script /etc/init.d/rcS irá realizar a execução de todos os links simbólicos de /etc/rcS.d. No RedHat, apenas o arquivo /etc/rc.d/rc.sysinit é executado. Talvez nunca iremos analisá-lo completamente, pois o mesmo possui mais de 900 linhas. A finalidade básica destes scripts é realizar uma checagem de todos os sistemas de arquivos locais. Se existir um problema durante a checagem, o script tentar realizar uma manutenção automática. Porém, se o script precisar de interação, ele resultará na execução de um shell sulogin, que irá lhe questionar pela senha do administrador root. No entanto, dependendo da gravidade do problema, o sistema pode simplesmente realizar uma reinicialização automática.

Uma das desvantagens do modo mono-usuário, ou mesmo no shell sulogin, é que, para que seja possível executá-lo, todos os sistemas de arquivos são montados e o sistema operacional deverá estar quase completamente carregados, o que pode não ser possível em uma situação de emergência.

Estes scripts também são responsáveis por realizar a habilitação das cotas no disco, caso estas estejam configuradas.

Após a execução dos scripts rcS no Debian ou rc.sysinit no RedHat, serão então executados os links simbólicos contidos nos diretórios /etc/rcX.d, onde novamente “X” será o número referente ao nível que estou executando.

Customizando os Níveis de Execução

Em algum momento, pode ser necessária a adição de novos serviços (ou também chamados de daemons) durante o processo de inicialização do sistema. Poderá ser feito de maneira manual, através da criação de links simbólicos nos diretórios adequados utilizando o padrão de nomes para os links. Porém, existem algumas ferramentas de auxílio à criação e manutenção dos serviços. Estas ferramentas diferem das distros Debian e RedHat. Vamos comentar um pouco sobre cada uma das ferramentas.

chkconfig

Sintaxe:

chkconfig –list [serviço]

chkconfig –add serviço

chkconfig –del serviço

chkconfig [–level nível] serviço [on | off | reset]

O comando chkconfig é uma maneira simples e fácil de realizar a customização dos serviços existentes em cada um dos níveis. Utilizado normalmente no RedHat ou distros similares. Seu uso é condicionado a uma prévia configuração do script de inicialização em /etc/init.d. Este script deverá possuir comentários específicos para tratamento do chkconfig. Observe o exemplo abaixo de comentários do chkconfig em um serviço.

# chkconfig: 345 13 87
# description: named (BIND) is a Domain Name Server (DNS) \
# that is used to resolve host names to IP addresses.

As linhas acima indicam seqüencialmente que o serviço (named) será executado nos níveis 3, 4 e 5, possui prioridade de inicialização 13 e de finalização 87. A próxima linha é apenas uma descrição do serviço que poderá utilizar uma única ou várias linhas, desde que no final de cada uma delas haja uma contra-barra.

Exemplos de uso:

# chkconfig –add named

# chkconfig –list named

# chkconfig named off

O primeiro comando irá adicionar o serviço named. O segundo comando irá listar todos os níveis e se está sendo executado ou não o serviço named. O último comando irá desativar o serviço named de todos os níveis.

update-rc.d

Sintaxe:

update-rc.d [-n] [-f] serviço remove

update-rc.d [-n] serviço defaults [nn | nn-start nn-stop]

update-rc.d [-n] serviço start | stop nn nível-de-execução nível-de-execução … [start | stop nn nível-de-execução nível-de-execução … ]

Debian e outras distribuições utilizam o update-rc.d para manipular os serviços em cada um dos níveis. Qualquer script localizado em /etc/init.d pode ser manipulado por este comando, porém, ele apenas adiciona ou remove serviços, não podendo realizar a manutenção dos mesmos.

Exemplos de uso:

# update-rc.d mysql defaults 99

# update-rc.d -f mysql remove

# update-rc.d mysql stop 99 0 1 6 . start 60 2 3 4 5 .

O primeiro comando adiciona o serviço mysql nos níveis padrões (1, 2, 3, 4 e 5) para inicialização e insere links para sua desativação nos outros níveis, todos com prioridade 99. O segundo comando irá remover todos os links simbólicos do serviço mysql. O terceiro comando irá adicionar o serviço mysql para ser paralisado nos níveis 0, 1 e 6 com prioridade 99 e ser inicializado com prioridade 60 nos níveis 2, 3, 4 e 5.

Customizando Imagens Initrd

No post anterior, discutimos como realizamos a geração das imagens Initrd. Hoje em dia, distros mais novas não utilizam mais esse tipo de imagem, sendo que o novo padrão adotado chama-se Initramfs. Na LPIC-2 é cobrada o uso da Initrd, presente apenas em antigas versões das distribuições. Vamos entender melhor como esta imagem funciona. Ela, ao contrário do que pode ter sido entendido no post anterior, não é apenas uma RAM disk contendo alguns módulos, ela é praticamente um sistema raíz independente. Os módulos são carregados por um script ou executados direto do disco. Segue abaixo uma ordem como as coisas acontecem em toda a existência da Initrd.

1. O gerenciador de boot carrega o kernel e a Initrd em memória.
2. Na inicialização, o kernel descompacta e copia o conteúdo da Initrd no dispositivo /dev/ram0 e então livra a memória utilizada pelo Initrd. Este processo é o que chamamos de transformar a Initrd em um RAM disk.
3. O kernel monta como leitura e escrita o dispositivo /dev/ram0 sendo a raíz do sistema.
4. O arquivo /linuxrc é executado. Este arquivo pode ser um executável qualquer, ou mesmo um shell script. É executado como root e pode fazer tudo que o init pode fazer.
5. /linuxrc monta o sistema raíz verdadeiro.
6. /linuxrc coloca o sistema raíz real no diretório raíz usando o comando pivot_root.
7. A sequência de boot normal é executada no sistema de arquivo raíz.
8. O sistema de arquivo da Initrd é removido.

Documentação adicional sobre o funcionamento da imagem Initrd pode ser obtida no diretório Documentation/initrd.txt na árvore do fonte do kernel ou analisando o próprio executável /linuxrc que no Debian e RedHat é um script.

Initrd e /linuxrc no Debian

No Debian, o script /linuxrc é interpretado pelo dash, ou mais comum, ash. Estes interpretadores oferecem um bom conjunto de comandos built-in. Quando o script /linuxrc é executado, ele lê configurações do arquivo /linuxrc.conf que foi escrito pelo comando mkinitrd no momento da criação da imagem Initrd.

O script /linuxrc do Debian não executa o comando pivot_root como deveria. O que acontece na verdade é que ao detectar que o script /linuxrc foi terminado, o kernel executa o /sbin/init, que apesar de estar no mesmo local que seu xará, ele não é o binário a que estamos acostumados (lembrem-se que até aqui o sistema raiz verdadeiro ainda não foi montado). Esse init irá realizar a execução dos scripts do diretório /scripts na ordem. Depois disso, ele irá finalmente realizar a execução do pivot_root para a mudança da raíz do sistema.

Initrd e /linuxrc no RedHat

RedHat realiza a criação do seu script /linuxrc dinamicamente, linha a linha. A customização neste ambiente não é tão simples como no Debian, pois poucas ferramentas são providas para uso. O shell utilizado é o /bin/nash, que não é “linkado” estaticamente. Neste ambiente existem apenas as ferramentas necessárias para o Initrd, nada muito além disso.

Objetivo 2: Recuperação do Sistema

Infelizmente nem tudo vai tão bem quanto deveria. Porém, felizmente o sistema é capaz de se recuperar na maior parte das vezes de maneira automática. Como por exemplo, os sistemas de arquivos são consertados/verificados a cada boot. Mas, existem problemas não muito freqüentes que irão precisar da intervenção humana.

Problemas no Sistema de Inicialização

Quando ocorrem problemas na execução de algum dos níveis de execução do init, isto normalmente é fácil de resolver. Nessas situações, ao ocorrer o erro o sistema nos levará para shell com acesso root mediante a senha do mesmo, como mostrado abaixo.

Give root password for maintenance
(or type Control-D to continue):

Na maior parte das situações, bastará executar o utilitário fsck com os parâmetros necessários, e os danos ao sistema de arquivo serão corrigidos.

No entanto, existem outras situações que o problema se dará durante a execução dos primeiros scripts do init (/etc/rc.sysinit ou /etc/init.d/rcS). Nestes casos, talvez não seja possível ter acesso ao disco rígido. Para tanto, podemos realizar um “bypass” no init, ou seja, fazer com que sua execução seja substituída por outra ferramenta. Para tanto, basta modificar o gerenciador de boot durante a inicialização. Considere o exemplo abaixo.

title Fedora Core (2.6.20-1.2925.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.20-1.2925.fc6 ro root=LABEL=/ rhgb quiet
initrd /initrd-2.6.20-1.2925.fc6.img

Para indicar ao kernel que será utilizado outro init, basta adicionar a linha init=executável indicando o caminho absoluto do novo inicializador do sistema. O exemplo acima ficaria então como mostrado abaixo.

title Fedora Core (2.6.20-1.2925.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.20-1.2925.fc6 ro root=LABEL=/ rhgb quiet init=/bin/bash
initrd /initrd-2.6.20-1.2925.fc6.img

No exemplo acima, chamaremos o /bin/bash em vez do /sbin/init, como seria feito normalmente. Fazendo isto, não serão executados os scripts do init, que por sua vez, não realizarão a execução dos scripts /etc/rc.sysinit ou /etc/init.d/rcS. Sendo assim, teremos acesso à um terminal de comandos bash onde poderemos realizar a execução de rotinas de manutenção e recuperação. Precisamos apenas ficarmos ciente de que só haverá este terminal de execução de comandos e que não haverá interrupções de finalização geradas pelo teclado, como Ctrl+C ou Ctrl+Z.

Agora, se seu sistema nem desta maneira está conseguindo ser recuperado, a única possibilidade que temos agora é a realização do boot por outro sistema operacional, através normalmente de um CD de recuperação. Esse CD de recuperação poderá ser o mesmo para a instalação da sua distro Linux, como no caso do RedHat ou outra mídia específica para este fim, como o Ubuntu Alternative CD.

Problemas no Gerenciador de Boot

Outra possibilidade de problema com que podemos nos deparar é a danificação do gerenciador de boot de seu sistema. Para proceder com a recuperação é simples. Iremos fazer o mesmo passo explicado anteriormente fazendo uso do CD de recuperação. Após isto, em um terminal de comandos, iremos realizar os comandos abaixo.

# chroot /onde-esta-montado-minha-raiz-real

A partir deste momento, devemos levar em consideração qual o gerenciador de boot utilizado. No caso do GRUB, basta o comando abaixo para realizar a reinstalação do mesmo na MBR.

# grub-install /dev/sda

Considerando que o disco rígido em questão é o primeiro Serial ATA ou SCSI. Porém, se seu gerenciador de boot for o LILO, basta o comando abaixo.

# lilo -v

Podemos realizar a recuperação da MBR de seu sistema caso haja um backup previamente criado. Portanto, para recuperá-lo, basta o comando abaixo.

# dd bs=512 if=mbr.backup of=/dev/sda

Não existe uma receita de bolo para todos os problemas existentes, sendo assim, muitas outras possibilidades de erros e suas soluções não estão englobadas aqui, mas com estas informações, acho que podemos ter um bom início.

Concluindo

Bem, terminando mais este post sobre outro tópico da prova 201 da LPIC-2, espero que tenham gostado do conteúdo. Novamente, se tiverem alguma dúvida, crítica ou sugestão de inclusão de algo no post, podem ficar a vontade para se expressar!

No próximo post irei falar sobre Sistemas de Arquivos. Espero poder postá-lo o quanto antes, ou seja, assim que tiver um tempinho para isso! 🙂

Até mais e valeu pelo apoio! 😀