Componente Tecnológica

Formador: Ricardo Sousa

Ano Letivo 2018/2019

Informação retirada do livro:

LINUX – 6ª Edição – Curso Completo – FCA Editora
Tecnologias Informáticas – 12ª - Porto Editora
Conceitos básicos
Noção de Sistema Operativo
Vamos apreciar mais tarde, com mais pormenor, a caracterização de um Sistema
Operativo em geral. Para já importa uma ideia muito simples, que nos explicite quer a
sua constituição quer as suas funções essenciais. O sistema operativo não é mais do que
um conjunto de programas que faz a gestão dos recursos físicos e lógicos, e das
operações fundamentais de um sistema de computação. É habitual considerarem-se
como principais funções de um Sistema Operativo:

• Gestão de operações de I/O

• Administração da memória
• Diagnóstico e correção de erros
• Controlo de segurança
• Criação e manutenção de ficheiros
Veremos cada uma destas funções de per si, ficando para já com a ideia de que o seu
conjunto é responsável por o utilizador não ter necessidade de recorrer a operações que
façam a gestão do equipamento e dos suportes de informação, bem como do modo
como é feita a gestão da memória (ou melhor dizendo, das memórias) do sistema para
cada situação em concreto da sua utilização.
Os sistemas operativos, estruturalmente, são constituídos por três conjuntos de
componentes:
✓ uma interface com o utilizador, que pode ser através de linha (CLI) de comando
ou através de um interface gráfico;
✓ um sistema de utilitários, dito de baixo nível, porque não são, na generalidade
dos casos, visíveis aos olhos dos utilizadores;
✓ o Kernel, que é o coração do sistema.
A shell é como que uma envolvente do kernel, que permite o diálogo entre o utilizador
e o hardware. Atualmente, podemos dizer que a maioria dos sistemas operativos se
concentra em duas famílias fundamentais: a família Windows e a família Unix. Existem,
apesar disso, nichos de utilização de outros sistemas, uns em queda, outros com uma
atividade significativa que são sistemas como o AS400, 0S/2, VMS, etc. Por agora,
podemos dizer que os sistemas mais conhecidos são: Linux; Mac OS; UNIX; Windows.
Em esquema poderíamos colocar:
Caraterização de um Sistema Operativo
Regressemos à definição de Sistema Operativo, como o conjunto Hardware/Software —
Firmware — que faz funcionar o sistema de informação, ou seja, um (ou vários)
equipamento.
Admitindo que neste momento não vamos abordar a componente física (o
microprocessador e o seu funcionamento) já estudado no 10º ano de escolaridade,
abordemos então o sistema operativo como a componente lógica, o que nos permite
afirmar que o SO é o sistema lógico (software) responsável pelo controlo e gestão do
hardware e das operações básicas do sistema. Suporta uma interface a partir da qual se
podem executar as chamadas aplicações de utilizador.
Recordando o esquema da página 18 podemos designar como sistema operativo o
conjunto das camadas shell e kernel do nosso esquema. Na realidade, não é assim tão
simples, pois já sabe que existe uma outra interface, entre o SO e o equipamento, que
por vezes se considera como fazendo parte do próprio SO e que se chama BIOS, do qual
falamos anteriormente.

Assim sendo, e supondo uma estrutura em camadas, todas as aplicações só podem

funcionar desde que o “coração” do sistema (core) forneça todos os serviços de suporte.
E que serviços são esses? Os mais importantes são:
• Acesso aos suportes de informação (ao disco, p. ex.)
• Gestão de memória
• Organização de tarefas
• Controlo dos fluxos de informação
• Funcionamento do interface

O código que permite executar essas funções recebe a designação de kernel, e encontra-
se rodeado de um conjunto de códigos de suporte — entre eles, as livrarias ou
bibliotecas (libraries) - que servem duas estruturas de funções. São, por um lado, o
suporte para a execução das tarefas fundamentais do SO, “chamadas” sempre que
necessárias, e, por outro, a ligação com o utilizador. Este código de suporte é, para todos
os efeitos, a shell.

Shell (de um sistema operativo)

Designa, de uma maneira geral, o conjunto de programas que servem de interface entre
o core (interior) de um sistema operativo e o utilizador. Podem ser divididos em dois
grandes grupos, os que fornecem um interface de linha de comando (CLI) e os que
oferecem um interface gráfico (GUI). Um dos exemplos mais notáveis de uma shell CLI,
é a do UNIX, ou dos sistemas chamados Unix-like.
Muitas vezes refere-se também como sendo o kernel a componente do core do Sistema
Operativo que se encontra mais próxima do hardware, o que é de facto verdade.
É no kernel do sistema que estão as instruções necessárias à realização das tais tarefas
básicas a que nos reportamos atrás, nomeadamente a gestão dos processos de acesso,
localização e trânsito da informação nos diferentes tipos de memórias, antes e depois
de ser tratada pelo processador.
Do mesmo modo é o kernel que refere as entradas e saídas dessa informação e que a
remete para a interface com um utilizador, como aliás já vimos atrás.
Importa apenas fazer um ligeiro aprofundamento do que são os serviços habituais do
core do sistema.
Hoje em dia, estes serviços estão cada vez mais em expansão. De uma gestão de
memória e de controlos de I/O e interrupções comuns há alguns anos atrás, esperamos
hoje que o sistema operativo seja capaz de tratar informações multimédia, de fazer
conexão com redes (quer locais quer na Net) de garantir a segurança do sistema
protegendo-o de ataques provenientes de ligações ou da introdução de código
“suspeito”, etc. e, como função essencial, gerir a intercomunicabilidade entre
programas através da API.
A designação API (Aplication Programming Interface) atribui-se ao software constituído
por conjuntos de rotinas que, vistas do ponto de vista de um programador, facilitam a
escrita de software que permite um melhor e mais rápido acesso a hardware que seja
concebido com esse propósito. Sob o ponto de vista do sistema, é software que
compatibiliza hardware e outro software funcionando entre o SO (e o equipamento) e
as aplicações, de modo similar à interface do utilizador, que permite ao utilizador
“comunicar” com o sistema.
De um modo simples e direto, podemos dizer então que o Sistema operativo se divide
em três componentes: Shell (GUI ou CLI); utilitários de sistema “low-level” e Kernel:
Há várias maneiras de classificar os sistemas operativos, decorrendo daí várias
designações, mais ou menos padrão, ao sabor da história ou ao sabor do modo como
são estruturados os componentes físicos ou lógicos associados ao SO.
Em muitos sistemas, a shell e o kernel são entidades completamente distintas
permitindo diversos tipos de combinações (como acontece no UNIX); noutros sistemas
essa distinção é meramente conceptual.
Uma das classificações que é habitual fazer-se é:

• Kernel monolítico (Windows — incluindo o NT e Linux, por exemplo)

• Microkernel (Amiga OS e Mac OS X, por exemplo)

• Exokernel (utilizado nos designados Embebed Systems, ou seja, sistemas

incorporados no hardware)

Estrutura dos Sistemas Operativos

Monolítica
Comecemos por analisar a estrutura monolítica que, tal como o seu nome indica,
funciona como se fosse um todo.
Digamos que este modelo estrutural se define pela existência de um interface virtual de
alto nível que age sobre o hardware através de um conjunto de primitivas (System Calls)
que implementam os serviços do Sistema Operativo (gestão de processos, atribuição de
priori- dades e gestão da memória) num ou em diferentes módulos que “correm”
debaixo do controlo de um supervisor. O Supervisor é um programa, ou conjunto de
programas, que controla a articulação dos processos do Sistema Operativo de um
computador, gerindo-os de modo a otimizar os recursos disponíveis. Em suma, trata as
operações de entrada e saída — não as controla, pois isso é da competência do IOCS ou
BIOS — e faz a sua gestão em termos da globalidade dos procedimentos necessários,
trata as interrupções (conceito fundamental no funcionamento de um sistema
operativo) e outras funções de controlo de todos os programas. Eis, num esquema
simples, a estrutura monolítica:
Dentro desta estrutura, podemos ainda considerar três subcategorias: Monolítico
simples; Monolítico modular; Monolítico por camadas (layered)
Vejamos cada uma deles através de um diagrama simples e de uma análise das suas
performances principais.

