Capítulo 3. A inicialização do sistema

Índice

3.1. Uma visão geral do processo de arranque
3.1.1. Stage 1: the UEFI
3.1.2. Estágio 2: o gestor de arranque
3.1.3. Estágio 3: o mini-sistema Debian
3.1.4. Estágio 4: o sistema Debian normal
3.2. Systemd
3.2.1. init do Systemd
3.2.2. Systemd login
3.3. A mensagem do kernel
3.4. A mensagem do sistema
3.5. System management
3.6. Other system monitors
3.7. System configuration
3.7.1. O nome da máquina
3.7.2. O sistema de ficheiros
3.7.3. Inicialização da interface de rede
3.7.4. Cloud system initialization
3.7.5. Customization example to tweak sshd service
3.8. O sistema udev
3.9. A inicialização de módulos do kernel

É inteligente para si como o administrador do sistema ter uma ideia como o sistema Debian é arranca e é configurado. Apesar dos detalhes exactos estarem nos ficheiros de código-fonte dos pacotes instalados e nas suas documentações, é um pouco exagerado para a maioria de nós.

Here is a rough overview of the key points of the Debian system initialization. Since the Debian system is a moving target, you should refer to the latest documentation.

O sistema do computador passa por várias fases de processos de arranque desde o ligar da energia até que oferece, ao utilizador, o sistema operativo (SO) totalmente funcional.

Para simplicidade, limito a discussão à plataforma PC típico com a instalação por omissão.

O processo típico de arranque é como um foguete de quatro etapas. Cada etapa do foguete entrega o controle do sistema à próxima etapa.

É claro que, estes podem ser configurados de modo diferente. Por exemplo, se compilou o seu próprio kernel, pode estar a saltar o passo com o mini sistema Debian. Portanto por favor não assuma que é este o caso para o seu sistema até que o verifique por si próprio.

The Unified Extensible Firmware Interface (UEFI) defines a boot manager as part of the UEFI specification. When a computer is powered on, the boot manager is the 1st stage of the boot process which checks the boot configuration and based on its settings, then executes the specified OS boot loader or operating system kernel (usually boot loader). The boot configuration is defined by variables stored in NVRAM, including variables that indicate the file system paths to OS loaders or OS kernels.

An EFI system partition (ESP) is a data storage device partition that is used in computers adhering to the UEFI specification. Accessed by the UEFI firmware when a computer is powered up, it stores UEFI applications and the files these applications need to run, including operating system boot loaders. (On the legacy PC system, BIOS stored in the MBR may be used instead.)

The boot loader is the 2nd stage of the boot process which is started by the UEFI. It loads the system kernel image and the initrd image to the memory and hands control over to them. This initrd image is the root filesystem image and its support depends on the bootloader used.

The Debian system normally uses the Linux kernel as the default system kernel. The initrd image for the current 5.x Linux kernel is technically the initramfs (initial RAM filesystem) image.

There are many boot loaders and configuration options available.


[Atenção] Atenção

Não brinque com os gestores de arranque sem ter discos de arranque de recuperação (caneta USB, CD ou disquete) criados a partir de imagens do pacote grub-rescue-pc. Torna-o capaz de arrancar o seu sistema mesmo sem um gestor de arranque funcional no disco rígido.

For UEFI system, GRUB2 first reads the ESP partition and uses UUID specified for search.fs_uuid in "/boot/efi/EFI/debian/grub.cfg" to determine the partition of the GRUB2 menu configuration file "/boot/grub/grub.cfg".

The key part of the GRUB2 menu configuration file looks like:

menuentry 'Debian GNU/Linux' ... {
        load_video
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root fe3e1db5-6454-46d6-a14c-071208ebe4b1
        echo    'Loading Linux 5.10.0-6-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-6-amd64 root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-6-amd64
}

For this part of /boot/grub/grub.cfg, this menu entry means the following.


[Dica] Dica

You can enable to see kernel boot log messages by removing quiet in "/boot/grub/grub.cfg". For the persistent change, please edit "GRUB_CMDLINE_LINUX_DEFAULT="quiet"" line in "/etc/default/grub".

[Dica] Dica

You can customize GRUB splash image by setting GRUB_BACKGROUND variable in "/etc/default/grub" pointing to the image file or placing the image file itself in "/boot/grub/".

