o sistema não desliga no “desligamento”, apenas pára


13

Instalei o Xubuntu 15.04 em um Lenovo IdeaCentre A740 QHD com uma CPU Haswell (revisão do BIOS 00KT19AUS) e NVIDIA GeForce GTX 850A 2GB. Está funcionando principalmente, exceto quando eu desligo ou reinicializo, na verdade, ele não desliga a energia depois de encerrar tudo:

IMG:

Então eu tenho que clicar no botão liga / desliga para realmente desligá-lo.


Eu mantive a instalação do Windows 8.1, caso haja algum firmware futuro. Antes de instalar o Xubuntu, desliguei o Fastboot no Windows e instalei o Xubuntu. Infelizmente, o UEFI BIOS não me permitiu alterar a ordem de inicialização para que o Ubuntu realmente iniciasse como padrão. Eu tentei bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi, tentei desativar o "quickboot" (o que quer que seja) no BIOS, tentei o programa Boot-Repair a partir de uma Live Session e tentei desativar o SecureBoot, mas ainda assim inicializaria o Windows. Acabei, com a ajuda de EricC ^^ do #ubuntu no freenode, apenas trocando os arquivos .efi para induzir o gerenciador de inicialização a pensar que o Ubuntu era o Windows:

cp /boot/efi/efi/boot/bootx64.efi{,.backup}
cp /boot/efi/efi/microsoft/boot/bootmgfw.efi{,.backup}
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/boot/bootx64.efi
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/microsoft/boot/bootmgfw.efi
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/microsoft/boot/grubx64.efi
sudo vim /usr/lib/os-probes/mounted/efi/20microsoft
# and changed bootmgfw.efi to bootmgfw.efi.backup
update-grub

Não sei se isso tem alguma influência no problema do desligamento.

EDIT: Venha para pensar sobre isso, a reinicialização da instalação do Xubuntu (quando eu fui inicializado através de uma unidade USB) também não funcionou.


O que eu tentei até agora para desligar:

  • acpi = off → nenhuma diferença
  • acpi = força → nenhuma diferença
  • instale drivers proprietários da Nvidia → que fizeram o X não iniciar com a mensagem "bbswitch: Nenhum dispositivo VGA discreto encontrado"
  • várias variações sudo poweroff, sudo shutdown now, sudo shutdown -h nowetc.

Além disso, se eu reiniciar em vez de desligar, eu recebo este show de luzes psicodélico no meu monitor e tenho que clicar muito no botão liga / desliga para desligá-lo:

reiniciar divertido

Se for útil, aqui está uma saída do journalctl --all logo após a inicialização e, talvez ainda melhor: journalctl -b -1 (diário da inicialização ao desligamento) .


Além disso, talvez relacionado, observe agora que pressionar o botão liga / desliga enquanto conectado ao XFCE desliga o computador, mesmo que eu tenha configurações de energia do XFCE para "Perguntar quando o botão liga / desliga for pressionado" e "Não fazer nada" em outros botões.

Meu /etc/systemd/logind.confnão possui linhas não comentadas além do [Login]cabeçalho.

Há um /usr/sbin/acpidprocesso sendo executado como root.


EDIT: Mais revelações: Ctrl + Alt + Delete, na verdade, reinicia bem no GRUB.

EDIT2: Arquivei um relatório de bug, pois isso não parece corrigível com os truques regulares.

EDIT3: Resolvido com acpi = noirq e kernel 4.4 e mais recente.


Tenho problemas semelhantes no Ubuntu 15.04 Desktop / Server, onde o sistema trava durante o desligamento / inicialização. Minha teoria é que ambos podem estar relacionados. Eu reduzi o problema de inicialização verificando dmesge descobri que ele estava tentando montar um sistema de arquivos que não existia e esperei um minuto antes de continuar a inicialização. Também os problemas de desligamento estavam relacionados a uma montagem, porque se eu desligar a área de trabalho com um abrir a conexão NFS ao meu servidor sem forçar a montagem, ele travará. Não tenho certeza se esses problemas estão relacionados ao seu problema, mas pensei em trazê-los à tona.
Michael Lindman

1
O comentário de M. Lindman faz uma boa observação obliquamente. Há um log que mostra em detalhes o que está acontecendo. Leia com journalctl --all. edite sua resposta e mostre-a para as pessoas, se quiser ajuda para entendê-la.
JdeBP

JdeBP: adicionado, mas pelo que posso dizer, o journalctl apenas fornece informações dessa inicialização - existe uma maneira de manter as anteriores?
unhammer


Obrigado JdeBP, me perguntei por que esses logs não foram armazenados :) Eu adicionei um novo link na parte inferior da pergunta, apesar de não encontrar nada suspeito.
unhammer

Respostas:


4

Meu melhor palpite, com base nas informações fornecidas, é um UEFI BIOS de buggy. Ao pesquisar os erros do kernel para Haswell, encontrei uma possível solução alternativa. Tente usar xhci_hcd.quirks=262144como opção de inicialização ou Desativar xhci na UEFI.