Monolítico simples
Nesta primeira subcategoria, de que existem inúmeros exemplos sobretudo no final do
século XX, como é o caso do UNIX, do MS-DOS, das versões do Windows até ao NT e das
da Apple até ao MAC OS (v9), podemos considerar que se trata de uma estrutura de SO
que:
• Não oferece portabilidade
• É de difícil manutenção (“pesada” no sentido de trabalhosa e complexa)
• Tem falta de fiabilidade (passível de muitos crashs e de erros não esperados)
• Todas as componentes de serviço estão no kernel
• Pode conseguir uma alta eficácia enquanto sistema (daí a sua durabilidade)

Em esquema:

O sistema de informação está, como já sabemos, estruturado em camadas e o Sistema

Operativo constitui uma única peça (monolítica) que faz a ligação entre o hardware e a
interface com o utilizador (API — Aplication Programming Interface). Compreende-se
que se existir uma falha no sistema, tudo quanto está pendente dele também falha, daí
os crashes de que falámos atrás.

Monolítico modular
Uma primeira solução para tentar resolver alguns destes problemas foi estruturar o
sistema operativo em módulos, com algum grau de autonomia entre eles que permita
resolver, de facto, alguns dos inconvenientes anteriores.

• Os módulos colocam-se na plataforma do sistema operativo de forma

independente uns dos outros
• É mais fácil de fazer a sua manutenção (porque sectorizada e localizada)
• Aumenta a fiabilidade (um erro num módulo não implica o crash de todo o
sistema)
• Todos os serviços se localizam ainda no Kernel e, portanto, com o mesmo
grau de privilégio
• Tem uma eficácia igual ou maior que o anterior
Em esquema:

Repare-se que, em termos globais, parece não diferir muito do anterior, mas os módulos
permitem uma melhor organização e “atribuição de responsabilidades” dentro do
sistema permitindo, a partir daí, ações mais direcionadas e mais precisas, com todas as
vantagens daí decorrentes.
Uma última solução mais aperfeiçoada é:

Monolítico por camadas (layered)

Repare-se que é um modelo estrutural significativamente diferente do anterior embora
tudo ainda esteja no Kernel como é típico de um sistema monolítico. No entanto,
teremos agora diferentes graus de privilégio, em função da camada em que se
encontrem os serviços:

• Aumenta a portabilidade em relação aos anteriores

• Torna-se muito mais simples a manutenção (intervenção ao nível da cada camada)
• Não diminui a fiabilidade (o crash de uma camada não implica necessariamente a paragem
do SO)
• Pode eventualmente diminuir a eficácia, pela existência de diversas interfaces
• Permite uma implementação cuidadosa da solução “stacked virtual machine”, ou seja,
máquina virtual “empilhada”

Naturalmente que este modelo possui, apesar de tudo, alguns inconvenientes difíceis
de ultrapassar pelo facto de o kernel ser o “pai de tudo” no Sistema Operativo.
Na estrutura modular, por exemplo, apesar de cada módulo executar operações
separadamente do conjunto do todo do SO, a integração do código no processo global
é condicionado por não existirem praticamente margens de erro, e serem de difícil
correção, caso aconteçam. Acresce a isto o facto de todos os módulos que concorrem
para um dado problema acabam por funcionar para um mesmo espaço endereçável e
um erro num deles aca- baria por provocar o crash de todo o sistema.
Apesar deste facto, quando a implementação do Sistema Operativo está bem feita e é
fiável a “fina” integração dos componentes permite articular com facilidade o software
designado de baixo nível (Low-Level software — ver imagem de página 27) subjacente à
shell, construindo uma solução altamente eficiente.
Os defensores deste modelo explicam muitas vezes que, se um código é defeituoso, não
pertence em princípio ao kernel e, caso isso aconteça, existem vantagens no modelo
modular para ultrapassar essa situação. De facto, a solução encontra-se no microkernel,
muitas vezes designado como ukernel.

Monolithic kernels vs microkernels

Os sistemas monolíticos são, muitas vezes, preferidos aos kernel por causa do baixo nível
e complexidade no controlo do código no espaço correspondente ao endereça- mento.
De facto, neste modelo as soluções são mais lineares e mais simples — embora
nalgumas situações não tão eficazes — que no kernel. Embora considerados já obsoletos
na década de noventa do século passado, foram como que “recuperados” quando o
LINUX foi implementado num modelo monolítico, ficando célebre a polémica entre
Linus Torvalds e Andrew Tanenbaum sobre as virtualidades e defeitos do sistema.
É natural que sendo os sistemas monolíticos mais simples de desenhar, e sendo também
mais fácil proceder ao seu “crescimento”, tenham as suas preferências entre os
conceptores de SO. O kernel mais bem-sucedido terá sido o Mach, embora sejam
utilizadas soluções deste tipo, por exemplo, na robótica ou em Medicina, com sucesso.

Kernels híbridos (modified microkernels)

Designam-se deste modo soluções kernel que possuem código “não-essencial” no
espaço reservado ao kernel, conseguindo-se com isso que funcione com maior rapidez
do que se estivesse no “espaço” destinado aos utilitários.
É como que uma espécie de solução de compromisso entre uma visão minimalista do
µkernel e as soluções que se foram construindo derivadas duma visão monolítica,
enquanto não se conseguiu provar que o µkernel puro era uma solução eficaz. Muitos
dos sistemas que temos atualmente são deste tipo, uma vez que não se podem
considerar como µkernel puros. São exemplos mais conhecidos o Windows (2000 e XP)
e o Mac OS X.

Executar o utilitário gparted Aspeto geral do utilitário gparted

Gestão de periféricos
Para instalar um novo periférico torna-se, normalmente, necessário instalar um novo
programa para controlar esse dispositivo. O programa que faz o controlo de um
dispositivo de hardware é conhecido por controlador de dispositivo ou simples-; mente
por driver.
Por questões de segurança, quando o kernel do sistema operativo Linux deteta que
existe uma aplicação a tentar aceder diretamente ao hardware, o acesso é-lhe negado.
As vantagens desta política são muitas; tais como: grande segurança, fiabilidade e
estabilidade.
A desvantagem deste processo é que todos os controladores necessários para o
funcionamento do computador têm de estar inseridos no kernel.
Se um controlador de um dispositivo não existir no interior do kernel, teríamos de
instalar um novo kernel com esse controlador e reiniciar o kernel. Para ultrapassar este
problema poderíamos instalar um kernel que inclua todos os controladores existentes;
contudo, atualmente, esta solução não é praticável, dado que todos os controladores
iriam ocupar muito espaço na memória RAM.
Nas primeiras versões do Linux esta questão era mais simples do que atualmente, visto
não existirem periféricos USB, softmodems e, muito menos, placas Wireless. O kernel
oferecia, normalmente, apenas suporte a discos com controladora IDE, placa de vídeo e
drive de disquetes. Com o tempo foi-se adicionando suporte a outros dispositivos, tais
como: placas de rede, placas de som, controladoras SCSI, entre outros. De facto, o kernel
do Linux era constituído por um kernel monolítico.
Se houvesse necessidade de ativar um novo controla-
dor que não estivesse incluído no kernel, tínhamos de
o compilar novamente, incluindo o novo controlador
e reiniciando o kernel.
Durante o desenvolvimento do kernel 2.0, este
problema foi resolvido com a introdução do suporte
em módulos. Os módulos são peças independentes
Esquema de um kernel que podem ser ativadas ou descativadas com o
monolítico sistema operativo em e Es a funcionamento. A partir
do kernel 2.2, quase tudo pode Fi. 4.93 Esquema de
um kernel monolítico ser compilado como módulo, o que tornou as coisas muito mais
práticas, pois passou a ser possível compilar um kernel a abranger quase todos os
controladores, incluindo os controladores não essenciais, que são compilados como
módulos. O kernel em si é pequeno e ocupa pouca memória RAM. Os módulos ficam
guardados numa diretoria do disco rígido e, quando hou- ver necessidade de algum
controlador que não esteja no kernel, o módulo será carregado do disco rígido sem que
haja necessidade de compilar o kernel e de reiniciar o sistema. Quando o controlador
não for essencial, o módulo será libertado da memória RAM e será guardado no disco
rígido.
Para aumentar a segurança no sistema, houve necessidade de se definirem métodos
para restringir a utilização dos controladores, conseguindo-se deste modo controlar o
acesso aos dispositivos. No Unix e no Linux, os controladores são vistos como ficheiros
do sistema e, assim, todos os métodos de permissões existentes para ficheiros e
diretorias são válidos para os controladores. A porta de comunicação série que no MS-
DOS é designada por COM1, é representada, no Unix e Linux, pelo ficheiro virtual
/dev/tty0.
No Unix e Linux, todos os ficheiros virtuais que representam os dispositivos encontram-
se na diretoria /dev.
Na diretoria /proc encontra-se informação sobre os dispositivos e os recursos que
ocupam. Vamos analisar alguns exemplos:
/proc/cpuinfo — contém informação sobre o microprocessador;
/proc/modules — contém informação sobre os módulos instalados.
Se executarmos o programa /sbin/Ismod podemos visualizar os módulos que estão
carregados no kernel; na prática estamos a visualizar a informação que está no ficheiro
/proc/modules.

