Tutorial de Ubuntu 26.04 / Recupere falhas de inicialização, kernel e rede

Inicie a recuperação do Ubuntu no console: identifique até onde o boot progride, preserve logs e alterações recentes, e delimite a falha. Um serviço SSH inacessível não prova que o SO falhou ao iniciar. Investigue os níveis de boot, kernel, rede e aplicação separadamente e reverta uma alteração relevante de cada vez. Os guias sobre investigação de falhas com logs e recuperação baseada em evidências complementam esta investigação.

Identifique o estágio da falha e o escopo seguro

Preserve o estado sempre que possível e assegure o acesso aos backups existentes e às chaves de desbloqueio. Não danifique deliberadamente discos de produção ou redes para um exercício. Registre o tempo, erros exatos, a última operação bem-sucedida e alterações recentes sem incluir credenciais ou chaves privadas.

Colete evidências em modo de leitura quando for possível entrar

cat /etc/os-release
uname -r
systemctl --failed
df -h
lsblk -f
findmnt /
sudo journalctl --list-boots
sudo journalctl -b -p err --no-pager

Se registros de inicialização anteriores existirem, compare-os com sudo journalctl -b -1 -p err --no-pager. A ausência de logs históricos não prova uma inicialização sem erros. Se o disco estiver cheio, identifique a causa e preserve os registros relevantes antes de remover qualquer coisa. Inspecione os registros próximos ao horário e de unidades específicas quando a saída apenas com erros não fornecer contexto.

Pratique uma falha de serviço limitada e restauração em um clone

Execute a partir do console de um clone de laboratório isolado de seu original. Esta nova unidade não é habilitada na inicialização e não exclui dados nem altera a rede. Estabeleça uma linha de base bem-sucedida, introduza um drop-in com o comando false e, em seguida, restaure removendo apenas esse arquivo. Isso exercita o diagnóstico de serviços, não uma falha real de kernel ou inicialização.

(
set -eu
unit=ubuntu-recovery-lab.service
file=/etc/systemd/system/$unit
drop=/etc/systemd/system/$unit.d
if sudo test -e "$file" || sudo test -L "$file" || sudo test -e "$drop" || sudo test -L "$drop"; then
    printf 'Lab unit already exists; choose a new name.\n' >&2
    exit 1
fi
if sudo systemctl cat "$unit" >/dev/null 2>&1; then
    printf 'A loaded unit already uses this name; stop.\n' >&2
    exit 1
fi
sudo sh -c 'set -C; cat > "$1"' sh "$file" <<'EOF'
[Unit]
Description=Bounded Ubuntu recovery exercise
[Service]
Type=oneshot
ExecStart=/usr/bin/true
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
sudo systemctl start "$unit"
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo install -d -m 0755 "$drop"
sudo sh -c 'set -C; cat > "$1/10-failure.conf"' sh "$drop" <<'EOF'
[Service]
ExecStart=
ExecStart=/usr/bin/false
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
if sudo systemctl start "$unit"; then
    printf 'Unexpected success: inspect the loaded unit.\n' >&2
    exit 1
fi
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo journalctl -u "$unit" --since '5 minutes ago' --no-pager
)

Espere Result=success e ExecMainStatus=0 na execução inicial; após a falha intencional, espere Result=exit-code e ExecMainStatus=1. Diferencie o estado oneshot inativo bem-sucedido da falha e compare os horários e comandos nos registros do journal. Restaure abaixo apenas se este for o arquivo recém-criado e não tiver edições intermediárias. A verificação recusa links simbólicos e conteúdo alterado; evite alterações simultâneas durante o teste.

(
set -eu
drop=/etc/systemd/system/ubuntu-recovery-lab.service.d
conf=$drop/10-failure.conf
if sudo test -L "$drop" || sudo test -L "$conf" ||
   ! printf '%s\n' '[Service]' 'ExecStart=' 'ExecStart=/usr/bin/false' | sudo cmp -s - "$conf"; then
    printf 'Lab drop-in changed or is a symlink; inspect manually.\n' >&2
    exit 1
fi
sudo rm -- "$conf"
sudo systemctl daemon-reload
sudo systemctl reset-failed ubuntu-recovery-lab.service
sudo systemctl start ubuntu-recovery-lab.service
sudo systemctl show ubuntu-recovery-lab.service -p Result -p ExecMainStatus
)