Veja "info grub" e grub-install(8).

O mini-sistema Debian é o 3º estágio do processo de arranque que é iniciado pelo gestor de arranque. Corre o kernel do sistema com o sistema de ficheiros raiz dele na memória. Este é um estágio preparatório opcional do processo de arranque.

[Nota] Nota

O termo "mini-sistema Debian" é cunhado pelo autor para descrever este 3º estágio do processo de arranque para este documento. Este sistema é geralmente referido como o initrd ou sistema initramfs. É utilizado pelo Instalador de Debian um sistema semelhante em memória .

O programa "/init" é executado como o primeiro programa neste sistema de ficheiros raiz em memória. É um programa que inicializa o kernel no espaço de utilizador e entrega o controle ao próximo estágio. Este mini-sistema Debian oferece flexibilidade ao processo de arranque tal como adicionar módulos de kernel antes do processo de arranque principal ou montar o sistema de ficheiros raiz como um encriptado.

  • O programa "/init" é um programa de script de shell se a initramfs for criada pelo initramfs-tools.

    • Pode interromper esta parte do processo de arranque para obter a shell de root ao fornecer "break=init" etc. ao parâmetro de arranque do kernel. Veja o script "/init" para mais condições de interrupção. Este ambiente shell é suficientemente sofisticado para fazer uma boa inspecção do hardware da sua máquina.

    • Os comandos disponíveis neste mini-sistema Debian são versões reduzidas e disponibilizados principalmente por uma ferramenta GNU chamada busybox(1).

  • O programa "/init" é um programa binário do systemd se a initramfs for criada pelo dracut.

    • Os comandos disponíveis neste mini-sistema Debian são versões reduzidas do ambiente systemd(1).

[Cuidado] Cuidado

Precisa de utilizar a opção "-n" para o comando mount quando está no sistema de ficheiros raiz apenas de leitura.

O sistema Debian normal é o 4º estágio do processo de arranque que é iniciado pelo mini-sistema Debian. O kernel do sistema para o mini-sistema Debian continua a correr nesse ambiente. O sistema de ficheiros raiz é mudado daquele na memória para o que está no sistema de ficheiros do disco rígido real.

O programa init é executado como o primeiro programa com PID=1 para executar o processo de arranque principal de arrancar muitos programas. O caminho de ficheiro predefinido ao programa init é "/usr/sbin/init" mas pode ser alterado pelo parâmetro de arranque do kernel como "init=/path/to/init_program".

"/usr/sbin/init" is symlinked to "/lib/systemd/systemd" after Debian 8 Jessie (released in 2015).

[Dica] Dica

O comando de iniciação atual do seu sistema pode ser verificado pelo comando "ps --pid 1 -f".


[Dica] Dica

Veja Debian wiki: BootProcessSpeedup para as dicas mais recentes em como acelerar o processo de arranque.

When the Debian system starts, /usr/sbin/init symlinked to /usr/lib/systemd is started as the init system process (PID=1) owned by root (UID=0). See systemd(1).

O processo init do systemd espalha processos em paralelo com base nos arquivos de configuração do unit (veja systemd.unit(5)) os quais são escritos em estilo declarativo em vez do estilo processual tipo SysV.

The spawned processes are placed in individual Linux control groups named after the unit which they belong to in the private systemd hierarchy (see cgroups and Secção 4.7.5, “Linux security features”).

Units for the system mode are loaded from the "System Unit Search Path" described in systemd.unit(5). The main ones are as follows in the order of priority:

  • "/etc/systemd/system/*": System units created by the administrator

  • "/run/systemd/system/*": Runtime units

  • "/lib/systemd/system/*": System units installed by the distribution package manager

As suas inter-dependências são especificadas pelas directivas "Wants=", "Requires=", "Before=", "After=", … (veja "MAPPING OF UNIT PROPERTIES TO THEIR INVERSES" em systemd.unit(5)). Os controlos de recursos estão também definidos (veja systemd.resource-control(5)).