Lista dos módulos carregados no kernel

Na figura, pode-se observar que o módulo floppy relativo à drive de disquetes não está
a ser usado (está com valor “0”).
Ao executar-se o comando:
modprobe -r floppy
o módulo floppy é descarregado do kernel.

O arranque: LILO/GRUB
Num sistema onde estão instalados vários sistemas operativos temos de ter um gestor
para que o utilizador, no arranque do computador, possa selecionar qual o sistema
operativo que vai arrancar. Existem diversos programas que realizam a tarefa anterior,
dentro dos quais destacamos o LILO e o GRUB.
O GRUB é o gestor de arranque que é instalado, por defeito, durante a fase de instalação
do Fedora e do Red Hat.
Após o arranque do computador e, antes de o sistema operativo ser carregado para a
memória, o GRUB disponibiliza aos utilizadores, durante uns segundos, um menu onde
podemos selecionar o sistema operativo que será carregado pelo computador.

Aspeto do gestor de arranque GRUB

No menu de arranque do GRUB e por intermédio da introdução de uma palavra- -passe,

os utilizadores têm possibilidade de aceder a mais opções, tais como: editar parâmetros
de arranque ou aceder a uma versão simplificada da shell — onde podemos executar
algumas operações como analisar discos rígidos, no caso de existirem sectores
danificados, ou aceder a ficheiros de configuração do sistema.
Se o GRUB não possuir nenhuma palavra-passe, podemos considerar uma falha de
segurança no sistema, dado que qualquer utilizador mais experiente pode aceder ao
sistema e realizar tarefas que podem danificar o normal funcionamento do mesmo.
O ficheiro de configuração do GRUB encontra-se no ficheiro /etc/grub.conf.
Na prática, o ficheiro /etc/grub.conf é um link para o ficheiro /boot/grub/grub.conf,
isto é, se alterarmos ou visualizarmos o ficheiro /etc/grub.conf, estamos a modificar e
a visualizar o que está no ficheiro /boot/grub/grub.conf.
Diretorias associadas ao servidor Apache
• /etc/httpd/conf — nesta diretoria encontram-se os ficheiros de configuração do Apache,
nomeadamente o ficheiro httpd.conf.

• /etc/re.d/init.d — contém a script de arranque do servidor Apache, o httpod. Com o

ficheiro httpd podemos, entre outras operações, arrancar, parar ou reiniciar o serviço;

• /var/www — diretoria que contém várias subdiretorias, das quais destacamos a que aloja
os manuais, as CGI, os defeitos e as páginas HTML do site:

• /var/www/html — diretoria, por defeito, do Apache, onde devemos alojar as pági- nas do
site;

• /var/www/manual/ — diretoria onde se encontram os manuais do Apache em formato

HTML. Após a instalação e arranque do Apache temos acesso a esta documentação
colocando num browser o endereço http://endereço IP/manual ou localmente
http://localhost/manual.

• /usr/share/man — diretoria com manuais do Apache. O acesso a estes manuais pode ser
efetuado usando o comando man httpd;

• /usr/sbin — os programas executáveis encontram-se nesta diretoria, incluindo o

executável do servidor, bem como vários utilitários;

• /usr/bin — alguns dos utilitários do Apache são colocados aqui, por exemplo, o programa
hipasswa, que é usado para gerar ficheiros de autenticação de palavras-passe;

• /var/log/httpd — diretoria onde são armazenados os ficheiros de registo do Apache. Dois

ficheiros importantes que se encontram nesta diretoria são os access loge o error log.

Vamos analisar alguns dos principais módulos disponíveis. Alguns deles podem ser
encontrados na Internet, por exemplo, no endereço http://modules.apache.org.
• mod_cgi — este módulo permite a execução de scripts CGI. Apesar da grande varie-
dade de scripts disponíveis na Internet e da facilidade em criá-las, a utilização de
CGI tem tendência a diminuir, dado que, para além de serem mais lentos, relativa-
mente a scripts escritas noutras linguagens, nomeadamente em Perl ou PHP, elas
podem sempre representar uma ameaça na segurança do servidor, pois estas
scripts são programas executáveis. Por esta razão, muitos administradores hesitam
em ativar este módulo de suporte a CGI;
• mod_perl — o Perl é uma linguagem de programação muito poderosa. A par do
PHP, o Perl é uma das linguagens mais usadas no desenvolvimento de sites
dinâmicos, fóruns e outras aplicações que envolvam processamento de
informação. O endereço do módulo mod_perl é http://perl.apache.org;
• mod_php — o PHP é muito utilizado em manipular base de dados e pode ser
integrado com várias bases de dados, entre elas o MySQL, PostgreSQL e dBase. A
página oficial do PHP é http://www.php.net;
• mod_asp — como o nome sugere, este é um módulo que oferece suporte parcial a
páginas ASP. É uma boa solução para migrar sites que estão escritos em ASP e a
funcionar em IIS para o Apache, sem haver necessidade de se converter tudo para
PHP. O mod_asp trabalha convertendo os comandos ASP para comandos Perl e,
por esta razão, é necessário instalar o mod_perl. O endereço oficial do módulo
mod_asp é: http://www.apache-asp.org;
• mod_gzip – O gzip ou GNU Zip é um formato de compressão desenvolvido pela Free
Software Fundation e é muito utilizado em sistema Linux. O mod_gzip pode ser
usado em conjunto com o Apache para compactar as páginas enviadas aos clientes.
Isto permite diminuir até 80% o tempo de transferência das páginas, melhorando
muito a capacidade do servidor. Atualmente, quase todos os browsers são capazes
de descompactar automaticamente as páginas; assim, não existem grandes
desvantagens em utilizar este módulo, a não ser um pequeno aumento na
utilização do processa- dor. O endereço do módulo mod_gzip é
http://freshmeat.net/projects/mod. gzip;
• mod_speling — este módulo corrige erros nos endereços digitados pelos utilizadores;
mesmo que estes introduzam, num browser, um endereço errado, este módulo pode
corrigir o erro e atingir a página desejada. Outro recurso permitido por este módulo é a
desativação da diferenciação entre letras maiúsculas e minúsculas. O endereço do módulo
mod_speling é http: //httpd.apache.org/docs/mod/mod speling.html;

• mod_bandwidth — permite estabelecer limites no uso da largura de banda para o servi

dor, para um determinado diretório, ou, ainda, para um determinado cliente. O endereço
do módulo mod_bandwindth é http://www.cohprog.com/mod. bandwidth.html;

• mod_frontpage — este módulo é um complementando ao módulo mod_asp. Oferece

suporte às Server Extensions do FrontPage. Podemos obter informação deste módulo no
endereço http://www.cohprog.com/mod bandwidth.html;

