Sistemas Operacionais Linux e Python
Shell, dispositivos, sysfs, udev, logs do kernel e documentação técnica
As questões a seguir não foram elaboradas para treinar apenas a execução mecânica de comandos. O conjunto foi construído para desenvolver uma forma de pensar e operar sistemas Linux com método: observar, testar, filtrar, interpretar, registrar e justificar. Ao longo dos exercícios, o leitor será levado a trabalhar com expansões de shell, pipelines, redirecionamento, inspeção de dispositivos em /dev, leitura de atributos em sysfs, consulta de metadados com udev, análise de mensagens do kernel, identificação de drivers, uso de lsblk, mount e df, além da consolidação técnica dos achados em arquivos de evidência e em uma análise final organizada por seções.
Em termos práticos, isso significa que o desafio não será apenas descobrir qual comando usar, mas compreender por que aquele comando produz certo efeito, como combinar comandos simples para obter uma observação mais precisa e como distinguir saída útil de ruído. Há exercícios que exigem perceber o comportamento do shell diante de expansões e aspas; outros exigem encadear comandos com pipelines e redirecionamento; outros, ainda, pedem que o leitor enxergue o sistema operacional como uma estrutura observável, em que dispositivos, drivers, logs e filesystems se conectam em camadas coerentes.
Quem conseguir resolver todas essas questões com entendimento real terá desenvolvido um conjunto de competências muito valioso. Terá domínio operacional básico e intermediário de terminal Linux, incluindo semântica de shell, uso criterioso de aspas, expansão de padrões, paginação, filtragem e redirecionamento de saída. Também terá aprendido a usar o terminal como ferramenta de investigação, e não apenas como lugar onde se digitam receitas prontas. Em vez de tentar comandos até algo aparecer, passará a formular pequenas hipóteses, coletar evidências e confirmar conclusões com sinais observáveis do próprio sistema.
Além disso, o leitor passará a compreender melhor o modelo de dispositivos do Linux. Isso inclui reconhecer que dispositivos são expostos como arquivos especiais, que o kernel disponibiliza informações estruturadas por interfaces textuais como /sys e /proc, que o udev acrescenta metadados relevantes e que ferramentas como journalctl -k, lsblk, mount e df mostram faces diferentes, mas complementares, do mesmo sistema. Em outras palavras: ao final, o leitor não verá mais disco, partição, driver, ponto de montagem e log do kernel como peças soltas, mas como partes de um mesmo mecanismo.
Outro ganho importante é a capacidade de documentar tecnicamente o próprio trabalho. O enunciado exige registro de comandos, saídas, arquivos de evidência, consolidação por seções e até defesa oral em vídeo com demonstração prática. Isso empurra o leitor para além da execução individual: ele precisa ser capaz de mostrar o que fez, explicar a finalidade de cada passo e apresentar evidências legíveis e auditáveis. Essa é uma skill de alto valor em ambientes profissionais, porque separa quem apenas faz funcionar de quem consegue investigar, comunicar e sustentar tecnicamente o que fez.
Há também uma qualidade intelectual menos visível, mas talvez mais importante: a formação de critério. Resolver este conjunto de exercícios implica aprender a escolher caminhos seguros de observação, identificar informações relevantes em saídas grandes, comparar fontes diferentes sobre o mesmo dispositivo e organizar o raciocínio de modo reproduzível. Esse tipo de postura é o embrião da maturidade técnica. Não é só saber Linux; é saber olhar para um sistema e perguntar, com método: o que exatamente está acontecendo aqui, que evidências sustentam essa leitura e como eu provo isso?
Por isso, as respostas que vêm a seguir devem ser lidas de duas maneiras ao mesmo tempo. Na superfície, elas mostram como resolver cada item. Em profundidade, elas mostram como um operador técnico raciocina diante de um sistema real: observando com cuidado, reduzindo ambiguidade, correlacionando sinais e registrando o caminho percorrido. Se o leitor conseguir acompanhar e reproduzir tudo isso com compreensão, terá desenvolvido não apenas habilidades de linha de comando, mas também autonomia investigativa, disciplina de documentação e capacidade de interpretação técnica - três qualidades que fazem enorme diferença quando a máquina deixa de ser exercício e vira ambiente real.
Antes de entrar exercício por exercício, duas regras evitam muita confusão. A primeira: em Linux, a resposta correta quase nunca é uma saída textual idêntica. O que vale é mostrar que você usou o comando certo, entendeu o que ele faz e produziu a evidência pedida. O nome do disco pode ser sda, vda, nvme0n1, pode haver loop0, zram0 e outras variações. O zoológico muda conforme a máquina.
A segunda: em vários itens, o enunciado pede registrar comandos e resultados em arquivos .txt, então a resposta esperada não é só rodar no terminal. É rodar, capturar e explicar minimamente. O TP inteiro gira em torno de shell, pipelines, dispositivos, sysfs, udev, logs do kernel, lsblk, mount e documentação técnica.
Você precisa mostrar duas coisas: que sabe usar expansão de padrões para listar arquivos .log e que sabe usar expansão de chaves para criar vários arquivos de uma vez. O ponto central não é o ls nem o touch; é o shell expandindo a linha antes de executar o comando.
Em *.log, o shell substitui o padrão pelos nomes reais que terminam com .log. Já em teste_{1..3}.txt, ele gera teste_1.txt, teste_2.txt e teste_3.txt antes de chamar o touch.
Uma boa resposta não apenas executa os comandos, mas registra em expansoes.txt o que foi feito e o que apareceu como resultado. Isso prova que você entendeu a semântica da expansão, e não apenas digitou uma receita.
touch app.log erro.log acesso.log
ls *.log
touch teste_{1..3}.txt
ls teste_*.txt
{
echo '$ ls *.log'
ls *.log
echo
echo '$ touch teste_{1..3}.txt'
touch teste_{1..3}.txt
echo '$ ls teste_*.txt'
ls teste_*.txt
} > expansoes.txtAqui a ideia é mostrar que pipeline não serve só para ligar comandos em sequência. Ele serve para construir um fluxo de processamento. Você precisa listar /etc, salvar a saída em pipeline.txt e, ao mesmo tempo, paginar essa mesma saída.
A solução mais limpa usa tee, porque ele grava em arquivo e repassa a saída adiante. Esse exercício é didático porque obriga você a pensar em fluxo: gerar, armazenar e inspecionar.
Uma armadilha comum é tentar redirecionar a saída depois do less. Isso bagunça a lógica, porque less é interativo; ele não é a ferramenta certa para produzir o arquivo de evidência.
ls /etc | tee pipeline.txt | less
less pipeline.txttee. Ele é o T do encanamento, não tem glamour, mas resolve./dev e registrar o resultado.O objetivo real deste item é mostrar que você sabe distinguir tipos de entrada em /dev. Ao usar ls -l, a primeira coluna indica o tipo. Quando a linha começa com b, trata-se de um dispositivo de bloco.
Então o raciocínio é simples e técnico: listar /dev em formato longo, filtrar as linhas cujo primeiro caractere é b, salvar em dispositivos_bloco.txt e conferir o conteúdo com less.
Em sistemas diferentes, o conjunto de dispositivos pode variar bastante. O importante não é aparecer exatamente sda ou nvme0n1, mas provar que você isolou corretamente o tipo pedido.
ls -l /dev | grep '^b' > dispositivos_bloco.txt
less dispositivos_bloco.txt/dev/null como destino que descarta dados.Este exercício quer provar que você entende /dev/null como um dispositivo especial que recebe dados e os descarta. É o ralo do sistema. O echo gera a saída, mas o redirecionamento muda o destino dessa saída.
Ao enviar o texto para /dev/null, nada aparece na tela. Sem o redirecionamento, a mensagem aparece normalmente. O valor didático aqui é perceber que a diferença não está no echo, mas no lugar para onde a saída foi enviada.
O arquivo redirecionamento.txt deve registrar não apenas os comandos, mas a interpretação da diferença observada.
echo "teste de saida" > /dev/null
echo "teste de saida"
{
echo 'Comando 1: echo "teste de saida" > /dev/null'
echo 'Diferenca: a saida nao aparece porque foi descartada por /dev/null'
echo
echo 'Comando 2: echo "teste de saida"'
echo 'Diferenca: a saida aparece normalmente no terminal'
} > redirecionamento.txtAspas mudam a semântica da linha de comando. Aspas simples preservam o texto literalmente. Aspas duplas permitem expansão de variáveis. O melhor jeito de demonstrar isso é usar uma variável e observar a diferença na saída.
Quando você executa echo '$nome', o shell trata o conteúdo como texto literal. Já em echo "$nome", ele substitui o valor da variável antes de chamar o echo.
A resposta correta não precisa de floreios. Basta uma variável, dois echo e um registro claro em aspas.txt.
nome="Fabio"
echo '$nome'
echo "$nome"
{
echo 'nome="Fabio"'
nome="Fabio"
echo '$ echo '\''$nome'\'''
echo '$nome'
echo '$ echo "$nome"'
echo "$nome"
} > aspas.txt/sys/block, escolher um dispositivo e ler atributos estruturados expostos pelo kernel.O que a resposta esperada precisa mostrar: você deve listar dispositivos em /sys/block, escolher um deles e ler pelo menos dois atributos desse dispositivo, registrando tudo em sysfs.txt.
Como chegar nisso: /sys/block expõe os block devices conhecidos pelo kernel. Ao listar esse diretório, você vê os nomes dos dispositivos e depois consulta atributos como size, removable, queue/logical_block_size e queue/physical_block_size.
O mais importante aqui não é decorar nomes de arquivos do sysfs, e sim entender que o kernel expõe informações estruturadas em pseudoarquivos. Uma boa prática didática é evitar loop* e escolher um dispositivo de armazenamento real quando houver um.
DEV="sda" # ajuste para nvme0n1 se necessario
{
echo '$ ls /sys/block'
ls /sys/block
echo
echo "$ cat /sys/block/$DEV/size"
cat "/sys/block/$DEV/size"
echo "$ cat /sys/block/$DEV/queue/logical_block_size"
cat "/sys/block/$DEV/queue/logical_block_size"
} > sysfs.txt
less sysfs.txtsysfs como um painel técnico do kernel. Não é um diretório comum; é uma janela estruturada para o estado interno do sistema./dev usando udevadm info.Aqui a ideia é mostrar que você sabe buscar metadados além do nome cru do dispositivo. O udev mantém propriedades úteis sobre os dispositivos reconhecidos pelo sistema, como tipo, modelo e fabricante.
O procedimento é escolher um dispositivo existente, consultar suas propriedades com udevadm info, salvar tudo em udev_info.txt e depois destacar linhas relevantes com grep.
Na interpretação: DEVTYPE e ID_TYPE ajudam a identificar o tipo do dispositivo; ID_VENDOR e ID_MODEL apontam fabricante e modelo.
Dependendo da máquina, algumas propriedades podem aparecer de forma mais rica ou mais pobre. Isso não invalida a resposta. O importante é provar que você sabe localizar, filtrar e interpretar o que o udev expõe.
udevadm info --query=property --name=/dev/sda > udev_info.txt
grep -E 'DEVTYPE|ID_TYPE|ID_VENDOR|ID_MODEL' udev_info.txt
# Se o sistema usar NVMe:
# udevadm info --query=property --name=/dev/nvme0n1 > udev_info.txtO journalctl -k mostra mensagens do kernel. O desafio aqui não é despejar tudo em um arquivo, e sim isolar o que interessa para uma investigação de armazenamento.
Para isso, vale filtrar por termos recorrentes nesse domínio, como sdX, nvme, ata, scsi e block. Não existe uma única expressão regular mágica. Existe critério: você quer reduzir o log a sinais ligados ao subsistema de armazenamento.
O arquivo kernel_devices.txt deve conter esse recorte, e o less serve para você conferir se o filtro capturou informação útil em vez de ruído.
journalctl -k | grep -Ei 'sd[a-z]|nvme|ata|scsi|block' > kernel_devices.txt
less kernel_devices.txt/proc/devices e identificar pelo menos um item de caractere e um de bloco.O /proc/devices apresenta uma lista textual com duas grandes seções: dispositivos de caractere e dispositivos de bloco. O exercício pede que você salve esse conteúdo em drivers.txt e identifique ao menos um item em cada categoria.
Tecnicamente, o arquivo mostra nomes registrados associados a números major, não uma listagem de módulos em formato de prateleira. Mas, para o objetivo didático do item, basta reconhecer a separação entre as duas categorias e apontar exemplos válidos.
Exemplo de resposta objetiva: na seção Character devices, um item comum é tty; na seção Block devices, é comum aparecer loop, sd ou nvme (depende da máquina).
Diferença funcional em uma frase: dispositivo de caractere trabalha como fluxo sequencial; dispositivo de bloco trabalha com blocos endereçáveis, tipicamente em armazenamento.
cat /proc/devices > drivers.txt
# Identificar um exemplo de cada secao na saida real:
awk '/^Character devices:/{f=1;next}/^Block devices:/{f=0} f && NF {print "Exemplo caractere:", $2; exit}' drivers.txt
awk '/^Block devices:/{f=1;next} f && NF {print "Exemplo bloco:", $2; exit}' drivers.txt
less drivers.txtlsblk e registrá-la em arquivo.O lsblk foi feito exatamente para isso: mostrar a relação entre discos, partições, tipos e pontos de montagem. A resposta correta precisa deixar essa hierarquia clara, não apenas listar nomes soltos.
Com a opção --tree, a estrutura fica mais legível. E, com uma seleção adequada de colunas, você consegue mostrar nome, major/minor, tamanho, tipo e pontos de montagem de forma organizada.
Este exercício é importante porque ajuda a ligar abstração e realidade: você não vê mais apenas entradas em /dev, mas a árvore lógica do armazenamento.
lsblk --tree -o NAME,MAJ:MIN,SIZE,TYPE,MOUNTPOINTS > armazenamento.txt
less armazenamento.txtlsblk costuma ser mais inteligível que sair catando pistas picadas em dez comandos diferentes.mount e df.Este item quer que você enxergue duas perspectivas complementares. O mount mostra o que está montado, qual é o tipo de filesystem e em que ponto de montagem ele aparece. Já o df -h ajuda a avaliar ocupação e capacidade.
Uma resposta bem organizada salva ambos no mesmo arquivo, separando as seções. Assim, você não apenas executa os comandos, mas também produz um registro técnico coerente.
O entendimento esperado é simples e útil: um comando mostra a ligação lógica entre dispositivo e montagem; o outro mostra o uso prático do espaço.
mount > filesystems.txt
echo >> filesystems.txt
echo '--- df -h ---' >> filesystems.txt
df -h >> filesystems.txt
less filesystems.txt/dev, logs do kernel, lsblk e documentação técnica em uma análise final estruturada.Este é o exercício mais importante do conjunto, porque ele amarra tudo. Aqui você deixa de resolver peças isoladas e passa a montar o mecanismo inteiro: escolher um dispositivo real, investigá-lo por mais de uma interface e consolidar o resultado em um relatório técnico.
A resposta forte precisa mostrar cinco movimentos. Primeiro, escolher um dispositivo real. Segundo, isolá-lo em /dev. Terceiro, localizar evidências sobre ele no log do kernel. Quarto, observar sua hierarquia com lsblk. Quinto, consultar ao menos um comando auxiliar para provar investigação consciente em vez de chute.
O arquivo final analise_final.txt deve trazer seções claras, com o nome do dispositivo escolhido, os comandos usados, a finalidade de cada etapa e os resultados principais. É isso que separa a execução casual de uma análise técnica auditável.
# Exemplo para um dispositivo sda:
ls -l /dev | grep -E ' sda([0-9]+)?$' > etapa_dev.txt
journalctl -k | grep -Ei 'sda|ata|scsi|block' > etapa_kernel.txt
lsblk /dev/sda -o NAME,MAJ:MIN,SIZE,TYPE,FSTYPE,MOUNTPOINTS > etapa_lsblk.txt
lsblk --help > ajuda_lsblk.txt
{
echo '=== 1. Dispositivo escolhido ==='
echo 'sda'
echo
echo '=== 2. Representacao em /dev ==='
echo 'Comando: ls -l /dev | grep -E '\'' sda([0-9]+)?$'\'''
echo 'Finalidade: localizar o dispositivo e suas particoes no diretorio /dev'
cat etapa_dev.txt
echo
echo '=== 3. Reconhecimento pelo kernel ==='
echo 'Comando: journalctl -k | grep -Ei '\''sda|ata|scsi|block'\'''
echo 'Finalidade: localizar mensagens do kernel relacionadas ao dispositivo'
cat etapa_kernel.txt
echo
echo '=== 4. Hierarquia de block devices ==='
echo 'Comando: lsblk /dev/sda -o NAME,MAJ:MIN,SIZE,TYPE,FSTYPE,MOUNTPOINTS'
echo 'Finalidade: visualizar a organizacao do disco e suas particoes'
cat etapa_lsblk.txt
echo
echo '=== 5. Comando auxiliar consultado ==='
echo 'Comando: lsblk --help'
echo 'Finalidade: consultar opcoes do comando lsblk'
head -n 20 ajuda_lsblk.txt
} > analise_final.txt
# Se o sistema usar NVMe, adapte sda para nvme0n1