O sufixo do ficheiro de configuração da unidade codifica os seus tipos como:

  • *.service descreve o processo controlado e supervisionado pelo systemd. Veja systemd.service(5).

  • *.device descreve o aparelho exposto em sysfs(5) como uma árvore de aparelhos do udev(7). Veja systemd.device(5).

  • *.mount descreve o ponto de montagem do sistema de ficheiros controlado e supervisionado pelo systemd. Veja systemd.mount(5).

  • *.automount Descreve o ponto de montagem automático do sistema de ficheiros controlado e supervisionado pelo systemd. Veja systemd.automount(5).

  • *.swap descreve o aparelho ou ficheiro de memória virtual (swap) controlado e supervisionado pelo systemd. Veja systemd.swap(5).

  • *.path descreve o caminho monitorizado pelo systemd para activação baseada-no-caminho. Veja systemd.path(5).

  • *.socket descreve o socket controlado e supervisionado pelo systemd para activação baseada-em-socket. Veja systemd.socket(5).

  • *.timer descreve o temporizador controlado e supervisionado pelo systemd para activação baseada-em-temporização. Veja systemd.timer(5).

  • *.slice gere recursos com cgroups(7). Veja systemd.slice(5).

  • *.scope é criado programaticamente a usar as interfaces de barramento do systemd para gerir um conjunto de processos do sistema. Veja systemd.scope(5).

  • *.target agrupa outros ficheiros de configuração de unit para criar o ponto de sincronização durante o arranque. Veja systemd.target(5).

Após o arranque do sistema (o, init), o processo systemd tenta arrancar o "/lib/systemd/system/default.target (que normalmente é uma ligaö#ao simbólica para "graphical.target"). Primeiro, algumas unidades alvo especiais (veja systemd.special(7)) tais como "local-fs.target", "swap.target" e "cryptsetup.target" são puxadas para montar os sistemas de ficheiros. Depois, outras unidades alvo são também puxadas pelas dependências da unidade alvo. Para mais detalhes. leia bootup(7).

O systemd oferece funcionalidades de compatibilidade regressiva. Os scripts de arranque estilo SysV em "/etc/init.d/rc[0123456S].d/[KS]name" são ainda analisados e telinit(8) é traduzido em pedidos activação de unidade do systemd.

[Cuidado] Cuidado

Os runlevel 2 a 4 emulados são todos direccionados por uma ligação simbólica ao mesmo "alvo de multi-utilizador".

When a user logins to the Debian system via gdm3(8), sshd(8), etc., /lib/systemd/system --user is started as the user service manager process owned by the corresponding user. See systemd(1).

The systemd user service manager process spawns processes in parallel based on the declarative unit configuration files (see systemd.unit(5) and [email protected](5)).

Units for the user mode are loaded from the "User Unit Search Path" described in systemd.unit(5). The main ones are as follows in the order of priority:

  • "~/.config/systemd/user/*": User configuration units

  • "/etc/systemd/user/*": User units created by the administrator

  • "/run/systemd/user/*": Runtime units

  • "/lib/systemd/user/*": User units installed by the distribution package manager

These are managed in the same way as Secção 3.2.1, “init do Systemd”.

As mensagens de erros do kernel mostradas na consola podem ser configuradas ao definir o nível de limiar dele.

# dmesg -n3

Under systemd, both kernel and system messages are logged by the journal service systemd-journald.service (a.k.a journald) either into a persistent binary data below "/var/log/journal" or into a volatile binary data below "/run/log/journal/". These binary log data are accessed by the journalctl(1) command. For example, you can display log from the last boot as:

$ journalctl -b

Under systemd, the system logging utility rsyslogd(8) may be uninstalled. If it is installed, it changes its behavior to read the volatile binary log data (instead of pre-systemd default "/dev/log") and to create traditional permanent ASCII system log data. This can be customized by "/etc/default/rsyslog" and "/etc/rsyslog.conf" for both the log file and on-screen display. See rsyslogd(8) and rsyslog.conf(5). See also Secção 9.3.2, “Analisador de relatório (Log)”.

The systemd offers not only init system but also generic system management operations with the systemctl(1) command.

Tabela 3.6. List of typical systemctl command snippets