• mod_ssl — este módulo permite ligações seguras, com encriptação forte. Este módulo
deve ser utilizado em sites de bancos e em outras páginas que trabalhem com números de
cartão de crédito e com outros dados confidenciais. O endereço do módulo mod_ssl é
http://www.modssl.org;

• jakarta — este é o projeto que oferece uma implementação do Java para o servidor
Apache. Os pacotes podem ser descarregados a partir do endereço http: //jakarta.apa-
che.org.

Atualização do kernel e outras aplicações

Quando recompilar um kernel
O kernel é o coração do sistema operativo. Todos os programas rodam sobre o kernel e
este cria uma ponte entre os programas, os utilizadores e o hardware.
Para se manter a compatibilidade com o maior número possível de dispositivos, as
distribuições devem incluir todos ou quase todos os drivers de dispositivos disponíveis
para o Linux, mas para evitar que isto torne o kernel muito grande, deve-se criar um
kernel base que inclua os controladores dos dispositivos mais importantes, enquanto
que aqueles dispositivos que não são utilizados com frequência devem ser
implementados como módulos.
Uma das vantagens dos módulos é a possibilidade de serem carregados somente
quando são necessários. Quando os dispositivos não são utilizados, os módulos são
descarregados libertando espaço na memória RAM e recursos do sistema.
Ao recompilarmos o kernel no Linux, temos a possibilidade de criar um kernel adaptado
às nossas necessidades. Se quisermos adicionar suporte a um dispositivo, cujo
controlador de dispositivo esteja somente disponível numa versão mais recente,
devemos recompilar o kernel.
Nas primeiras versões do Linux, o método utilizado para adicionar ou remover um
controlador de um dispositivo ao kernel baseava-se em reconstruir um novo kernel.
Atualmente, o processo de recompilar o kernel para obtermos um novo kernel, com
novos controladores de dispositivos, não é muito utilizado, uma vez que os módulos
disponibilizam maior flexibilidade.
O kernel fornecido no Fedora Core está compilado com o máximo de módulos possíveis
para fornecer a maior flexibilidade possível. Um kernel que esteja a correr pode ainda
ser ajustado com o programa syscti, que permite um acesso direto ao kernel que está a
correr e possibilita que sejam alterados alguns parâmetros do mesmo.

Versões do kernel
O kernel do Linux encontra-se num constante estado de desenvolvimento. Quando se
adicionam novas características, ou se resolvem defeitos ou, ainda, se uma nova
tecnologia é incorporada no código-base, torna-se necessário fornecer lançamentos
estáveis do kernel para serem usados. É importante ter lançamentos separados que
contenham o código mais recente para que os colaboradores, que desenvolvem o
kernel, o possam testar.
Para nos mantermos a par das várias versões do kernel, são-lhes atribuídos números das
versões.
Os programadores usam números de versões sequenciais que tenham um significado
abstrato. Por exemplo, será que a versão 6 é duas vezes mais avançada que a versão 3
da mesma aplicação? Será que a versão 2 de uma aplicação é menos desenvolvida que
a versão 5 de uma outra aplicação? Os números das versões não podem ser usa- dos
para este tipo de comparação quantitativa e qualitativa. É perfeitamente possível que
números mais elevados possam ter menos características e mais defeitos que versões
mais antigas. Os números apenas existem para diferenciar e organizar as versões
sequenciais da revisão do software.
Imaginemos a versão mais recentemente desenvolvida do kernel, que, no momento em
que este texto é escrito, é, a versão número 2.6.16-11.
A versão do kernel pode ser dividida em quatro secções:
• versão principal — este é o número da versão principal, que agora está em 2;

• versão menor — este é o número da versão menor, que agora está em 6;

• número de subnível — este número indica a iteração atual do kernel; aqui é o número 16;

• nível extraversão — este é o número que representa uma coleção de pacotes e adições
feitas ao kernel. Neste exemplo é 11.

A visualização da versão atual do kernel, isto é, saber qual a versão do kernel que o
sistema carregou durante o arranque do sistema, pode ser realizada executando, numa
linha de comandos de uma shell, o comando:
uname -r
Neste exemplo o resultado seria:
2.6.16-11
As versões menores numeradas com números pares são kerneis estáveis, enquanto que
versões menores, numeradas com números ímpares, são lançamentos de
desenvolvimento. A versão 2.6.x é o kernel de produção estável, enquanto que a versão
2.5.x é o kernel de desenvolvimento do Linux. Quando se iniciar uma nova versão de
desenvolvi- mento do kernel, será numerada com 2.7.x.
Para computadores de produção, devem-se sempre usar kernels com números pares
menores. Os números ímpares menores introduzem novas características, por isso,
podemos usar um kernel com números ímpares menores numa máquina de testes se
necessitarmos de usufruir das novas características disponibilizadas pela versão de
desenvolvimento.

Como obter um kernel atualizado

No Linux existem diversos processos para atualizar o kernel. O método tradicional para
atualizar o kernel consiste em descarregar o seu código-fonte e configurar as opções
desejadas, compilando e instalando.
No Fedora, existem procedimentos mais simples para atualizar um kernel, tais como
utilizar pacotes pré-compilados do kernel ou usando o programa yum.

Instalar novo kernel usando o programa yum

O método mais simples para atualizar o kernel, no Fedora, é usar o programa yum. Para
executarmos este programa, ligamos o computador à Internet e, como root, execu-
tamos o comando:
yum update kernel
O instalador yum vai analisar a versão mais recente do kernel e, se pretendermos
prosseguir com a instalação, selecionamos Y e pressionamos Enter.
Após a instalação, podemos verificar que foram adicionados os ficheiros:
/boot/config-2.6.16-1.2096_FC4
e
/boot/vmlinuz-2.6.16-1.2096_FC4
Processo de atualização do Kernel

Instalação completa do novo kernel

Os ficheiros com o kernel inicial não foram eliminados e ainda se encontram na direc-
toria /boot.
/boot/config-2.6.11-1.1369_FC4
e
/boot/vmlinuz-2.6.11-1.1369_FC4
O ficheiro de configuração do arranque /etc/grub.conf foi alterado de modo a manter a
versão anterior do kernel e criou-se uma nova opção com a nova versão do kernel. A
nova versão do kernel está selecionada para arrancar por defeito. Caso seja o LILO o
gestor de arranque instalado, o ficheiro alterado é o /etc/lilo.conf.
Aspeto do ficheiro /etc/grub.conf após atualização do kernel

Instalar novo kernel usando ficheiros pré-compilados

O Fedora Core fornece diversas versões pré-compiladas do kernel, por exemplo, para
processadores Athlon e Pentium ou para motherboards com um ou múltiplos processa-
dores. Estas versões do kernel são fornecidas em formato RPM. Para as instalar, temos,
inicialmente, de obter o ficheiro com o kernel pré-compilado no formato RPM e, como
root, executar o comando:
rpm -Uvh novo kernel.rpm
Os ficheiros RPM com o kernel não incluem os ficheiros com o código-fonte, mas
incorporam scripts de instalação que vão automaticamente alterar a configuração do
gestor de arranque, tornando o novo kernel aquele que vai arrancar por defeito. Se não
quisermos que isto aconteça, teremos de, manualmente, editar os ficheiros
/etc/lilo.conf ou o /etc/grub.conf e alterá-los para como estavam inicialmente.
Nota: É aconselhável executar o comando rpm -U (atualização) em vez do rpm -i
(instalação) num novo. kernel RPM, para evitar que o novo kernel seja escrito por cima
do velho kernel. Isto é feito como uma medida da segurança; assim, se o novo kernel
não funcionar, podemos arrancar o sistema, normalmente, com o velho Kernel.

Instalar novo kernel a partir do código-fonte