As únicas outras opções em que consigo pensar são as seguintes:

A) Aguarde e espere que a equipe de desenvolvimento do kernel ou a Lenovo desenvolvam uma atualização que resolva o problema.

B) Entre em contato com o suporte da Lenovo e solicite uma atualização do BIOS que resolva o problema ou incentive outras pessoas com o mesmo problema a assinar o relatório de erros. Isso pode ou não ser mais eficaz que A.

C) Modifique o BIOS ou o kernel você mesmo até atingir o resultado desejado (não para os fracos de coração). Não estou recomendando este curso de ação, apenas o incluindo para garantir a integridade. Modificar o BIOS pode facilmente deixar você com um sistema não inicializável com uma garantia anulada. Você também deve ler atentamente as razões a favor e contra a compilação de seu próprio kernel no documento vinculado acima mencionado.

Fonte: https://bugzilla.kernel.org/show_bug.cgi?id=66171#c118


Isso é para sistemas de Broadwell ( support.lenovo.com/us/en/products/desktops-and-all-in-ones/... ), o meu é um (revisão 00KT19AUS BIOS) Haswell
unhammer

Editou novas informações em questão para você.
Elder Geek

Eu editei minha resposta
Elder Geek

Nota: Parece que Christopher M. Penalver chegou à mesma conclusão falsa que eu fiz sobre o BIOS. Você pode atualizá-los com o bug relatado.
Elder Geek

1
As configurações de XHCI estão relacionadas à USB - espero que ajude você a encontrá-las na sua BIOS. Caso contrário, entre em contato com o atendimento ao cliente Lenovo no número 1 (855) 253-6686 e pergunte sobre onde encontrá-los ou se eles têm uma atualização do BIOS em andamento. Muito bem sucedida!
Elder Geek

4

Tente adicionar

acpi=noirq

aos parâmetros de inicialização do kernel. Isso permite o desligamento no desligamento / reinicialização (testado com os kernels 4.4 e 4.7rc5).

Parece suspender também, mas infelizmente não é suspenso ao pressionar o botão liga / desliga.

Isso funcionou bem há mais de três meses no A740, então estou resolvendo isso.


Estou feliz que minha opção A) funcionou para você! :-)
Elder Geek

Como em "espera e esperança"? Na verdade, o que eu fiz foi denunciá-lo como bug no pacote linux do Ubuntu, tentando algumas versões mais recentes da linha principal e, quando isso não resolveu nada, eu o relatei antes, primeiro para o componente errado bugzilla.kernel.org/show_bug.cgi?id = 118401 , depois foi enviado para ide / ahci e, após algumas trocas de e-mail e tentando obter uma saída de depuração útil marc.info/?t=146296312800002&r=1&w=2 e tentando diferentes opções sugeridas lá, encontrou a que funcionou. Simplesmente aguardar e atualizar não resolve, as configurações do grub precisam ser editadas.
Unhammer

Independentemente disso, fico feliz que você tenha resolvido. Se era A ou B :-)
Elder Geek

2

Depois de vasculhar os arquivos do sistema, vi alguns avisos sobre o BIOS. Verifiquei o site da Intel e houve uma atualização disponível que parecia resolver um problema de sobreposição de endereços de memória. Obviamente não é o mesmo, mas meus logs indicaram que vários setores da minha BIOS estavam retornando valores inesperados, o que não impediu a inicialização do kernel, mas obviamente não era bom. O problema não era aparente até que o kernel parou de usar upstarte começou a usar systemd.

Baixei o BIOS atualizado e o apliquei e agora meu sistema desliga conforme o esperado.


Que sistema / BIOS era esse? (Lenovo ainda não divulgou um BIOS atualizado para minha arquitetura do processador.)
unhammer

0

O que cat /etc/default/haltdiz? Tente halt -p.

Você também pode editar /etc/init.d/halte remover estas linhas:

if [ "$INIT_HALT" = "HALT" ]
then
  poweroff=""
fi

abaixo

poweroff="-p"

halt -pnão é diferente, ainda não é completamente desligado.
unhammer

ah, e / etc / default / halt diz HALT=poweroff. Mas não deve halt -pou poweroff ou shutdown nowainda funcionam independentemente do que está lá dentro?
Unhammer #

0

Nos registros do seu kernel (captura de tela), tenho um pressentimento de que atualizações autônomas podem ser a causa do seu problema. Houve vários relatórios de erros neste ano atrás, mas eles não foram resolvidos. Uma correção temporária para isso seria desativar as atualizações automáticas por atualizações, mas a manteremos como último recurso. Mas, primeiro, tentaremos uma atualização manual:

sudo apt-get autoremove
sudo apt-get dist-upgrade

