Eu tenho uma instalação do Fedora 32 com um HP Probook 450 G0. O BIOS com privilégios de administrador não me permite desabilitar a "inicialização rápida". Por que não? O que fazer? De alguma forma, meu Fedora liga automaticamente novamente após desligar e em 3 segundos. Então imaginei que tinha a ver com minha "inicialização rápida" habilitada, mas infelizmente não há como desativá-la. Minhas outras configurações:
- Wake on LAN > siga a ordem de inicialização
- dispositivo WLAN incorporado habilitado
- controlador LAN incorporado habilitado
- Inicialização do dispositivo USB
- Inicialização personalizada
- "Inicialização rápida" está ativado
- A inicialização segura está DESATIVADA
- Modo de inicialização > UEFI nativo (sem CSM)
- Ordem de inicialização UEFI > Dispositivo USB genérico > Inicialização personalizada > Gerenciador de inicialização do sistema operacional
Como dito, entro na minha BIOS como "administrador". Eu tenho o DriveLock ativado e também defini uma senha (= isso era um requisito para "inicialização rápida" ligar/desligar).
Responder1
Parece exatamente o problema que tive com meu sistema de desktop doméstico anterior.
O HP Probook 450 G0 usa um chipset Mobile Intel HM76 Express, que também é conhecido pelo codinome de desenvolvimento Intel "Panther Point". Meu desktop que apresentava esse problema também tinha um chipset Panther Point.
O problema real é que os controladores USB XHCI dos chipsets Panther Point e Lynxpoint precisam ser desligados de uma maneira específica e controlada, caso contrário, eles ativarão o sistema novamente imediatamente. O que é irritante é que diferentes versões dos chipsets precisarão de diferentes etapas de desligamento, e a correção de uma versão na verdade desencadeia o problema de outra. Alguns BIOS (talvez a maioria?), Mas não todos, lidam com isso automaticamente, portanto, o problema só existe em algum subconjunto de sistemas que usam esses chipsets.
Você encontrará uma longa discussão sobre esse problema em:https://bugzilla.kernel.org/show_bug.cgi?id=66171
Resumindo, existem duas peculiaridades definidas no código do driver Linux XHCI para esse problema: XHCI_SPURIOUS_WAKEUPe XHCI_SPURIOUS_REBOOT. Dependendo da versão exata do chipset, você pode precisar ativar uma ou ambas essas peculiaridades.
Você pode ativar a XHCI_SPURIOUS_REBOOTpeculiaridade por /etc/modprobe.d/*.conflinha options xhci-hcd quirks=8192ou com a opção de inicialização do kernel xhci_hcd.quirks=8192.
Para ativar a XHCI_SPURIOUS_WAKEUPopção, utilize o valor 262144no lugar de 8192; para ativar as duas peculiaridades de uma vez, use o valor 270336(= a soma dos dois valores).
Experimente primeiro a rota de opção de inicialização do kernel: ela funcionará independentemente de o driver XHCI estar incorporado no kernel principal ou carregado como um módulo do kernel. Se você encontrar uma opção que corrija isso para você, adicioná-lo a um /etc/modprobe.d/*.confarquivo pode ser uma maneira "mais limpa" de torná-lo persistente se o driver XHCI for carregado como um módulo.
Como os drivers USB são essenciais para teclados USB, o driver XHCI pode ser carregado no início da fase initramfs do processo de inicialização, portanto, depois de fazer uma alteração no /etc/modprobe.d/*.conf, lembre-se de reconstruir seu arquivo initramfs ( dracuta ferramenta initramfs atual está no Fedora, eu acho?) .
Deixar o driver XHCI descarregado também apresentará o problema, pois sem nenhum driver XHCI presente, o kernel não saberá que o controlador XHCI precisa de atenção especial no desligamento.