``` Acer Aspire V5-571: resolvendo um problema antigo de shutdown com auxílio da IA ``` ```

Acer Aspire V5-571

Resolvendo um problema antigo de shutdown com auxílio da IA

Aquele momento que você dá shutdown ele volta a ligar

Este é o relato da investigação de um problema antigo em um Acer Aspire V5-571 rodando Linux.

O sintoma era bastante curioso: ao executar o desligamento, o sistema operacional aparentemente fazia tudo corretamente. Os serviços eram encerrados, o processo de shutdown chegava ao fim e aparecia a mensagem: 

Finished System Power Off

Só que, em vez de permanecer desligado, o notebook simplesmente reiniciava.

Ou seja: o Linux dizia "acabou", mas o Acer respondia "beleza, vamos ligar de novo". 😄

A investigação foi realizada com auxílio de ferramentas de inteligência artificial, utilizadas principalmente para organizar hipóteses, interpretar resultados e estruturar a documentação do processo.

Os testes, alterações e validações foram realizados diretamente no equipamento.

O problema

O comando utilizado para testar o desligamento era: 

sudo poweroff

O sistema iniciava normalmente o processo de desligamento.

Nada indicava um travamento evidente do Linux. Pelo contrário: a sequência de shutdown chegava ao seu final.

Mesmo assim, o equipamento não permanecia desligado.

Em vez disso: 

poweroff → reinício

Quando o comportamento é esse, uma das primeiras suspeitas é que exista algum problema relacionado à forma como o kernel está solicitando o desligamento ao firmware da máquina.

Então começou a investigação.

Primeiras hipóteses

A primeira rodada de testes envolveu algumas possibilidades relacionadas a problemas de reboot e ACPI em máquinas antigas.

Foram consideradas, entre outras coisas, opções de kernel relacionadas ao mecanismo de reboot, como: 

reboot=kbd

reboot=acpi

A ideia era verificar se o problema estava relacionado à maneira como o kernel estava conversando com o firmware para realizar a transição de desligamento.

Foram realizados testes com essas possibilidades, mas o comportamento permaneceu.

O notebook continuava reiniciando.

Isso já eliminava algumas hipóteses e indicava que talvez o problema estivesse acontecendo em uma etapa mais específica do processo.

Uma pista: gerenciamento de energia USB

Até aqui, as hipóteses relacionadas ao mecanismo de reboot e ACPI não tinham produzido resultado.

Durante a investigação, uma discussão no fórum do Linux Mint chamou atenção justamente por envolver problemas de desligamento e gerenciamento de energia em máquinas Linux.

Foi uma daquelas situações em que você está procurando uma coisa, encontra uma discussão aparentemente específica demais e pensa: "hmm... isso aqui vale um teste."

A discussão não apresentava uma solução pronta para este Acer Aspire V5-571. Ela serviu como faísca para uma hipótese: talvez o gerenciamento de energia dos dispositivos USB estivesse participando do problema.

A partir daí, passamos a investigar como o Linux estava gerenciando a energia dos dispositivos USB durante a transição para o desligamento.

No Linux, dispositivos USB possuem controles relacionados ao gerenciamento de energia. Um deles pode ser consultado através de: 

cat /sys/bus/usb/devices/*/power/control

Em determinadas situações, esses dispositivos podem estar utilizando o estado: 

auto

Esse mecanismo normalmente é desejável, pois permite que dispositivos entrem em estados de economia de energia quando não estão sendo utilizados.

Mas estávamos investigando justamente uma máquina antiga apresentando um comportamento anormal durante o desligamento.

Então veio um teste simples.

Referência que serviu como ponto de partida: Linux Mint Forums — discussão sobre o problema

O teste

A ideia foi forçar os dispositivos USB para o estado: 

on

O teste poderia ser feito com: 

for ctl in /sys/bus/usb/devices/*/power/control


do
[ -w "$ctl" ] && echo on > "$ctl"
done

Depois disso, o comando de desligamento foi executado novamente: 

sudo poweroff

E dessa vez aconteceu algo diferente.

O notebook desligou.

Não reiniciou.

Não voltou para a tela de login.

Não ressuscitou misteriosamente.

Simplesmente desligou.

Nesse ponto, tínhamos uma pista concreta.

Os testes apontavam para o gerenciamento de energia dos dispositivos USB durante a transição para o desligamento como parte do problema.

Transformando o teste em solução

O problema do teste anterior é que ele precisava ser executado manualmente.

A ideia então passou a ser executar o mesmo procedimento automaticamente, imediatamente antes do desligamento.

O systemd possui um diretório específico para scripts executados durante essa etapa: 

/usr/lib/systemd/system-shutdown/

Foi criado então o arquivo: 

/usr/lib/systemd/system-shutdown/acer-powerfix

Com o seguinte conteúdo: 

#!/bin/sh


#

# Acer Aspire V5-571

#

# Workaround para bug de desligamento.

#

# Antes do desligamento, força todos os dispositivos USB

# para o estado "on", evitando o comportamento de reboot

# observado neste equipamento.

#

for ctl in /sys/bus/usb/devices/*/power/control
do
[ -w "$ctl" ] && echo on > "$ctl"
done

exit 0

Instalação

Para reproduzir a solução no equipamento: 

sudo nano /usr/lib/systemd/system-shutdown/acer-powerfix

Depois de inserir o script e salvar o arquivo: 

sudo chmod +x /usr/lib/systemd/system-shutdown/acer-powerfix

O teste pode então ser realizado com: 

sudo poweroff

E o GRUB?

Durante a investigação também foi considerada a possibilidade de resolver o problema através de parâmetros passados ao kernel pelo GRUB.

A configuração chegou a ser investigada e alterada durante os testes.

Como essas opções não resolveram o problema, a configuração do GRUB foi posteriormente devolvida para uma configuração mais simples: 

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


GRUB_CMDLINE_LINUX=""

Após a alteração: 

sudo update-grub

A solução efetiva acabou sendo o workaround relacionado ao gerenciamento de energia USB.

Resultado

Depois da implementação do script, o comportamento esperado passou a ocorrer: 

sudo poweroff
↓
shutdown do sistema
↓
Finished System Power Off
↓
notebook desligado

Em vez de: 

sudo poweroff
↓
shutdown do sistema
↓
Finished System Power Off
↓
REBOOT

O objetivo aqui não foi "consertar" o firmware do Acer.

O workaround simplesmente atua antes do desligamento para evitar a condição que estava provocando o comportamento observado.

Conclusão

Esse foi um daqueles problemas que parecem simples até o momento em que você começa a investigar.

O sistema operacional estava aparentemente completando o processo de desligamento. As primeiras hipóteses relacionadas ao mecanismo de reboot não resolveram. A investigação então foi caminhando para o gerenciamento de energia e, nesse ponto, um teste relativamente simples produziu uma diferença concreta no comportamento da máquina.

A partir desse teste foi possível transformar o procedimento em um pequeno script executado automaticamente pelo systemd.

Não afirmo que esse seja o único caminho possível para resolver o problema, nem que todo Acer Aspire V5-571 apresente exatamente o mesmo comportamento.

Mas neste equipamento, o resultado foi reproduzível: forçar os dispositivos USB para power/control = on antes do desligamento fez o notebook desligar em vez de reiniciar.

E talvez essa seja a parte mais interessante desse tipo de problema: às vezes a solução não aparece como uma grande descoberta.

Às vezes ela aparece quando você muda uma única coisa e pensa:

"Espera... dessa vez ele desligou."

Foi daí que saiu a solução.

Ferramentas e ambiente

A investigação foi feita utilizando um equipamento que já estava longe de ser novo, mas que continua firme na bancada.

Hardware

Sistema

Ferramentas

Uma observação sobre o uso de IA

A IA não executou os testes nem teve acesso direto ao equipamento.

Ela foi utilizada como uma espécie de parceiro de investigação: ajudando a organizar hipóteses, interpretar saídas do sistema, sugerir caminhos de diagnóstico e, posteriormente, estruturar a documentação.

Os comandos foram executados no equipamento e os resultados foram observados e validados durante a investigação.

A solução apresentada neste artigo é, portanto, resultado da combinação entre investigação prática e assistência por IA.