Se isso não resolveu o problema e a atualização ocorreu sem erros ou avisos, tentaremos nos aprofundar um pouco mais para ver se conseguimos descobrir o que está causando o problema. Você pode obter uma liderança inspecionando o conteúdo de /var/log/unattended-upgrades. Se você descobrir qual atualização está causando o problema, poderá colocar a atualização na lista negra, modificando /etc/apt/apt.conf.d/50unattended-upgrades.

Se ele ainda não resolver o problema, você pode remover temporariamente o pacote para confirmar se é a causa:

sudo apt-get remove unattended-upgrades 

Eu recomendo que você o reinstale, mesmo que ele tenha resolvido o seu problema. Se for esse o caso, traga de volta o relatório de erros com mais informações para que os desenvolvedores possam resolver seu problema.

Aviso: Se você optar por desativar a atualização automática e não atualizar manualmente o sistema, poderá estar em risco do ponto de vista de segurança e estabilidade.


Esta é uma nova instalação - autoremovee dist-upgradeter "0 para atualizar, 0 para remover" etc, e / var / log / autônoma-upgrades está vazio: $ wc -c < /var/log/unattended-upgrades/unattended-upgrades-shutdown.log0
unhammer

Além disso, não há programas /lib/systemd/system-shutdown, portanto, não há serviços que devem ser chamados quando eu digitar poweroff . E remover unattended-upgradescompletamente não teve efeito.
Unhammer

0

Eu tentei de tudo e depois de dias um fã de baixa classificação deste fórum fez o truque: Ubuntu 14.04 travou no desligamento

Para mim, a solução foi atualizar o kernel. Eu usei 4.5.3 no Ubuntu 15.10 (qualquer coisa maior que isso irá travar o SO após o login) E o 4.7 RC3 funciona no Ubuntu 16.04.

Agora funciona perfeitamente :-)


Isso não funcionou para o meu sistema. Como mostram os relatórios de bugs, eu já tentei muitos kernels 4.7 - isso impossibilitou a inicialização! Após relatar a montante e depuração ajuda de lista do kernel, a solução para os meus problemas (inicialização em tudo, e desligar no desligamento) foi acpi=noirq askubuntu.com/a/794739/25639
unhammer

0

Posso confirmar que definitivamente tem algo a ver com a ACPI. Meu sistema exibe esse comportamento exato, se e somente se eu passar acpi = off no Linux 4.20-rc3 para fins de desenvolvimento do kernel. Se a sua ACPI foi ativada inicialmente, há uma chance razoável de que a implementação da ACPI no BIOS tenha ocorrido um erro. Vejo que você disse que uma atualização do kernel ajudou. Mas uma atualização do BIOS também pode ter funcionado.


Na verdade, isso não responde à pergunta. Sua sugestão relacionada ao BIOS apenas indica uma solução possível, que parece que você ainda não tentou. De fato, o OP indicou que ele havia resolvido seu problema "adicionando acpi = noirq aos parâmetros de inicialização do kernel".
precisa

0

Eu tive o mesmo problema e acredito que está relacionado à inicialização do UEFI. Em um Acer Aspire V 11, originalmente Windows 8, fiz uma nova instalação do OpenSUSE Leap 15.0 com inicialização EFI e inicialização segura definida como "desativada" no BIOS. Agora o desligamento, reinicie e suspenda o trabalho corretamente.

Anteriormente, eu estava usando o Ubuntu 16.04, 18.04 e, mais recentemente, o 18.10 no boot legado, e todos sofreram o mesmo problema. Eu também experimentei o Fedora 24, o OpenSUSE Tumbleweed e o OpenSUSE 42.2, todos com o mesmo problema.

Também tentei o Ubuntu 18.10 com a inicialização EFI e a inicialização segura ativada, mas recebi um erro de dispositivo não inicializável. Não tentei a inicialização do EFI com a inicialização segura desativada.


-1

Seu hardware pode não suportar o desligamento do software. Já tive isso antes, e a maneira de testar é esta:

sudo poweroff

Se isso não desligar o hardware, é um problema de hardware e não de software.


3
Como afirma a pergunta, tentei isso sem sucesso. Mas o GRUB gerencia bem a reinicialização do software (não sei como testar o desligamento), enquanto o Windows 8.1 faz o desligamento do software e reinicia perfeitamente neste hardware. Parece um problema no kernel, por isso arquivei um relatório de bug .
Unhammer

1
voto positivo por preencher um relatório de bug.
Daniel

-1 Porque acho o contrário. Ele termina com systemd-shutdown[1]: Powering off.a máquina desligada perfeitamente com as versões 12.04 e 14.04, mas não uma nova instalação da 16.04.
Nateowami 26/06

-1
  1. Reinicie então F2
  2. Vá para configuração e desative o xHCI
  3. Salvar e sair

Não pense nisso, confie em mim e faça-o :)


Não consigo encontrar nenhuma configuração XHCI no BIOS em nenhum lugar. Posso desligar todo o USB, mas isso não é uma opção para mim.
unhammer

isso não vai virar tudo usb ele só vai se transformar usb3
Talal
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.