Confirme Result=success e ExecMainStatus=0 novamente. Para uma limpeza completa, verifique a propriedade e inatividade, remova apenas esta unidade de laboratório e seu diretório drop-in vazio, e então recarregue o systemd. Registre isso separadamente das decisões reais de kernel anterior/modo de recuperação abaixo.

Use um kernel anterior após falha de inicialização relacionada a atualização

Se a inicialização falhar imediatamente após uma atualização e o GRUB mais um kernel mais antigo estiverem disponíveis, selecione um kernel anterior em Opções avançadas para Ubuntu a partir do console. O acesso ao GRUB varia conforme o firmware, host e tempo; verifique o procedimento do console da máquina ou VM. Discos criptografados ainda exigem desbloqueio.

Se o kernel anterior inicializar, registre uname -r e compare o histórico de atualizações, os logs do kernel e o estado relevante dos drivers/DKMS. Esse resultado sozinho não estabelece o novo kernel como a única causa. Preserve o kernel em execução e uma alternativa funcional, repare o problema identificado e então verifique a inicialização normal.

O guia de Modo de Recuperação da Wiki do Ubuntu descreve as opções de recuperação do GRUB e seus pré-requisitos.

Identifique a infraestrutura inicial do disco RAM

O Ubuntu 26.04 altera a infraestrutura padrão do disco RAM inicial para Dracut, enquanto as configurações existentes do initramfs-tools podem permanecer. Durante a recuperação de inicialização, não execute imediatamente os comandos de regeneração copiados de outro guia LTS: inspecione primeiro as ferramentas instaladas e os artefatos de inicialização.

dpkg-query -W dracut dracut-core initramfs-tools 2>/dev/null
command -v dracut update-initramfs
ls -lh /boot

Uma ferramenta instalada por si só não prova como a imagem de inicialização atual foi construída. Verifique a configuração e o procedimento de recuperação oficial para o kernel, criptografia, LVM ou RAID selecionados, mantendo um kernel funcional, acesso ao console e backups antes da regeneração.

Transição do Dracut no Ubuntu 26.04

Inspecione o modo de recuperação antes de permitir gravações

Um shell root do menu de recuperação possui privilégios poderosos e difere de um login comum. Inspecione a detecção de disco, espaço livre, montagens e o arquivo específico a ser reparado primeiro. Considere o seguinte apenas no shell de recuperação quando o sistema de arquivos root estiver em modo somente leitura e um reparo de configuração realmente exigir gravação.

findmnt /
mount -o remount,rw /

Estes comandos omitem o sudo porque o shell de recuperação é executado como root. Com corrupção ou erros de E/S, pare as tentativas repetidas de gravação e priorize a preservação de dados e um procedimento de resgate apropriado. Não execute fsck em modo de reparo em um sistema de arquivos montado nem inicialize um disco não identificado.

Recupere a conexão após uma alteração na configuração de rede

ip -br address
ip route
resolvectl status
sudo netplan get
systemctl is-active NetworkManager systemd-networkd
sudo ss -lntp

A partir do console, identifique a interface real, o serviço que a gerencia e a configuração efetiva do Netplan. Compare o arquivo que foi alterado mais recentemente com seu backup em vez de adicionar outro arquivo YAML para sobrescrevê-lo. Verifique se o cloud-init ou outra ferramenta gera a configuração.

Ao restaurar o backup correto, preserve também a configuração atual. Após o sucesso do netplan generate, use sudo netplan try --timeout 120 mantendo o acesso ao console. O rollback automático pode falhar; verifique os endereços, rotas, DNS e uma nova conexão SSH resultantes. Se a rede funcionar, investigue as chaves SSH, os listeners, e o UFW separadamente.

Consulte o manual do netplan try para limitações de reversão e requisitos de verificação.

Preserve os dados e verifique a recuperação

Se o SO instalado estiver inutilizável, considere um ambiente live/resgate verificado. Identifique criptografia, LVM e RAID antes de acessar os discos e evite selecionar a fonte como destino de instalação. Não tente comandos genéricos de reinstalação do GRUB ou recriação de partições; utilize um procedimento compatível com o layout real e backups testados.

Após a recuperação, verifique a reinicialização, uma nova conexão SSH, serviços, leituras/gravações de aplicativos, logs e backups. Registre o que foi revertido, o que melhorou, perguntas não resolvidas e evidências a coletar se ocorrer novamente. A recuperação está completa quando a operação normal é sustentável, não apenas quando uma resposta retorna pela primeira vez.