O método tradicional para atualizar o kernel consiste em descarregar o seu código-fonte
a partir do site oficial http://www.kernel.org e configurar as opções desejadas,
compilando e instalando. Este método permite maior controlo sobre as características
desejadas, mas torna-se um procedimento um pouco mais complexo.
Obter código-fonte do kernel
O kernel do Linux sempre esteve livremente disponível. Para obtermos a última versão
do código-fonte do kernel, com ajuda de um browser, vamos ao site
http://www.kernel.org e
descarregamos o ficheiro
compactado com o código-
fonte da versão que
pretendemos instalar. Outro
processo para obter o código-
fonte do kernel é utilizarmos
um cliente de FTP para
acedermos ao servidor FTP
oficial do kernel, o
ftp.kernel.org, e fazer o
arranque como utilizador
anonymous.
Como estamos interessados
no kernel 2.6, devemos ir a
/pub/linux/kernel/v2.6 e
selecionar o ficheiro com a
versão que pretendemos, por Cliente FTP FileZilla com acesso ao servidor ftp.kernel.org
exemplo, o 2.6.16.

No servidor FTP encontramos um número de diferentes entradas para cada versão do

kernel. Como estamos interessados no kernel completo, temos de obter o pacote
completo com o código-fonte. Consoante o programa de compactação utilizado, o
ficheiro com o código-fonte pode ser obtido nos seguintes formatos:
linux-2.6.xx.xx.tar.gz
ou
linux-2.6.xx.xx.bz2
O ficheiro compactado com o código-fonte do kernel deve ser descarregado para a
diretoria /usr/src.
Depois de descarregar o ficheiro com o código-fonte na diretoria /usr/src, temos de
descompactá-lo, e, para isso, dentro da diretoria /usr/src, executamos o comando:
tar -xzvf linux-2.6.xx.xx.tar.gz
Se o ficheiro descarregado tiver extensão tar.bz2, dentro da diretoria /usr/src,
executamos o comando:
tar -xjvf linux-2.6.xx.xx.tar.bz2
Nota: Ao descompactar o ficheiro é criada uma subdiretoria com o nome do ficheiro,
por exemplo, /usr/src/Linux-2.6.xx.xx.
Nesta fase, devemos criar um link simbólico do Linux-2.6 para Linux 2.6.xx.xx (de outro
modo alguns scripts não irão funcionar). Eis como criar um link simbólico:
Se existir o link já criado, devemos removê-lo, usando o comando:
rm /usr/src/linux-2.6
A criação do link pode ser realizada executando o comando:
ln -s /usr/src/linux-2.6.xx.xx /usr/src/linux-2.6
Ao criar um link simbólico para /usr/src/linux-2.6, é possível permitir que múltiplas
versões do kernel sejam compiladas e decompostas para funções diferentes: deve-se
apenas alterar o link simbólico para a diretoria do kernel na qual se quer trabalhar.
Nota: O uso correto do link simbólico é crucial para a compilação do Kernel. Devemos
ter sempre o link simbólico do Kernel apontado para a versão das fontes do Kernel com
as quais estamos a trabalhar.

Compilar o kernel
Antes de iniciar o processo de compilação é necessário instalar o compilador de gcc.
Para isso, no ambiente de trabalho, vamos a Área de Trabalho e, em Configuração do
Sistema, selecionamos Adicionar/Remover Aplicações, ou podemos, simplesmente,
numa shell, executar system-config-packages.
Na janela Gestão de Pacotes selecionamos as Ferramentas de Desenvolvimento e
clicamos em Atualizar para prosseguir com a instalação do compilador.
Se quisermos fazer uma atualização — update — do kernel, a partir do novo código-
fonte que descarregamos, ou se pretendermos aplicar um acrescento para adicionar
novas funcionalidades ou apoio
de hardware, necessitamos de
compilar e instalar um novo
kernel para que o sistema,
realmente, possa usar essa nova
funcionalidade. Compilar o
kernel envolve traduzir os
conteúdos do kernel do código-
fonte para a forma binária.
Instalar o kernel compreende
colocar todos os ficheiros
compilados onde pertencem em
/boot e /lib e fazer alterações ao
gestor de arranque (bootloader).
O processo de compilação do
kernel é quase completamente
automatizado pelo utilitário Adicionar compilador gcc.
make, como o é o processo de
instalação.
Eis uma lista de verificação dos passos para compilar e configurar o kernel:
1. Encontrar o disco de arranque que funcione com o kernel antigo, para ser capaz
de reiniciar o sistema, no caso de algo correr mal com o novo kernel.

Nota: Antes de efetuarmos qualquer alteração ao kernel atual, devemos ter a certeza
de termos feito uma cópia de segurança numa disquete ou pen. Isto irá permitir fazer o
arranque ao nosso sistema com um Kernel que sabemos que funciona, no caso de algo
correr mal durante a configuração. O comando para tal é o seguinte:
mkpootdisk --device /dev/fd0 uname -r
2. Aplicar todos os aumentos ao kernel, se existirem, para que tenhamos as
características que desejamos. Se estamos a instalar um novo kernel a partir do
código-fonte completo, esta tarefa não se efetua.
3. Fazer cópia de segurança ao .config, se existir, para que se possa recuperar, caso
haja algum erro. Se estamos a instalar um novo kernel a partir do código-fonte
completo, não é necessário efetuar esta tarefa.

A cópia de segurança do ficheiro .config pode ser realizada através do comando:

cp .config .config.original
4. Correr a diretiva make mrproper para preparar a árvore-fonte do kernel,
limpando quaisquer ficheiros antigos ou binários. Se estamos a instalar um novo
kernel a partir do código-fonte completo, não é necessário efetuar esta tarefa.
5. Dentro da diretoria /usr/src/linux-2.6, onde se encontra o código-fonte do
kernel, temos de definir os componentes que serão incluídos no novo kernel,
usando uma das ferramentas de configuração:
make xconfig
ou
make menuconfig
ou
make config

Módulos
Como já foi visto, os módulos são pacotes de software que podem ser adicionados e
removidos do kernel durante o funcionamento do sistema operativo, sem que este
tenha de parar, nem mesmo por um instante.
Pelo facto de funcionarem dentro do kernel, esses pacotes de software têm acesso
directo ao hardware e às estruturas de dados internas do próprio kernel.
Os módulos são a plataforma ideal para implementar os controladores de dispositivos
(drivers), que necessitam de aceder directamente ao hardware.
Contudo, a utilidade dos módulos é muito mais vasta do que esta, pois também são
usados para implementar muitos subsistemas e pacotes opcionais do próprio kernel. Por
exemplo, existem módulos que implementam protocolos de comunicação, suporte para
novos sistemas de ficheiros, extensões para criar compatibilidade com outros sistemas
operativos, novos algoritmos de cifragem de dados, etc.
As duas grandes vantagens dos módulos são a optimização da quantidade de memória
ocupada pelo próprio kernel e o uptime. Ao contrário do que acontece com outros
sistemas operativos, não temos de mandar o sistema abaixo apenas para instalar um
novo driver ou alterar um protocolo de comunicação.
O kernel inicial com que o sistema arranca possui apenas um conjunto de
funcionalidades mínimo, necessário para fazer o sistema arrancar, assim como todos os
serviços genéricos que são usados em todas as situações. Desta forma, a quantidade de
memória ocupada pelo kernel é mínima.
Os componentes opcionais, que variam de sistema para sistema e que não são essenciais
para o seu funcionamento, são carregados sob a forma de módulos, durante a fase final
do arranque do sistema.
Por exemplo, os controladores das placas de som, das placas de rede, das placas RDIS,
alguns protocolos de rede e o software de suporte a alguns sistemas de ficheiros, estão
dentro de módulos opcionais.
Para conhecer os módulos que estão instalados no kernel, vamos novamente utilizar o
file-system proc (ou executar o comando «/sbin/lsmod»):
# cat /proc/modules
Ao executar este comando, vamos obter uma listagem de todos os módulos instalados,
em conjunto com as suas interdependências. As interdependências devem-se ao facto
de existirem módulos que utilizam o software implementado noutros módulos.
Exemplo:

Neste exemplo, estão instalados 12 módulos no kernel, que dizem respeito a uma placa
de rede RTL8139, ao sistema de ficheiros FAT/VFAT do DOS, uma placa de som AWE32
e um controlador SCSI NCR/Symbios 53c875.
Os módulos «rtl8139too» e «ncr53c8xx» são os controladores da placa de rede e do
adaptador SCSI. Estes dois módulos funcionam isoladamente e não possuem
dependências com nenhuns outros.
Os módulos «soundcore», «soundlow», «sound», «uart401», «awe wave» e «sb» fazem
parte do subsistema de áudio. Por esse motivo, estão interligados e dependem uns dos
outros.
Os primeiros três módulos são genéricos para todas as placas de áudio, enquanto os
últimos três são os controladores da porta MIDI externa da placa, do sintetizador MIDI
interno e do módulo PCM da Sound Blaster AWE 32.
Os módulos «fat», «vfat», «nls iso8859-1» e «nsl cp437» também dependem uns dos
outros, pois são necessários para dar suporte ao filesystem FAT, incluindo as extensões
do Windows para nomes compridos, VFAT e FAT32. Neste file-system, são suportados
os códigos de página 427 e is0o8859-1.
A indicação autoclean que aparece em alguns destes módulos indica que estes foram
carregados de forma automática. Por esse motivo, assim que deixarem de ser utilizados,
são automaticamente descarregados.
O programa «kmod» («kerneld» nas versões antigas) verifica periodicamente quais são
os módulos que deixaram de ser necessários, descarregando-os de imediato. Como
consequência, a memória que estes estavam a ocupar fica livre para outras aplicações.
Os comandos usados para carregar e descarregar módulos manualmente são o
«insmod» e «rmmod». Em ambos os casos, temos de indicar o nome do módulo que
desejamos carregar ou descarregar ou, então, o nome do respectivo ficheiro.
A directoria «/lib/modules» é o local onde estão localizados os módulos que foram
fornecidos com o kemel. Ao inspeccionar esta directoria, vamos encontrar várias
subdirectorias contendo módulos, ordenados de acordo com a sua utilidade e com a
versão do kernel para que foram criados.
O nome de alguns destes módulos pode não ser auto-explicativo, pelo que é
recomendável uma consulta à documentação do próprio kernel, que se encontra na
directoria «/usr/src/linux*/Documentation».
Para além dos módulos que são fornecidos com o kernel, também é possível instalar
novos módulos fornecidos por terceiras pessoas ou desenvolvidos pelo próprio
utilizador.
Uma das situações mais frequentes em que isto costuma acontecer é quando instalamos
drivers para hardware novo, pois já existem alguns fabricantes de hardware que
começaram a fornecer módulos com drivers para os periféricos que fabricam.
Por exemplo, se desejássemos instalar suporte no kernel para o protocolo de rede IPX
(conectividade com redes Novell), seria necessário inserir o seguinte módulo no kernel:
# /sbin/insmod ipx
Para voltar a remover este módulo, bastaria usar:
# /sbin/rmmod ipx
Durante a inserção e a remoção de módulos, é normal que o kernel escreva algumas
mensagens para os logs que registam os acontecimentos do sistema. Para consultar
estes logs, podemos utilizar o comando «dmesg» ou então ler o texto que está no fim
do ficheiro «/var/log/messages».
Existe um comando muito útil, chamado «modprobe», que serve para manipular
módulos e pode ser utilizado de várias formas. Pode servir para detectar o hardware
presente no sistema, listar os módulos disponíveis no sistema e até para instalar grupos
de módulos interdependentes, de uma única vez.
Por exemplo, o comando:
# /sbin/modprobe ppp
Serve para activar o suporte para PPP (protocolo IP sobre linhas série e modems) no
kernel. Contudo, se verificarmos o conteúdo do ficheiro «/proc/modules», vamos
descobrir que para além do módulo ppp, foi também carregado o módulo slhc, pois o
ppp depende deste último para funcionar.
Da mesma forma, podemos remover os dois módulos anteriores de uma só vez, usando
o comando:
# /sbin/modprobe -r ppp
O funcionamento do «modprobe» pode ser configurado através do ficheiro
«/etc/modules.conf» (nas distribuições antigas chama-se «/etc/conf.modules»).
No sistema do exemplo anterior, o ficheiro «modules.conf» tem a seguinte
configuração:

As linhas que começam pela palavra alias identificam o módulo que deve ser utilizado
em cada classe de dispositivos. Por exemplo, na classe dos controladores SCSI é usado o
módulo «ncr53c8xx», na classe das placas de rede (1º placa) é usado o módulo «rtl8139»
e, na classe das placas de som, o módulo «sb».
As linhas que começam pelas palavras pre-install e post-install definem as dependências
que existem entre módulos, pois permitem especificar comandos que são executados
sempre que um módulo é carregado.
As linhas que começam pela palavra options definem diversos parâmetros de
funcionamento de cada módulo. Por exemplo, no caso dos controladores de
dispositivos, definem os recursos de hardware utilizados (IRQ, DMA, IOPorts).
Os parâmetros de configuração de módulos podem parecer algo complexos à primeira
vista. Contudo, não existe qualquer razão para preocupações, uma vez que existem
vários utilitários que fazem a gestão de módulos de forma automática.
Em primeiro lugar, quando o sistema operativo é instalado, a maioria do hardware é
detectado de forma automática e o software de instalação encarrega-se de criar uma
versão inicial do ficheiro «/etc/modules.conf» perfeitamente funcional.
No caso das placas de som, existem os programas «/usr/sbin/sndconfig» e «redhat-
config-soundcard» do painel de controlo, que se encarregam de detectar
automaticamente o tipo de placa de som presente no sistema e actualizam o ficheiro
«/etc/modules.conf».
Quando desejamos instalar novo hardware, após o computador ter sido instalado,
também existe software que nos pode auxiliar. No caso dos modems, controladores SCSI
e placas de rede, existem vários utilitários gráficos, como o próprio painel de controlo
do Linux Red Hat, que simplificam esta tarefa.

Recompilação do kernel
Nos primeiros tempos, a única forma de adicionar ou remover controladores de
dispositivos ao kernel de Linux consistia em reconstruir um novo kernel e seleccionar
apenas os componentes desejados.
Actualmente, esta tarefa já raramente é utilizada, pois os módulos oferecem muito mais
flexibilidade. Contudo, existem casos em que ainda temos de modificar o kernel. Por
exemplo, isso é o que acontece quando desejamos instalar uma nova versão.
Desde os primeiros tempos que o kernel de Linux tem sido distribuído aos utilizadores
sob a forma de código-fonte. O código-fonte está maioritariamente escrito em
linguagem C, existindo apenas algumas pequenas partes em linguagem Assembly,
porque dependem do hardware.
A maioria das distribuições de Linux costuma incluir um conjunto de utilitários, que
servem para instalar e desenvolver novas aplicações. Esse utilitários incluem os
compiladores e os assembladores, que traduzem programas em linguagens C e
Assembly para o formato binário dos microprocessadores (linguagem máquina).
Utilizando esses utilitários, é possível reconstruir um kernel novo a partir do seu código-
fonte. Como esta tarefa é relativamente complicada, existe outro utilitário chamando
«make», que faz tudo de forma automática. O «make» vai ler um ficheiro, chamado
Makefile, que contém a lista das tarefas a realizar e executa-as sequencialmente.
O «make» permite aos utilizadores compilar kernels novos, mesmo sem possuir
quaisquer conhecimentos sobre programação em linguagem C, nem sobre as restantes
ferramentas de desenvolvimento do Linux.
Para reconstruir o kernel, apenas temos de executar a seguinte sequência de operações:
# cd /usr/src/linux-2.4
# make menuconfig
# make dep
# make
# make modules
# make install
# make modules install
O comando «cd» serve apenas para mudar a directoria actual, para o local onde o
código-fonte do kernel de Linux se encontra. Caso tenha sido feito download para outro
local ou esteja a ser usada uma versão diferente da 2.4, deverá ser escolhida a directoria
correcta.
A linha «make menuconfig» serve para aceder a um sistema de menus, que nos permite
escolher todos os serviços e controladores que desejamos instalar.
Caso estejamos a usar o sistema de janelas X, podemos usar «make xconfig» em vez do
«make menuconfig». O «xconfig» funciona em modo gráfico, pelo que ainda é mais fácil
de usar.

