Neste tópico iremos abordar a inicialização do sistema, as mensagens de log, entender um pouco do SysVinit, Upstart e Systemd e verificar alguns parâmetros de inicialização que passamos ao kernel.
Veremos também um resumo básico da BIOS, o comando DMESG, os tipos de processos init, initramfs.
Peso 3
Após ligar a máquina, o BIOS (Basic Imput/Output System) irá ler o primeiro setor do dispositivo definido na ordem de boot no setup, procurará um setor de boot válido, e, após encontra-lo, carregará o seu código (programa init) para a memória e passará o controle do hardware ao sistema operacional. Esse processo é chamado de initramfs. A partir deste momento, o sistema identificará o hardware e após a identificação, inicializa os serviços do sistema operacional.
No GNU/Linux, é possível passar alguns parâmetros ao kernel, dando instruções de como o sistema deverá inicializar. Geralmente, passamos esses parâmetros quando queremos escolher uma determinada versão do kernel, ou corrigir erros de inicialização do sistema, como quantidade de memória disponível, resolução, nível de execução do sistema e etc.
Tudo isso ocorre na MBR (Master Boot Record) do disco de inicialização. Para a gerência da MBR, podemos ter alguns gerenciadores de bootloader. É o que veremos a seguir.
PS: Estudaremos esses bootloader de forma mais detalhada no tópico 102.2.
Os carregadores de boot (bootloader)
Existem 2 principais programas responsáveis para gerenciar o boot dos sistemas GNU/Linux: o Lilo e o Grub.
Atualmente o Lilo é usado apenas em distribuições antigas e seu arquivo principal de configuração é /etc/lilo.conf. Distribuições atuais usam o Grub como bootloader e parâmetros de inicialização podem ser passados no arquivo /boot/grub/grub.cfg.
É através do bootloader que passamos alguns comandos e parâmetros para o kernel quando queremos fazer uma depuração na inicialização, corrigir problemas, alterar o shell padrão etc.
Alguns parâmetros que podemos passar para o kernel na tela de bootloader.
acpi - liga/desliga o suporte a acpi - acpi=off
init - define outro programa para executar no lugar do /sbin/init - init=/bin/bash
mem - serve para definir a quantidade de memória RAM para o sistema - mem=1024
maxcpus - número máximo de processadores visiveis para o sistema - maxcpus=2
quiet - não exibe as informações durante o boot - quiet
vga - seleciona um modo de vídeo - vga=773
root - serve para definir uma partição raiz diferente da pré-determinada - root=/dev/sda3
ro/rw - monta a partição como somente leitura (ro) ou leitura e escrita (rw) - ro
Para passarmos esses parâmetros, teclamos a tecla "e". Uma imagem parecida com essa deverá aparecer para você:
DMESG (Display Message)
Quando ligamos a máquina com um sistema Linux, várias mensagens são exibidas durante o processo de boot. Essas mensagens indicam a detecção de hardware, inicialização de serviços, detecção de dispositivos etc. Para visualizarmos essas mensagens que podem nos auxiliar na detecção de problemas, usamos o comando dmesg.
Essas informações ficam em um buffer, onde são "apagadas" a cada início do sistema. Pode-se gerar um arquivo com essas informações com o comando dmesg > nome_do_arquivo caso queira comparar com as mensagens de inicializações futuras.
Se quiser ter uma informação mais precisa, basta utilizarmos o grep para filtrar a parte que nos interessa:
dmesg | grep "dev"
SysVinit
Após carregar o bootloader e iniciar o sistema, o kernel identifica o hardware da máquina, identifica os dispositivos, carrega os drivers que estão compilados dentro do kernel e entrega o sistema para o processo init, que é o responsável para disparar os processos que inicializará o restante do sistema. Ele, o init, monta o sistema de arquivos, inicia os sistemas de áudio, inicia os daemons de log, cron, NTP etc, carrega as variáveis e configurações de ambiente e por fim, a tela de login.
Esses processos eram iniciados em /etc/init e seguiam uma ordem já pre-estabelecida dos sistemas, os conhecidos runlevel.
O processo init tem como característica iniciar um processo somente após o outro terminar, pois na época não se havia processadores com multi núcleo como temos hoje. Os programadores não pensavam em paralelização pois isso poderia travar a máquina. A medida que foram surgindo multi-processadores, surgiu-se a ideia de iniciar processos em paralelo para ganhar tempo e velocidade.
O SysVinit utiliza o método de inicialização dos runlevels, que são nada mais que os níveis que o sistema Linux utiliza para iniciar. Existem vários runlevels mas só são utilizados 7. No tópico 101.3 veremos mais sobre runlevels.
O sistema SysVinit ainda utiliza scripts que são executados de acordo com o nível atual de execução do sistema. Como os runlevels são de 0 a 6, dentro do diretório /etc/init.d/ ou /etc/rc.d, teremos vários diretórios nomeados como rc0.d/, rc1.d/, rc2.d/, rc...d/ até o rc6.d/ com seus respectivos scripts.
O método de utilização para iniciar, parar, recarregar ou obter o status de serviços nos sistemas que utilizam o init são:
/etc/init.d/serviço start/stop/restart/status
Portanto, o processo init é o processo pai de todos os processos e o seu PID sempre é 1. O arquivo de configuração para alterar o nível de execução do sistema é o /etc/inittab.
PS: Algum tempo depois, em versões mais novas do Debian, o sistema sysvinit foi utilizado de forma paralela, ou seja, inicialização com dependência entre serviços. Mas isso não vem ao caso para a prova.
Upstart e Systemd
Com o surgimento de processadores multi-core, agora ficou fácil pensar em mais rapidez para a inicialização.
O Upstart trouxe a ideia de reformular o init. Em vez de iniciar somente um após o outro terminar, agora ele poderia disparar eventos que iniciam um determinado serviço e este serviço inicia outro serviço e assim por diante. Caso haja uma falha em iniciar um processo, esse processo era iniciado novamente sem que fosse necessário informar ao processo que gerou o serviço que parou, ou seja, o processo-pai. Esses processos são monitorados agora pelo sub-sistema D-bus.
Sintaxe dos sistemas que utilizam o Upstart:
start/stop serviço
Já o Systemd, parece muito com o Upstart - ativação de eventos, substituição do init etc - porém, ele não precisa mais utilizar os inúmeros scripts que existiam para a inicialização. Ele monitora o PID dos processos iniciados e consegue garantir que todos os processos iniciados por esse serviço, sejam terminados.
Como não existe mais o diretório /etc/init.d/, o Systemd utiliza a sintaxe:
systemctl start/reload/stop/status serviço
Veremos um pouco mais sobre o Upstart e o Systemd no próximo tópico.
Atualmente o Lilo é usado apenas em distribuições antigas e seu arquivo principal de configuração é /etc/lilo.conf. Distribuições atuais usam o Grub como bootloader e parâmetros de inicialização podem ser passados no arquivo /boot/grub/grub.cfg.
É através do bootloader que passamos alguns comandos e parâmetros para o kernel quando queremos fazer uma depuração na inicialização, corrigir problemas, alterar o shell padrão etc.
Alguns parâmetros que podemos passar para o kernel na tela de bootloader.
acpi - liga/desliga o suporte a acpi - acpi=off
init - define outro programa para executar no lugar do /sbin/init - init=/bin/bash
mem - serve para definir a quantidade de memória RAM para o sistema - mem=1024
maxcpus - número máximo de processadores visiveis para o sistema - maxcpus=2
quiet - não exibe as informações durante o boot - quiet
vga - seleciona um modo de vídeo - vga=773
root - serve para definir uma partição raiz diferente da pré-determinada - root=/dev/sda3
ro/rw - monta a partição como somente leitura (ro) ou leitura e escrita (rw) - ro
Para passarmos esses parâmetros, teclamos a tecla "e". Uma imagem parecida com essa deverá aparecer para você:
DMESG (Display Message)
Quando ligamos a máquina com um sistema Linux, várias mensagens são exibidas durante o processo de boot. Essas mensagens indicam a detecção de hardware, inicialização de serviços, detecção de dispositivos etc. Para visualizarmos essas mensagens que podem nos auxiliar na detecção de problemas, usamos o comando dmesg.
Essas informações ficam em um buffer, onde são "apagadas" a cada início do sistema. Pode-se gerar um arquivo com essas informações com o comando dmesg > nome_do_arquivo caso queira comparar com as mensagens de inicializações futuras.
Se quiser ter uma informação mais precisa, basta utilizarmos o grep para filtrar a parte que nos interessa:
dmesg | grep "dev"
SysVinit
Após carregar o bootloader e iniciar o sistema, o kernel identifica o hardware da máquina, identifica os dispositivos, carrega os drivers que estão compilados dentro do kernel e entrega o sistema para o processo init, que é o responsável para disparar os processos que inicializará o restante do sistema. Ele, o init, monta o sistema de arquivos, inicia os sistemas de áudio, inicia os daemons de log, cron, NTP etc, carrega as variáveis e configurações de ambiente e por fim, a tela de login.
Esses processos eram iniciados em /etc/init e seguiam uma ordem já pre-estabelecida dos sistemas, os conhecidos runlevel.
O processo init tem como característica iniciar um processo somente após o outro terminar, pois na época não se havia processadores com multi núcleo como temos hoje. Os programadores não pensavam em paralelização pois isso poderia travar a máquina. A medida que foram surgindo multi-processadores, surgiu-se a ideia de iniciar processos em paralelo para ganhar tempo e velocidade.
O SysVinit utiliza o método de inicialização dos runlevels, que são nada mais que os níveis que o sistema Linux utiliza para iniciar. Existem vários runlevels mas só são utilizados 7. No tópico 101.3 veremos mais sobre runlevels.
O sistema SysVinit ainda utiliza scripts que são executados de acordo com o nível atual de execução do sistema. Como os runlevels são de 0 a 6, dentro do diretório /etc/init.d/ ou /etc/rc.d, teremos vários diretórios nomeados como rc0.d/, rc1.d/, rc2.d/, rc...d/ até o rc6.d/ com seus respectivos scripts.
O método de utilização para iniciar, parar, recarregar ou obter o status de serviços nos sistemas que utilizam o init são:
/etc/init.d/serviço start/stop/restart/status
Portanto, o processo init é o processo pai de todos os processos e o seu PID sempre é 1. O arquivo de configuração para alterar o nível de execução do sistema é o /etc/inittab.
PS: Algum tempo depois, em versões mais novas do Debian, o sistema sysvinit foi utilizado de forma paralela, ou seja, inicialização com dependência entre serviços. Mas isso não vem ao caso para a prova.
Upstart e Systemd
Com o surgimento de processadores multi-core, agora ficou fácil pensar em mais rapidez para a inicialização.
O Upstart trouxe a ideia de reformular o init. Em vez de iniciar somente um após o outro terminar, agora ele poderia disparar eventos que iniciam um determinado serviço e este serviço inicia outro serviço e assim por diante. Caso haja uma falha em iniciar um processo, esse processo era iniciado novamente sem que fosse necessário informar ao processo que gerou o serviço que parou, ou seja, o processo-pai. Esses processos são monitorados agora pelo sub-sistema D-bus.
Sintaxe dos sistemas que utilizam o Upstart:
start/stop serviço
Já o Systemd, parece muito com o Upstart - ativação de eventos, substituição do init etc - porém, ele não precisa mais utilizar os inúmeros scripts que existiam para a inicialização. Ele monitora o PID dos processos iniciados e consegue garantir que todos os processos iniciados por esse serviço, sejam terminados.
Como não existe mais o diretório /etc/init.d/, o Systemd utiliza a sintaxe:
systemctl start/reload/stop/status serviço
Veremos um pouco mais sobre o Upstart e o Systemd no próximo tópico.
Comentários
Postar um comentário