101.2 Lição 1
Certificação: |
LPIC-1 |
---|---|
Versão: |
5.0 |
Tópico: |
101 Arquitetura do sistema |
Objetivo: |
101.2 Inicialização do sistema |
Lição: |
1 de 1 |
Introdução
Para controlar a máquina, o componente principal do sistema operacional — o kernel — deve ser carregado por um programa chamado bootloader (carregador de inicialização), que por sua vez é carregado por um firmware pré-instalado, como a BIOS ou a UEFI. O carregador de inicialização pode ser personalizado para passar parâmetros para o kernel, como a partição que contém o sistema de arquivos raiz ou em qual modo o sistema operacional deve ser executado. Uma vez carregado, o kernel dá seguimento ao processo de inicialização, identificando e configurando o hardware. Por fim, o kernel chama o utilitário responsável por iniciar e gerenciar os serviços do sistema.
Note
|
Em algumas distribuições Linux, os comandos executados nesta lição podem exigir privilégios de root. |
BIOS ou UEFI
Os procedimentos executados pelas máquinas x86 para executar o carregador de inicialização são diferentes conforme se usa a BIOS ou a UEFI. A BIOS, abreviação de Basic Input/Output System, é um programa armazenado em um chip de memória não volátil conectado à placa-mãe, executado sempre que o computador é ligado. Esse tipo de programa é chamado firmware e seu local de armazenamento é separado dos outros dispositivos de armazenamento do sistema. A BIOS pressupõe que os primeiros 440 bytes no primeiro dispositivo de armazenamento — seguindo a ordem definida no utilitário de configuração da BIOS — são o primeiro estágio do bootloader (também chamado de bootstrap). Os primeiros 512 bytes de um dispositivo de armazenamento são o que se chama de MBR (Master Boot Record) dos dispositivos de armazenamento que usam o esquema de partição DOS padrão e, além do primeiro estágio do gerenciador de inicialização, eles contêm a tabela de partições. Se o MBR não contiver os dados corretos, o sistema não poderá inicializar, a menos que um método alternativo seja empregado.
De um modo geral, as etapas pré-operacionais para inicializar um sistema equipado com BIOS são:
-
O processo POST (power-on self-test) é executado para identificar falhas simples de hardware assim que a máquina é ligada.
-
A BIOS ativa os componentes básicos para carregar o sistema, como a saída de vídeo, o teclado e as mídias de armazenamento.
-
A BIOS carrega o primeiro estágio do bootloader a partir do MBR (os primeiros 440 bytes do primeiro dispositivo, conforme definido no utilitário de configuração da BIOS).
-
O primeiro estágio do bootloader chama o segundo estágio, responsável por apresentar as opções de inicialização e carregar o kernel.
A UEFI, abreviação de Unified Extensible Firmware Interface, difere da BIOS em alguns pontos-chave. Como a BIOS, a UEFI também é um firmware, mas pode identificar partições e ler muitos sistemas de arquivos nelas. A UEFI não depende do MBR, levando em consideração apenas as configurações armazenadas na memória não-volátil (NVRAM) conectada à placa-mãe. Essas definições indicam a localização dos programas compatíveis com a UEFI, chamados aplicativos EFI, que serão executados automaticamente ou chamados a partir de um menu de inicialização. Os aplicativos EFI podem ser carregadores de inicialização, seletores de sistema operacional, ferramentas para diagnóstico e reparo do sistema etc. Eles devem estar em uma partição de um dispositivo de armazenamento convencional e em um sistema de arquivos compatível. Os sistemas de arquivos compatíveis padrão são FAT12, FAT16 e FAT32 para dispositivos de bloco e ISO-9660 para mídia ótica. Essa abordagem permite a implementação de ferramentas muito mais sofisticadas do que as que seriam possíveis com a BIOS.
A partição que contém os aplicativos EFI é chamada de Partição de Sistema EFI ou apenas ESP. Essa partição não deve ser compartilhada com outros sistemas de arquivos do sistema, como o sistema de arquivos raiz ou os sistemas de arquivos de dados do usuário. O diretório EFI na partição ESP contém os aplicativos apontados pelas entradas salvas na NVRAM.
De maneira geral, as etapas de inicialização do pré-sistema operacional em um sistema com UEFI são:
-
O processo POST (power-on self-test) é executado para identificar falhas simples de hardware assim que a máquina é ligada.
-
A UEFI ativa os componentes básicos para carregar o sistema, como a saída de vídeo, o teclado e as mídias de armazenamento.
-
O firmware da UEFI lê as definições armazenadas na NVRAM para executar o aplicativo EFI predefinido armazenado no arquivo de sistemas da partição ESP. Normalmente, o aplicativo EFI predefinido é um bootloader.
-
Se o aplicativo EFI predefinido for um bootloader, ele carrega o kernel para iniciar o sistema operacional.
O padrão UEFI também suporta um recurso chamado Inicialização Segura, que permite apenas a execução de aplicativos EFI assinados, ou seja, aplicativos EFI autorizados pelo fabricante do hardware. Esse recurso aumenta a proteção contra software malicioso, mas pode dificultar a instalação de sistemas operacionais não cobertos pela garantia do fabricante.
O bootloader
O carregador de inicialização mais popular para Linux na arquitetura x86 é o GRUB (Grand Unified Bootloader). Assim que é chamado pela BIOS ou pela UEFI, o GRUB exibe uma lista de sistemas operacionais disponíveis para inicialização. Às vezes, a lista não aparece automaticamente, mas ela pode ser invocada pressionando Shift enquanto o GRUB está sendo chamado pela BIOS. Nos sistemas UEFI, a tecla a ser usada é Esc.
No menu do GRUB, é possível escolher qual dos kernels instalados deve ser carregado e passar novos parâmetros para ele. A maioria dos parâmetros do kernel segue o padrão opção=valor
. Alguns dos parâmetros mais úteis do kernel são:
acpi
-
Ativa/desativa o suporte a ACPI.
acpi=off
desabilita o suporte a ACPI. init
-
Define um iniciador de sistema alternativo. Por exemplo,
init=/bin/bash
define o shell Bash como iniciador. Assim, uma sessão do shell será iniciada logo após o processo de inicialização do kernel. systemd.unit
-
Define o destino do systemd a ser ativado. Por exemplo,
systemd.unit=graphical.target
. O systemd também aceita os níveis de execução numéricos definidos para SysV. Para ativar o nível de execução 1, por exemplo, é necessário apenas incluir o número1
ou a letraS
(abreviação de “single”) como parâmetro do kernel. mem
-
Define a quantidade de RAM disponivel para o sistema. Este parâmetro é útil para limitar a RAM disponível para cada convidado em uma máquina virtual. Assim,
mem=512M
limita a 512 megabytes a quantidade de RAM disponível para um sistema convidado em particular. maxcpus
-
Limita o número de processadores (ou núcleos de processador) visíveis ao sistema em máquinas multiprocessador simétricas. Também é útil para máquinas virtuais. Um valor de
0
desativa o suporte a máquinas multiprocessador e tem o mesmo efeito do parâmetro do kernelnosmp
. O parâmetromaxcpus=2
limita a dois o número de processadores disponíveis para o sistema operacional. quiet
-
Oculta a maioria das mensagens de inicialização.
vga
-
Seleciona um modo de vídeo. O parâmetro
vga=ask
mostra uma lista dos modos disponíveis a escolher. root
-
Define a partição raiz, diferente da que está configurada no bootloader. Por exemplo,
root=/dev/sda3
. rootflags
-
Opções de montagem para o arquivo de sistemas raiz.
ro
-
Torna somente para leitura a montagem inicial do arquivo de sistemas raiz.
rw
-
Permite escrever no arquivo de sistemas raiz durante a montagem inicial.
Geralmente não é necessário alterar os parâmetros do kernel, mas isso pode ser útil para detectar e resolver problemas relacionados ao sistema operacional. Os parâmetros do kernel devem ser adicionados ao arquivo /etc/default/grub
na linha GRUB_CMDLINE_LINUX
para que persistam após a inicialização. É necessário gerar um novo arquivo de configuração para o carregador de inicialização a cada vez que /etc/default/grub
é alterado, o que é feito com o comando grub-mkconfig -o /boot/grub/grub.cfg
. Quando o sistema operacional estiver rodando, os parâmetros do kernel usados para carregar a sessão ficam disponíveis para leitura no arquivo /proc/cmdline
.
Note
|
A configuração do GRUB será discutida mais adiante, em outra lição. |
Inicialização do sistema
Além do kernel, o sistema operacional depende de outros componentes que fornecem os recursos esperados. Muitos desses componentes são carregados durante o processo de inicialização do sistema e vão de simples scripts de shell a programas de serviços mais complexos. Os scripts geralmente são usados para executar tarefas de curta duração que serão finalizadas durante o processo de inicialização. Os serviços, também conhecidos como daemons, podem ficar ativos o tempo todo, pois muitas vezes são responsáveis por aspectos específicos do sistema operacional.
Existe uma enorme diversidade de maneiras de incorporar scripts de inicialização e daemons com as mais diferentes características em uma distribuição Linux. Esse fato, historicamente, impediu o desenvolvimento de uma solução única que atenda às expectativas dos mantenedores e usuários de todas as distribuições Linux. No entanto, qualquer ferramenta escolhida pelos mantenedores de distribuições para executar esta função será capaz de pelo menos iniciar, interromper e reiniciar os serviços do sistema. Essas ações geralmente são executadas pelo próprio sistema após uma atualização de software, por exemplo, mas o administrador do sistema quase sempre precisa reiniciar o serviço manualmente após fazer modificações em seu arquivo de configuração.
Também é conveniente que um administrador do sistema possa ativar um conjunto específico de daemons, dependendo das circunstâncias. Por exemplo, deve ser possível executar apenas um conjunto mínimo de serviços para executar tarefas de manutenção do sistema.
Note
|
Estritamente falando, o sistema operacional é apenas o kernel e seus componentes, que controlam o hardware e gerenciam todos os processos. É comum, no entanto, usar o termo “sistema operacional” de maneira mais vaga, para designar um grupo inteiro de programas distintos que compõem o ambiente de software onde o usuário pode executar as tarefas computacionais básicas. |
A inicialização do sistema operacional começa quando o carregador de inicialização carrega o kernel na RAM. Nesse momento, o kernel assume o controle da CPU e começa a detectar e configurar os aspectos fundamentais do sistema operacional, como a configuração básica de hardware e o endereçamento de memória.
O kernel abre então o initramfs (initial RAM filesystem). O initramfs é um arquivo que contém um sistema de arquivos raiz temporário usado durante o processo de inicialização. O principal objetivo de um arquivo initramfs é fornecer os módulos necessários para que o kernel possa acessar o sistema de arquivos raiz “de verdade” do sistema operacional.
Logo que o sistema de arquivos raiz fica disponível, o kernel monta todos os sistemas de arquivos configurados em /etc/fstab
e, em seguida, executa o primeiro programa, um utilitário chamado init
. O programa init
é responsável por executar todos os scripts de inicialização e daemons do sistema. Existem implementações distintas desses iniciadores de sistema além do tradicional init, como o systemd e o Upstart. Depois que o programa init é carregado, o initramfs é removido da RAM.
- Padrão SysV
-
Um gerenciador de serviços baseado no padrão SysVinit controla quais daemons e recursos estarão disponíveis empregando o conceito de níveis de execução. Os níveis de execução são numerados de 0 a 6 e são projetados pelos mantenedores da distribuição para atender a propósitos específicos. As únicas definições de nível de execução compartilhadas entre todas as distribuições são os níveis 0, 1 e 6.
- systemd
-
O systemd é um gerenciador de sistemas e serviços moderno, com uma camada de compatibilidade para os comandos e níveis de execução do SysV. O systemd possui uma estrutura concorrente, emprega sockets e D-Bus para a ativação de serviços, execução de daemon sob demanda, monitoramento de processos com cgroups, snapshot support, recuperação da sessão do sistema, controle de ponto de montagem e um controle de serviços baseado em dependências. Nos últimos anos, a maioria das grandes distribuições Linux adotou gradualmente o systemd como seu gerenciador de sistema padrão.
- Upstart
-
Como o systemd, o Upstart é um substituto para o init. O foco do Upstart é acelerar o processo de inicialização, paralelizando o processo de carregamento dos serviços do sistema. O Upstart foi usado pelas distribuições baseadas no Ubuntu em versões anteriores, mas hoje deu lugar ao systemd.
Inspeção da inicialização
Às vezes ocorrem erros durante o processo de inicialização, mas nem sempre eles são críticos a ponto de interromper completamente o sistema operacional. Não obstante, esses erros podem comprometer o comportamento esperado do sistema. Todos os erros resultam em mensagens que podem ser usadas para investigações futuras, pois elas contêm informações valiosas sobre quando e como o erro ocorreu. Mesmo quando nenhuma mensagem de erro é gerada, as informações coletadas durante o processo de inicialização podem ser úteis para fins de ajuste e configuração.
O espaço de memória em que o kernel armazena suas mensagens, incluindo as mensagens de inicialização, é chamado de buffer de anel do kernel. As mensagens são mantidas nesse buffer mesmo quando não são exibidas durante o processo de inicialização (por exemplo, quando uma animação é exibida em vez da mensagem). No entanto, o buffer de anel do kernel perde todas as mensagens quando o sistema é desligado ou se o comando dmesg --clear
for executado. Sem opções, o comando dmesg
exibe as mensagens atuais no buffer de anel do kernel:
$ dmesg [ 5.262389] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [ 5.449712] ip_tables: (C) 2000-2006 Netfilter Core Team [ 5.460286] systemd[1]: systemd 237 running in system mode. [ 5.480138] systemd[1]: Detected architecture x86-64. [ 5.481767] systemd[1]: Set hostname to <torre>. [ 5.636607] systemd[1]: Reached target User and Group Name Lookups. [ 5.636866] systemd[1]: Created slice System Slice. [ 5.637000] systemd[1]: Listening on Journal Audit Socket. [ 5.637085] systemd[1]: Listening on Journal Socket. [ 5.637827] systemd[1]: Mounting POSIX Message Queue File System... [ 5.638639] systemd[1]: Started Read required files in advance. [ 5.641661] systemd[1]: Starting Load Kernel Modules... [ 5.661672] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro [ 5.694322] lp: driver loaded but no devices found [ 5.702609] ppdev: user-space parallel port driver [ 5.705384] parport_pc 00:02: reported by Plug and Play ACPI [ 5.705468] parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] [ 5.800146] lp0: using parport0 (interrupt-driven). [ 5.897421] systemd-journald[352]: Received request to flush runtime journal from PID 1
A saída do dmesg
pode ter centenas de linhas, portanto a listagem anterior contém apenas o trecho que mostra o kernel chamando o gerenciador de serviços systemd. Os valores no início das linhas são a quantidade de segundos desde o início do carregamento do kernel.
Nos sistemas baseados em systemd, o comando journalctl
mostra as mensagens de inicialização com as opções -b
, --boot
, -k
ou --dmesg
. O comando journalctl --list-boots
mostra uma lista de números de inicialização relativos à inicialização atual, seu hash de identificação e os registros de data e hora da primeira e última mensagens correspondentes:
$ journalctl --list-boots -4 9e5b3eb4952845208b841ad4dbefa1a6 Thu 2019-10-03 13:39:23 -03—Thu 2019-10-03 13:40:30 -03 -3 9e3d79955535430aa43baa17758f40fa Thu 2019-10-03 13:41:15 -03—Thu 2019-10-03 14:56:19 -03 -2 17672d8851694e6c9bb102df7355452c Thu 2019-10-03 14:56:57 -03—Thu 2019-10-03 19:27:16 -03 -1 55c0d9439bfb4e85a20a62776d0dbb4d Thu 2019-10-03 19:27:53 -03—Fri 2019-10-04 00:28:47 -03 0 08fbbebd9f964a74b8a02bb27b200622 Fri 2019-10-04 00:31:01 -03—Fri 2019-10-04 10:17:01 -03
Os logs de inicialização anteriores também são preservados nos sistemas baseados no systemd, sendo assim possível inspecionar as mensagens de sessões anteriores do sistema operacional. Se as opções -b 0
ou --boot=0
forem usadas, aparecem as mensagens da inicialização atual. As opções -b -1
ou --boot=-1
exibem as mensagens da inicialização anterior. As opções -b -2
ou --boot=-2
exibem as mensagens da inicialização antes da anterior e assim por diante. O trecho a seguir mostra o kernel chamando o gerenciador de serviços do systemd para o último processo de inicialização:
$ journalctl -b 0 oct 04 00:31:01 ubuntu-host kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) oct 04 00:31:01 ubuntu-host kernel: ip_tables: (C) 2000-2006 Netfilter Core Team oct 04 00:31:01 ubuntu-host systemd[1]: systemd 237 running in system mode. oct 04 00:31:01 ubuntu-host systemd[1]: Detected architecture x86-64. oct 04 00:31:01 ubuntu-host systemd[1]: Set hostname to <torre>. oct 04 00:31:01 ubuntu-host systemd[1]: Reached target User and Group Name Lookups. oct 04 00:31:01 ubuntu-host systemd[1]: Created slice System Slice. oct 04 00:31:01 ubuntu-host systemd[1]: Listening on Journal Audit Socket. oct 04 00:31:01 ubuntu-host systemd[1]: Listening on Journal Socket. oct 04 00:31:01 ubuntu-host systemd[1]: Mounting POSIX Message Queue File System... oct 04 00:31:01 ubuntu-host systemd[1]: Started Read required files in advance. oct 04 00:31:01 ubuntu-host systemd[1]: Starting Load Kernel Modules... oct 04 00:31:01 ubuntu-host kernel: EXT4-fs (sda1): re-mounted. Opts: commit=300,barrier=0,errors=remount-ro oct 04 00:31:01 ubuntu-host kernel: lp: driver loaded but no devices found oct 04 00:31:01 ubuntu-host kernel: ppdev: user-space parallel port driver oct 04 00:31:01 ubuntu-host kernel: parport_pc 00:02: reported by Plug and Play ACPI oct 04 00:31:01 ubuntu-host kernel: parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] oct 04 00:31:01 ubuntu-host kernel: lp0: using parport0 (interrupt-driven). oct 04 00:31:01 ubuntu-host systemd-journald[352]: Journal started oct 04 00:31:01 ubuntu-host systemd-journald[352]: Runtime journal (/run/log/journal/abb765408f3741ae9519ab3b96063a15) is 4.9M, max 39.4M, 34.5M free. oct 04 00:31:01 ubuntu-host systemd-modules-load[335]: Inserted module 'lp' oct 04 00:31:01 ubuntu-host systemd-modules-load[335]: Inserted module 'ppdev' oct 04 00:31:01 ubuntu-host systemd-modules-load[335]: Inserted module 'parport_pc' oct 04 00:31:01 ubuntu-host systemd[1]: Starting Flush Journal to Persistent Storage...
As mensagens sobre a inicialização e outras emitidas pelo sistema operacional são armazenadas em arquivos dentro do diretório /var/log/
. Se ocorrer um erro crítico e o sistema operacional for incapaz de continuar o processo de inicialização depois de carregar o kernel e o initramfs, uma mídia de inicialização alternativa pode ser usada para iniciar o sistema e acessar o arquivo de sistemas correspondente. Depois disso, os arquivos em /var/log/
podem ser consultados em busca das razões causaram a interrupção do processo de inicialização. As opções -D
ou --directory
do comando journalctl
servem para ler mensagens de log em diretórios diferentes de /var/log/journal/
, que é a localização padrão para as mensagens de log do systemd. Como as mensagens de log do sistema não são armazenadas em texto puro, o comando journalctl
é necessário para que fiquem legíveis.
Exercícios Guiados
-
Em uma máquina equipada com firmware BIOS, onde está localizado o binário do bootstrap?
-
O firmware UEFI suporta recursos estendidos fornecidos por programas externos, chamados aplicativos EFI. Esses aplicativos, no entanto, têm seu próprio local especial. Em que lugar do sistema localizam-se os aplicativos?
-
Os gerenciadores de inicialização permitem a passagem de parâmetros personalizados do kernel antes de carregá-lo. Suponha que o sistema não possa inicializar devido a uma localização incorreta do sistema de arquivos raiz. Como o sistema de arquivos raiz correto, localizado em
/dev/sda3
, seria fornecido como parâmetro para o kernel? -
O processo de inicialização de uma máquina Linux termina com a seguinte mensagem:
ALERT! /dev/sda3 does not exist. Dropping to a shell!
Qual a causa provável desse problema?
Exercícios Exploratórios
-
O carregador de inicialização apresenta uma lista de sistemas operacionais a escolher quando houver mais de um sistema operacional instalado na máquina. No entanto, um sistema operacional recém-instalado pode sobrescrever o MBR do disco rígido, apagando o primeiro estágio do gerenciador de inicialização e tornando o outro sistema operacional inacessível. Por que isso não aconteceria em uma máquina equipada com um firmware UEFI?
-
Qual é uma consequência comum de se instalar um kernel personalizado sem fornecer uma imagem initramfs apropriada?
-
O log de inicialização tem centenas de linhas, portanto a saída do comando
dmesg
é frequentemente canalizada para um comando de paginação — como o comandoless
— para facilitar a leitura. Qual opção dodmesg
faz automaticamente a paginação da saída, eliminando a necessidade de usar explicitamente um comando de paginação? -
Um disco rígido contendo todo o sistema de arquivos de uma máquina offline foi removido e conectado a uma máquina operacional como drive secundário. Supondo que seu ponto de montagem seja
/mnt/hd
, como ojournalctl
seria usado para inspecionar o conteúdo dos arquivos de diário localizados em/mnt/hd/var/log/journal/
?
Resumo
Esta lição aborda a sequência de inicialização em um sistema Linux padrão. O conhecimento adequado de como funciona o processo de inicialização de um sistema Linux ajuda a evitar erros que podem tornar o sistema inacessível. A lição tratou dos seguintes tópicos:
-
Diferença entre os métodos de inicialização da BIOS e da UEFI.
-
Estágios típicos da inicialização do sistema.
-
Recuperação de mensagens de inicialização.
Os comandos e procedimentos abordados foram:
-
Parâmetros comuns do kernel.
-
Comandos para ler mensagens de inicialização:
dmesg
ejournalctl
.
Respostas aos Exercícios Guiados
-
Em uma máquina equipada com firmware BIOS, onde está localizado o binário do bootstrap?
No MBR do primeiro dispositivo de armazenamento, como definido no utilitário de configuração da BIOS.
-
O firmware UEFI suporta recursos estendidos fornecidos por programas externos, chamados aplicativos EFI. Esses aplicativos, no entanto, têm seu próprio local especial. Em que lugar do sistema localizam-se os aplicativos?
Os aplicativos EFI são armazenados na EFI System Partition (ESP), localizada em qualquer bloco de armazenamento disponível com um sistema de arquivos compatível (geralmente um sistema de arquivos FAT32).
-
Os gerenciadores de inicialização permitem a passagem de parâmetros personalizados do kernel antes de carregá-lo. Suponha que o sistema não possa inicializar devido a uma localização incorreta do sistema de arquivos raiz. Como o sistema de arquivos raiz correto, localizado em
/dev/sda3
, seria fornecido como parâmetro para o kernel?O parâmetro
root
deve ser usado, como emroot=/dev/sda3
. -
O processo de inicialização de uma máquina Linux termina com a seguinte mensagem:
ALERT! /dev/sda3 does not exist. Dropping to a shell!
Qual a causa provável desse problema?
O kernel não encontrou o dispositivo
/dev/sda3
, informado como o sistema de arquivo raiz.
Respostas aos Exercícios Exploratórios
-
O carregador de inicialização apresenta uma lista de sistemas operacionais a escolher quando houver mais de um sistema operacional instalado na máquina. No entanto, um sistema operacional recém-instalado pode sobrescrever o MBR do disco rígido, apagando o primeiro estágio do gerenciador de inicialização e tornando o outro sistema operacional inacessível. Por que isso não aconteceria em uma máquina equipada com um firmware UEFI?
As máquinas UEFI não usam o MBR do disco rígido para armazenar o primeiro estágio do gerenciador de inicialização.
-
Qual é uma consequência comum de se instalar um kernel personalizado sem fornecer uma imagem initramfs apropriada?
O sistema de arquivos raiz pode ficar inacessível se seu tipo tiver sido compilado como um módulo externo do kernel.
-
O log de inicialização tem centenas de linhas, portanto a saída do comando
dmesg
é frequentemente canalizada para um comando de paginação — como o comandoless
— para facilitar a leitura. Qual opção dodmesg
faz automaticamente a paginação da saída, eliminando a necessidade de usar explicitamente um comando de paginação?Os comandos
dmesg -H
oudmesg --human
habilitam a paginação por padrão. -
Um disco rígido contendo todo o sistema de arquivos de uma máquina offline foi removido e conectado a uma máquina operacional como drive secundário. Supondo que seu ponto de montagem seja
/mnt/hd
, como ojournalctl
seria usado para inspecionar o conteúdo dos arquivos de diário localizados em/mnt/hd/var/log/journal/
?Com os comandos
journalctl -D /mnt/hd/var/log/journal
oujournalctl --directory=/mnt/hd/var/log/journal