Operação Fragmentos de comando
List all available unit types "systemctl list-units --type=help"
List all target units in memory "systemctl list-units --type=target"
List all service units in memory "systemctl list-units --type=service"
List all device units in memory "systemctl list-units --type=device"
List all mount units in memory "systemctl list-units --type=mount"
Lista todas unidades de socket em memória "systemctl list-sockets"
Lista todas as unidades de temporizador em memória "systemctl list-timers"
Iniciar o "$unit" "systemctl start $unit"
Parar o "$unit" "systemctl stop $unit"
Recarregar configuração específica do serviço "systemctl reload $unit"
Parar e iniciar todo "$unit" "systemctl restart $unit"
Iniciar o "$unit" e parar todos os outros "systemctl isolate $unit"
Mudar para "gráfico" (sistema GUI) "systemctl isolate graphical"
Mudar para "multi-utilizador" (sistema CLI) "systemctl isolate multi-user"
Mudar para "recuperação" (sistema CLI de único utilizador) "systemctl isolate rescue"
Enviar sinal kill ao "$unit" "systemctl kill $unit"
Verificar se o serviço "$unit" está ativo "systemctl is-active $unit"
Verificar se o serviço "$unit" falhou "systemctl is-failed $unit"
Verifica o estado de "$unit|$PID|aparelho" "systemctl status $unit|$PID|$device"
Mostra propriedades de 1"$unit|$job" "systemctl show $unit|$job"
Reinicia um "$unit" falhado "systemctl reset-failed $unit"
List dependências de todos os serviços unit "systemctl list-dependencies --all"
Lista ficheiros unit instalados no sistema "systemctl list-unit-files"
Ativa "$unit" (adicionar ligação simbólica) "systemctl enable $unit"
Desactiva "$unit" (remove ligação simbólica) "systemctl disable $unit"
Desmascara "$unit" (remove ligação simbólica para "/dev/null") "systemctl unmask $unit"
Mascara "$unit" (adicionar ligação simbólica para "/dev/null") "systemctl mask $unit"
Obter definição de alvo-predefinido "systemctl get-default"
Define alvo-predefinido para "graphical" (sistema GUI) "systemctl set-default graphical"
Define alvo-predefinido para "multi-user" (sistema CLI) "systemctl set-default multi-user"
Mostra ambiente da função "systemctl show-environment"
Define "variável" de ambiente de função para "valor" "systemctl set-environment variável=valor"
Remove a definição da "variável" de ambiente de função "systemctl unset-environment variável"
Reinicia todos os ficheiros unit e os daemons "systemctl daemon-reload"
Desligar o sistema "systemctl poweroff"
Desligar e reiniciar o sistema "systemctl reboot"
Suspender o sistema "systemctl suspend"
Hibernar o sistema "systemctl hibernate"

Aqui, "$unit" nos exemplos em cima pode ser um único nome de unidade (sufixos como .service e .target são opcionais) ou, em muitos casos, especificações de múltiplas unidades (a simbologia da shell "*", "?", "[]" a utilizar fnmatch(3) serão correspondidos aos nomes primários de todas as unidades presentemente em memória).

Os comandos de alteração do estado do sistema nos exemplos em cima são tipicamente precedidos por "sudo" para obter os privilégios administrativos necessários.

Os resultados de "systemctl status $unit|$PID|$aparelho" usam cores no ponto ("●") para sumarizar rapidamente o estado da unidade.

  • Ponto "●" branco indica estado "inativo" ou "desactivado".

  • Ponto "●" vermelho indica um estado de "falha" ou "erro".

  • Ponto "●" verde indica um estado "ativo", "a reiniciar" ou "a ativar".

Here are a list of other monitoring command snippets under systemd. Please read the pertinent manpages including cgroups(7).


As opções de montagem de sistemas de ficheiros de discos normais e de rede são definidas em "/etc/fstab". Veja fstab(5) e Secção 9.6.7, “Optimização do sistema de ficheiros por opções de montagem”.

A configuração do sistema de ficheiros encriptado é definida em "/etc/crypttab". Veja crypttab(5)

A configuração do software RAID com mdadm(8) é definida em "/etc/mdadm/mdadm.conf". Veja mdadm.conf(5).

[Atenção] Atenção

Após montar todos os sistemas de ficheiros, os ficheiros temporários em "/tmp", "/var/lock" e "/var/run" são limpos para cada arranque.

The cloud system instance may be launched as a clone of "Debian Official Cloud Images" or similar images. For such system instance, personalities such as hostname, filesystem, networking, locale, SSH keys, users and groups may be configured using functionalities provided by cloud-init and netplan.io packages with multiple data sources such as files placed in the original system image and external data provided during its launch. These packages enable the declarative system configuration using YAML data.