Para cada componente do kernel, podemos escolher as opções «y», «n», ou «m».
Quando escolhemos «y», esse componente é automaticamente instalado na versão
base do kernel. Quando escolhemos «m», é criado um módulo que pode ser carregado
dinamicamente durante o funcionamento do sistema. Quanto escolhemos «n», estamos
simplesmente a desactivar esse componente.
A linha seguinte, «make dep», vai analisar as dependências entre cada um dos pacotes
de software que fazem parte de kernel. Pode acontecer que a configuração escolhida
no passo anterior esteja inconsistente. Isso acontece quando activamos um
componente que necessita de outro, mas este outro foi desactivado.
A linha «make» é que vai realmente reconstruir o novo kernel. Quando este comando é
executado, o utilitário «make» vai mandar traduzir algumas centenas de ficheiros em
linguagem C para código-binário. Por esse motivo, o compilador de C «gec» vai ser
chamado centenas de vezes, até todos os ficheiros terem sido convertidos. Esta
operação pode demorar entre 10 minutos a mais de meia hora, dependendo da
velocidade do computador.
Após todos os ficheiros terem sido compilados, o seu resultado é agrupado num único
ficheiro (linking), que é depois comprimido utilizando o programa «gzip». Quando o
Linux está a ser usado num PC, o ficheiro final fica guardado na directoria
«./arch/i386/boot». É exactamente este ficheiro que contém o novo kernel,
devidamente comprimido.
A linha «make modules» gera todos os módulos que serão utilizados em conjunto com
o novo kernel.
As linhas «make install» e «make modules install» copiam o kernel propriamente dito,
juntamente com os ficheiros auxiliares e os módulos que acabaram de ser compilados
para as directorias definitivas do sistema: «/boot» e «/lib/modules».
Por fim, falta apenas configurar o sistema para passar a arrancar a partir do novo kernel:
este é o tema que vai ser tratado em seguida...

O arranque do sistema
O conhecimento da sequência de passos que um sistema Linux executa durante o
arranque é essencial para qualquer administrador.
Entre muitas outras coisas, é durante o arranque que são lançados os vários serviços do
sistema, as interfaces de rede são configuradas e os periféricos são activados.

GRUB/LILO ou «loadlin»
A primeira fase do arranque de um sistema Linux consiste no carregamento do kernel
do sistema operativo para a memória. Nos PC, os programas utilizados para carregar o
kernel são o GRUB (Grand Unified Boot Loader) ou alternativamente o LILO (Linux
Loader).
Tanto o GRUB como o LILO podem ser instalados no início do disco rígido (MBR - master
boot record) ou no início da partição principal de Linux (ou seja, a que possui a directoria
raiz e a «/boot»).
Quando um PC arranca, a BIOS do sistema executa o boot-loader que estiver instalado,
GRUB ou LILO, que em seguida lê o kernel de Linux do disco, descomprime-o e carrega-
o em memória. Depois de carregado, o kernel começa a ser executado e só então é que
podemos dizer que o computador está efectivamente a correr Linux.
Outro programa que também pode ser utilizado para correr Linux é o «loadlin». O
«loadlin» é um programa que corre a partir do DOS e faz a mesma coisa que o LILO.

Utilizando o «loadlin»
O «loadlin» é uma ferramenta muito útil para as pessoas que utilizam o Linux, mas por
uma razão ou por outra ainda têm de continuar a usar outros sistemas operativos no
mesmo computador.
A grande vantagem do «loadlin» é que pode ser executado manualmente, permitindo
entrar em Linux a partir da linha de comandos do DOS, sem necessidade de reiniciar o
sistema.
Para arrancar o Linux a partir do DOS, podemos usar o «loadlin» de acordo com os
seguintes exemplos:
C:> loadlin vmlinuz.bin root=/dev/hda5
C:> loadlin vmlinuz.bin initrd=image. img
No primeiro exemplo, estamos a carregar um kernel a partir do ficheiro «vmlinuz.bin>.
À partição principal por onde o Linux deve arrancar é a «/dev/hda5».
No segundo exemplo, estamos a carregar novamente o kernel do ficheiro «vmlinuz.bin»,
mas também estamos a carregar um ramdisk inicial contendo um file-system de
arranque, que está no ficheiro «image.img».
Em qualquer dos dois casos, o ficheiro «vmlinuz.bin» tem de estar acessível a partir do
DOS, pois é ele que contém o kernel que vamos carregar em memória.
Num sistema com várias partições e mais do que um sistema operativo, temos um
problema adicional: é normal ter de reinstalar os outros sistemas operativos de tempos
em tempos, quer seja para fazer actualizações, quer seja para recuperar de situações de
instabilidade e crashes.
Acontece que os outros sistemas operativos têm o mau hábito de apagar o sector de
arranque, que é substituído pelo seu próprio. Nessas situações, o GRUB/LILO deixam de
ser executados e o Linux deixa de arrancar.
Esse problema pode ser facilmente resolvido, utilizando o primeiro dos dois exemplos
anteriores: usamos o «loadlin» para arrancar o Linux a partir do DOS e usamos o
parâmetro root para indicar o nome da partição por onde o Linux costumava arrancar.
Após o Linux arrancar, podemos voltar a configurar o GRUB/LILO, para repor o sector de
arranque do Linux.

Configurando o GRUB
O GRUB é um programa muito versátil, que permite ao utilizador escolher diversos
sistemas operativos por onde fazer o arranque.
Antes de carregar qualquer sistema operativo em memória, o GRUB apresenta um menu
ao utilizador e faz uma pausa de vários segundos. Nessa altura, os utilizadores podem
seleccionar o sistema operativo que desejam usar.
Para além disso, os utilizadores podem inserir uma password e aceder a um conjunto de
opções extra, que permitem editar os parâmetros de arranque do kernel e aceder a uma
shell simplificada que permite realizar algumas operações para tentar recuperar
sistemas danificados, seleccionar kernels contidos em ficheiros diferentes, etc.
A configuração do GRUB é feita no ficheiro «/etc/grub.conf», que contém a lista com
todos os sistemas operativos instalados:

Observando o exemplo, é fácil constatar que o ficheiro «grub.conf» está dividido em

