Atualizar o sistema faz parte do dia a dia de quem vive no terminal. Mas quem roda distribuições rolling release focadas em desempenho, como o CachyOS, sabe que cedo ou tarde vai topar com uma regressão chata. Hoje foi exatamente um desses dias.
Mandei um upgrade de rotina e veio a linha 7.2 do kernel (pacote linux-cachyos 7.2.2-1). Reiniciei e o meu ASUS (Intel Core HX com gráficos híbridos NVIDIA/Intel) simplesmente travou. O boot congelou antes mesmo de carregar o initrd por completo ou entregar o userspace. Tela preta, sem prompt, sem resposta.
Aqui conto como achei a causa nos logs, o tropeço bobo que cometi ao tentar forçar a ordem de boot no Limine na mão, e como congelei a versão certa no pacman enquanto abria a issue para os mantenedores.
1. Diagnóstico inicial: caçando rastros no journalctl#
Como a máquina não passava do bootloader no kernel 7.2, reiniciei, abri o menu do Limine e escolhi a imagem estável que ainda estava no disco: a 7.1.8-1.
Com o desktop de volta, a prioridade foi olhar o que quebrou no boot anterior. O journalctl com -b -1 filtra direto os logs da inicialização que falhou:
journalctl -b -1 | grep -iE "panic|error|fail|fault|kernel"O log entregou o culpado na hora: erros de ACPI na tabela DSDT da BIOS e falhas no módulo asus-wmi:
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.I2C1.TPL1], AE_NOT_FOUND
ACPI Error: AE_NOT_FOUND, During name lookup/catalog
asus_wmi: ASUS WMI generic driver loaded
asus_wmi: fan_curve_get_factory_default failed: -19
asus_wmi: using asus-wmi for asus::kbd_backlight
(udev-worker): Process '/bin/chmod 0666 /sys/class/leds/asus::kbd_backlight/brightness' failed with exit code 1.O que estava acontecendo por baixo dos panos?#
A linha 7.2 mexeu na forma como o kernel interpreta chamadas ACPI e lida com o driver de plataforma asus-wmi. No meu hardware, as rotinas de curva de ventoinhas (fan_curve_get_factory_default) e as regras udev de brilho do teclado entraram em conflito com o barramento I2C, travando o kernel antes da montagem da partição raiz.
O kernel 7.1.8-1 anterior ignorava essas inconsistências da tabela ACPI e subia liso.
2. A armadilha do Limine e o erro do blake2b#
Com a versão 7.1.8-1 funcionando, resolvi colocá-la como primeira opção no gerenciador de boot. O CachyOS usa o Limine, que é super rápido e tem uma sintaxe de configuração limpa.
Abri o arquivo:
sudo nano /boot/limine.confAchei o bloco //linux-cachyos que apontava para o kernel estável e fiz o que qualquer um com pressa faria: recortei o bloco e colei lá no topo, logo abaixo de /+CachyOS.
Salvei e mandei reiniciar. A resposta da BIOS foi imediata:
PANIC: Blake2b hash must be 128 characters longPor que o bootloader reclamou?#
O Limine usa hashes criptográficos para validar a integridade dos arquivos de configuração e dos binários. Quando recortei e colei o bloco no editor de texto, quebrei a linha da chave Blake2b, que acabou truncada com menos de 128 caracteres hexadecimais.
Como o tamanho não batia, o mecanismo de segurança do Limine abortou a inicialização antes de qualquer estrago.
A solução limpa e automatizada#
Em vez de tentar arrumar hash na mão, voltei pelo kernel de emergência e deixei a ferramenta nativa ou o utilitário do CachyOS reconstruir a configuração:
# Recalcula as somas criptográficas e regrava o limine.conf (ou use o assistente do CachyOS)
sudo limine-enroll-config 2>/dev/null || sudo cachyos-kernel-manager(Se o seu ambiente utilizar ganchos automatizados ou o utilitário gráfico da distro, o próprio cachyos-kernel-manager regenera todas as entradas do bootloader e inicializadores sem risco de corrupção).
O arquivo foi reescrito sem erros, os hashes de 128 caracteres fecharam e o kernel 7.1.8-1 assumiu o topo da fila.
3. Blindando o pacman: atualizando sem puxar o kernel quebrado#
Com o boot nos trilhos, eu ainda tinha mais de 430 pacotes para atualizar (navegadores, LLVM, Node.js, bibliotecas). Eu precisava rodar o update sem que o pacman trouxesse o kernel 7.2.2-1 de volta.
Para o update imediato, passei o --ignore:
sudo pacman -Syu --ignore linux-cachyos,linux-cachyos-headers,linux-cachyos-bore,linux-cachyos-nvidia-openTudo atualizou normalmente. Para não ter que lembrar dessa lista toda vez que rodar pacman -Syu, fixei a regra no /etc/pacman.conf:
# /etc/pacman.conf
# Trava o kernel ate os patches de ACPI/ASUS sairem na 7.2
IgnorePkg = linux-cachyos linux-cachyos-headers linux-cachyos-bore linux-cachyos-nvidia-openO pacman continua avisando que tem versão nova, mas não encosta nesses pacotes até eu liberar.
4. Reportando o problema para a comunidade#
Arrumar o sistema local resolve o meu problema, mas abrir o chamado técnico ajuda todo mundo que tem o mesmo hardware.
Peguei os detalhes da compilação:
pacman -Qi linux-cachyos | grep -E "Name|Version|Build Date|Packager"Juntei o trecho do journalctl com os erros de asus_wmi e ACPI e abri o Issue #1010 no GitHub do linux-cachyos detalhando:
- O hardware exato (ASUS com Intel HX e GPU híbrida NVIDIA).
- O momento exato em que o boot travou e os erros de DSDT/ACPI.
- A confirmação de que na 7.1.8-1 tudo funciona perfeitamente com os mesmos módulos.
O que fica dessa saga#
- Evite editar hashes de boot no olho: O Limine checa integridade com rigor (hashes Blake2b de 128 caracteres). Use sempre os utilitários de sincronização como
limine-enroll-config. journalctl -b -1economiza tempo: Olhar os logs do boot que acabou de falhar evita ficar chutando o que aconteceu.- Tenha sempre um kernel de fallback: Manter o kernel estável anterior ou o LTS no disco salva você de precisar caçar um pendrive de boot.
- Use o
IgnorePkgcom foco: Congele só o que quebrou para não atrasar a atualização do restante do sistema.
Enquanto a correção oficial não sai nos repositórios, a máquina segue 100% estável no 7.1.8-1.
Este artigo foi útil?
Deixe uma reação rápida para apoiar o conteúdo:
Veja também
Este post está licenciado sob CC BY-NC.
Comentários
Participe da discussão abaixo.
0 comentários