See more at "Cloud Computing with Debian and its descendants", "Cloud-init documentation" and Secção 5.4, “The modern network configuration for cloud”.

Com uma instalação predefinida, muitos serviços de rede (veja Capítulo 6, Aplicações de rede) são arrancados como processos daemon após network.target durante o arranque do sistema pelo systemd. O "sshd" não é excepção. Vamos mudar isto para arranque a-pedido do "sshd" como um exemplo de personalização.

Primeiro, desativar a unidade de serviço instalada no sistema.

 $ sudo systemctl stop sshd.service
 $ sudo systemctl mask sshd.service

The on-demand socket activation system of the classic Unix services was through the inetd (or xinetd) superserver. Under systemd, the equivalent can be enabled by adding *.socket and *.service unit configuration files.

sshd.socket para especificar um socket onde escutar

[Unit]
Description=SSH Socket for Per-Connection Servers

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target

[email protected] como o ficheiro de serviço correspondente do sshd.socket

[Unit]
Description=SSH Per-Connection Server

[Service]
ExecStart=-/usr/sbin/sshd -i
StandardInput=socket

Depois reinicie.

 $ sudo systemctl daemon-reload

The udev system provides mechanism for the automatic hardware discovery and initialization (see udev(7)) since Linux kernel 2.6. Upon discovery of each device by the kernel, the udev system starts a user process which uses information from the sysfs filesystem (see Secção 1.2.12, “procfs e sysfs”), loads required kernel modules supporting it using the modprobe(8) program (see Secção 3.9, “A inicialização de módulos do kernel”), and creates corresponding device nodes.

[Dica] Dica

Se "/lib/modules/versão-de-kernel/modules.dep" não foi gerado de modo apropriado pelo depmod(8) por alguma razão, os módulos podem não carregar como esperado pelo sistema udev. Execute "depmod -a" para o corrigir.

Para regras de montagem em "/etc/fstab", os nós de aparelhos não precisam de ser os estáticos. Pode usar o UUID para montar os aparelhos em vez dos nomes de aparelho como "/dev/sda". Veja Secção 9.6.3, “Aceder a partição a usar UUID”.

Como o sistema udev é de certa forma um alvo em movimento, deixo os detalhes para outras documentações e descrevo a informação mínima aqui.

[Atenção] Atenção

Don't try to run long running programs such as backup script with RUN in udev rules as mentioned in udev(7). Please create a proper systemd.service(5) file and activate it, instead. See Secção 10.2.3.2, “Mount event triggered backup”.

O programa modprobe(8) permite-nos configurar o kernel Linux em execução a partir do processo de utilizador ao adicionar e remover módulos do kernel. O sistema udev (veja Secção 3.8, “O sistema udev”) automatiza a invocação dele para ajudar na inicialização dos módulos de kernel.

Existem módulos de não-hardware e módulos driver de hardware especial como os seguintes que precisam de ser pré-carregados ao listá-los no ficheiro "/etc/modules" (veja modules(5)).

Os ficheiros de configuração para o programa modprobe(8) estão localizados sob o diretório "/etc/modprobes.d/" como explicado em modprobe.conf(5). (Se deseja evitar que alguns módulos do kernel sejam carregados automaticamente, considere metê-los em lista negra no ficheiro "/etc/modprobes.d/blacklist".)

O ficheiro "/lib/modules/version/modules.dep" gerado pelo programa depmod(8) descreve as dependências dos módulos usados pelo programa modprobe(8).

[Nota] Nota

Se tiver problemas com o carregamento de módulos durante o arranque ou com o modprobe(8), "depmod -a" pode resolver esses problemas ao reconstruir "modules.dep".

O programa modinfo(8) mostra informação sobre um módulo do kernel Linux.

O programa lsmod(8) formata lindamente o conteúdo de "/proc/modules" e mostra que módulos do kernel que estão atualmente carregados.

[Dica] Dica

Pode identificar o hardware exacto no seu sistema. Veja Secção 9.5.3, “Identificação do hardware”.

Pode configurar o hardware durante o arranque para ativar as funcionalidades esperadas do hardware. Veja Secção 9.5.4, “Configuração do hardware”.

Pode provavelmente adicionar suporte para o seu aparelho especial ao recompilar o kernel. Veja Secção 9.10, “O kernel”.