quatro secções diferentes. A primeira secção descreve algumas opções do próprio
GRUB, enquanto as restantes secções definem os sistemas operativos alternativos que
o utilizador pode escolher durante o arranque.
No exemplo, os dois primeiros sistemas são duas versões diferentes de Linux e o terceiro
corresponde ao DOS ou Windows. A cada sistema foi associado um título, composto por
uma pequena descrição do sistema operativo usado.
Nas secções que descrevem o arranque dos vários sistemas, foi necessário definir um
conjunto de dados que servem para ajudar o sistema a arrancar. Esses dados são o título
dado a cada sistema, o nome do disco e partição que contêm o file-system de arranque,
o nome do ficheiro que contém o kernel e opcionalmente um RAMDISK inicial.
A partição inicial de arranque é definida pela palavra-chave root, seguida do nome do
dispositivo correspondente ao disco rígido e o número lógico da partição. Esta partição
deve ser montada inicialmente em modo read-only, para evitar a possibilidade de erros
durante o arranque.
Finalmente, pode haver a necessidade de definir um RAMDISK inicial: initrd. O initrd é
um pequeno file-system que é carregado em memória antes de o kernel ser executado.
Geralmente, contém todos os módulos de software necessários para o kernel completar
a fase inicial do arranque, como por exemplo os drivers do controlador de disco rígido.
A última secção não diz respeito a Linux, mas sim a uma partição que tem DOS ou
Windows instalado. Por essa razão, tem um conjunto de opções diferentes das
anteriores.
Em vez de referenciar uma imagem de um kernel, tem apenas uma descrição da partição
onde o outro sistema está instalado. Neste exemplo, o DOS estava instalado na primeira
partição do primeiro disco IDE, pelo que a linha root vai ter os parâmetros hdo0 e 0.
A linha seguinte contém o comando «chainloader +1» que indica ao GRUB que deve
tentar executar outro boot-loader, que por sua vez se encarregará de arrancar o outro
sistema operativo. Nessa altura, será executado o boot-loader habitual desse sistema.
Finalmente, este sistema operativo está protegido com uma senha cifrada, para que não
seja possível seleccionar este sistema sem conhecer a dita password.
Quanto à secção inicial do «grub.conf», as primeiras linhas começam por definir alguns
parâmetros acerca do próprio GRUB.
A primeira linha, «boot=/dev/hda», define o local onde o sector de arranque do LILO
deve ser guardado no disco. O dispositivo Ada corresponde ao primeiro disco IDE inteiro,
o que significa que vai ser usado o master boot record desse disco.
Em alternativa, poderíamos ter escolhido a partição de arranque hda5. Contudo, nesse
caso teríamos de nos certificar que essa partição estava activa, usando o programa
«fdisk», porque a BIOS só arranca a partir da partição que está activa.
&s linhas timeout e default indicam qual dos sistemas é carregado por omissão. O GRUB
espera 10) segundos e depois, se o utilizador não tiver escolhido nenhum sistema,
carrega o sistema que aparece na posição 0, ou seja, o primeiro sistema da lista.
O GRUB tem muito mais opções de configuração, que podem ser consultadas no manual
do sistema ou usando o comando help dentro da shell do próprio «grub». Existe uma
página de manual sobre o «grub», mas a maior parte da informação está nas páginas de
informação «info grub».
Por fim, sempre que outro sistema operativo apaga o sector de arranque criado pelo
GRUB, este sector tem de voltar a ser instalado no disco rígido. Para reinstalar o GRUB
no sector de arranque do disco rígido, é necessário executar o comando «/sbin/grub-
install», indicando o nome do dispositivo de arranque:
# /sbin/grub-install /dev/hda
Instalar um novo kernel
Quando somos forçados a recompilar o kernel do sistema ou quando pretendemos fazer
uma actualização para uma nova versão, temos de configurar o GRUB para começar a
arrancar pelo kernel novo.
Como já havíamos visto, os kernels acabados de recompilar costumam ficar guardados
dentro do ficheiro comprimido «zImage» ou «vmlinuz», localizado na directoria
«/usr/src/linux/arch/1386/boot>.
Para começar a usar o novo kernel, devemos copiar a sua imagem para a directoria
«/boot»:
# cd /usr/src/linux/arch/i386/boot
# cp vmlinux /boot /new-vmlinux
Geralmente um kernel personalizado nunca necessita de carregar módulos durante a
fase inicial de boot. Como conhecemos bem o nosso próprio sistema, podemos incluir
no interior do kernel todos os controladores para os dispositivos que vão ser usados
durante o arranque.
Por exemplo, quando usamos um disco rígido SCSI, é natural que o driver da placa SCSI
seja incluído na versão base do kernel. Por esse motivo, quando usamos kernels
personalizados, não costuma ser necessário usar ramdisks com imagens de arranque.
Em consequência, apenas temos de acrescentar as seguintes linhas ao fim do ficheiro
«/etc/grub.conf»:

A nova seção que acrescentámos define um sistema que será conhecido por new-linux
e usa a partição «/dev/hda2» como directoria raiz, pois esta é a partição onde está
instalado o início da árvore de directorias do Linux.
Se desejamos que o novo kernel passe a ser o sistema preferido, que arranca por
omissão, basta alterar a linha «default=», que aparece na primeira secção do
«grub.conf» e escolher a posição em que aparece o novo kernel.
Finalmente, resta lembrar que quando o novo kernel é instalado a partir de um pacote
RPM, não é habitual ser necessário fazer absolutamente nada, dado que os RPM
costumam acrescentar automaticamente uma secção ao «grub.conf».

A sequência de arranque do sistema

Assim que o GRUB (ou o «loadlin») descomprime o kernel de Linux e o carrega em
memória, este começa imediatamente a funcionar.
Um dos primeiros passos que o kernel de Linux executa é a detecção de todo o hardware
presente no sistema, passando pela memória, processadores presentes, portas série,
placas gráficas, discos rígidos, etc.
“Após ter detectado os periféricos mais importantes, cujos controladores foram
incluídos na versão base do kernel, é montada a partição principal, onde está a directoria
raiz, ou seja, o root file-system.
Para evitar que o conteúdo desta partição possa sofrer estragos durante o arranque, em
caso de existirem problemas de hardware, este sistema de ficheiros costuma ser
montado inicialmente em modo de leitura read-only. Mais tarde, após todo o sistema
ter sido testado, será remontado em modo read-write.
A partir deste momento, o kernel lança o primeiro processo que executa o programa
«init». O «init» é considerado o pai ancestral de todos os processos que correm no
sistema, pois é ele que começa por executar todos os outros processos. Como é o
primeiro, tem sempre o identificador PID número 1.
A tarefa principal do «init» é lançar processos de acordo com a descrição que se
encontra no ficheiro chamado «/etc/inittab».
Alguns dos processos descritos no «inittab» são lançados apenas uma vez quando o
sistema arranca, enquanto outros são lançados repetidamente: assim que uma cópia
morre, é imediatamente lançada outra em sua substituição.
Existem ainda outros processos que só são lançados pelo «init» quando alguns eventos
acontecem. Por exemplo, é habitual ser lançado o programa «shutdown» sempre que o
utilizador carrega em CTRL-ALT-DEL ou quando uma UPS (unidade de alimentação
ininterrupta) avisa o sistema de que a alimentação está prestes a falhar.

Níveis de execução (runlevels)

A informação mais importante que existe no «/etc/initab» é a linha initdefault:

Esta linha define o nível de execução do sistema, que costuma ser conhecido por
runlevel. No exemplo anterior, foi escolhido o nível de execução número 5, cujo
significado será analisado em seguida.
Um sistema Linux pode trabalhar em sete níveis de execução diferentes:
A tabela inittab
A tabela inittab contém a lista de tarefas que o processo «init» tem de realizar:

Cada linha deste ficheiro é composta por 4 campos separados por caracteres «:» e
corresponde a um programa que deve ser executado pelo «init».
O primeiro campo atribui uma identificação a cada linha e o segundo campo tem a lista
de runlevels em que o comando deve ser executado. O terceiro campo define opções
sobre a forma como os comandos são executados e o último campo tem o nome do
programa a executar.
A linha inicial é diferente de todas as outras, porque serve apenas para identificar o
runlevel com que o sistema arranca:

A primeira linha que realmente contém comandos para serem executados pelo «init» é
a que vem a seguir:
Esta linha é executada imediatamente assim que o sistema arranca, pelo que não tem
nenhum runlevel definido. A instrução «/etc/rc.d/rc.sysinit» executa um script de shell,
que faz toda a inicialização do hardware do sistema.
Em seguida, temos uma sequência de 7 linhas praticamente iguais, que executam o
script de inicialização «/etc/re.d/rc» (runtime configuration), de acordo com cada nível
de execução:

Este script é responsável por lançar todos os serviços do sistema, como a gestão de
impressoras, serviços de rede, etc. Como iremos ver adiante, o seu funcionamento varia
de acordo com o runlevel em que o sistema arrancou.
Nas linhas que se seguem, definem-se as acções a tomar sempre que alguns eventos
acontecem. Por exemplo, quando o utilizador carrega em CTRL-ALT-DEL ou quando uma
UPS avisa que a energia está prestes a faltar, é executado um shutdown automático.
Depois disto, temos um conjunto de 6 linhas muito importantes, que executam o
programa «mingetty» em cada consola virtual de tty1 a tty6:

O «mingetty» é o programa que o sistema utiliza para fazer o pedido de login aos
utilizadores. Este programa faz a validação do nome dos utilizadores e da respectiva
senha, lançando em seguida o interpretador de comandos”.
São estas 6 linhas do «inittab» que mandam lançar 6 cópias do programa «mingetty»,
para cada uma das primeiras 6 consolas virtuais do sistema. E apenas por esse motivo
que nos aparece a prompt «login:» em cada uma dessas consolas virtuais.