le système ne s'éteint pas à la mise hors tension, s'arrête simplement

J'ai installé Xubuntu 15.04 sur un Lenovo IdeaCentre A740 QHD avec un processeur Haswell (révision du BIOS 00KT19AUS) et NVIDIA GeForce GTX 850A 2 Go. Cela fonctionne principalement, sauf lorsque je fais un arrêt ou un redémarrage, cela ne coupe pas réellement l'alimentation après avoir tout quitté:

Je dois donc cliquer sur le bouton d'alimentation pour l'éteindre.

J'ai conservé l'installation de Windows 8.1 au cas où il y aurait un futur firmware. Avant d'installer Xubuntu, j'ai désactivé Fastboot à partir de Windows, puis installé Xubuntu. Malheureusement, le BIOS UEFI ne m'a pas permis de changer l'ordre de démarrage afin qu'Ubuntu démarre réellement par défaut. J'ai essayé bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi, j'ai essayé de désactiver "quickboot" (quoi que ce soit) dans le BIOS, j'ai essayé le programme de réparation de démarrage à partir d'une session en direct et j'ai essayé de désactiver SecureBoot, mais cela ne ferait que démarrer Windows. Je me suis retrouvé, avec l'aide d'EricC ^^ de #ubuntu sur freenode, en changeant simplement les fichiers .efi pour tromper le gestionnaire de démarrage en pensant qu'Ubuntu était 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

Je ne sais pas si tout cela a une incidence sur le problème d'arrêt.

EDIT: À bien y penser, le redémarrage de l'installation de Xubuntu (lorsque j'ai été démarré via une clé USB) n'a pas fonctionné non plus.

Ce que j'ai essayé jusqu'à présent pour l'arrêter:

• acpi = off → pas de différence
• acpi = force → pas de différence
• installez les pilotes Nvidia propriétaires → cela vient de faire en sorte que X ne démarre pas avec le message "bbswitch: aucun périphérique VGA discret trouvé"
• diverses variations sur sudo poweroff, sudo shutdown now, sudo shutdown -h nowetc.

De plus, si je redémarre au lieu de l'arrêt, j'obtiens ce spectacle de lumière psychédélique sur mon moniteur et je dois cliquer longuement sur le bouton d'alimentation pour l'éteindre:

Si c'est utile, voici une sortie journalctl --all juste après le démarrage et peut-être encore mieux: journalctl -b -1 (journal du démarrage à l'arrêt) .

En outre, peut-être lié, je remarque maintenant que le fait d'appuyer sur le bouton d'alimentation lorsque vous êtes connecté à XFCE éteint l'ordinateur, même si j'ai les paramètres d'alimentation XFCE sur "Demander lorsque le bouton d'alimentation est enfoncé" et "Ne rien faire" sur les autres boutons.

Mon /etc/systemd/logind.confn'a pas de lignes non commentées en dehors de l'en- [Login]tête.

Un /usr/sbin/acpidprocessus s'exécute en tant que root.

EDIT: Plus de révélations: Ctrl + Alt + Suppr redémarre en fait bien à partir de GRUB.

EDIT2: J'ai déposé un rapport de bogue car cela ne semble pas réparable avec les astuces habituelles.

EDIT3: résolu avec acpi = noirq et noyau 4.4 et plus récent.

Ma meilleure estimation basée sur les informations fournies est un BIOS UEFI buggé. En fouillant dans les bogues du noyau pour Haswell, j'ai trouvé une solution de contournement possible. Essayez d'utiliser xhci_hcd.quirks=262144comme option de démarrage ou de désactiver xhci dans l'UEFI.

Les seules autres options auxquelles je peux penser sont les suivantes:

A) Attendez et espérez que l'équipe de développement du noyau ou Lenovo propose une mise à jour qui résout le problème.

B) Contactez le support Lenovo et demandez une mise à jour du BIOS qui résout le problème ou encouragez les autres personnes ayant le même problème à s'abonner à votre rapport de bogue. Cela peut ou non être plus efficace que A.

C) Modifiez le BIOS ou le noyau vous-même jusqu'à ce que vous atteigniez le résultat souhaité (pas pour les faibles de cœur). Je ne recommande pas cette ligne de conduite, seulement l'inclure pour être complet. La modification du BIOS peut facilement vous laisser avec un système non démarrable avec une garantie annulée. Vous devriez également lire attentivement les raisons pour et contre la compilation de votre propre noyau dans le document lié susmentionné.

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

Essayez d'ajouter

acpi=noirq

aux paramètres de démarrage du noyau. Cela lui permet de s'éteindre lors de l'arrêt / redémarrage (testé avec les noyaux 4.4 et 4.7rc5).

Il semble suspendre aussi, mais ne reprend malheureusement pas de suspension en appuyant sur le bouton d'alimentation.

Cela a bien fonctionné depuis plus de trois mois maintenant sur l'A740, donc j'appelle cela résolu.

Après avoir parcouru les fichiers système, j'ai vu quelques avertissements sur le BIOS. J'ai vérifié le site Web d'Intel et il y avait une mise à niveau disponible qui semblait résoudre un problème de chevauchement des adresses mémoire. Ce n'est évidemment pas la même chose, mais mes journaux ont indiqué que divers secteurs de mon BIOS retournaient des valeurs inattendues, ce qui n'a pas empêché le noyau de démarrer mais n'était évidemment pas bon. Le problème n'est apparu que lorsque le noyau a cessé d'utiliser upstartet a commencé à utiliser systemd.

J'ai téléchargé le BIOS mis à jour et l'ai appliqué et maintenant mon système s'éteint comme prévu.

Que cat /etc/default/haltdit-il? Essayez halt -p.

Vous pouvez également modifier /etc/init.d/haltet supprimer ces lignes:

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

au dessous de

poweroff="-p"

D'après vos journaux du noyau (capture d'écran), je pense que les mises à niveau sans assistance peuvent être la cause de votre problème. Il y a eu plusieurs rapports de bogues il y a quelques années, mais ils n'ont pas été résolus. Une solution temporaire à ce problème serait de désactiver les mises à jour automatiques par les mises à jour, mais nous le conserverons en dernier recours. Mais tout d'abord, nous allons essayer une mise à niveau manuelle:

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

Si cela n'a pas résolu votre problème et que la mise à niveau s'est déroulée sans erreur ni avertissement, nous allons essayer de creuser un peu plus pour voir si nous pouvons découvrir la cause du problème. Vous pouvez obtenir une piste en inspectant le contenu de /var/log/unattended-upgrades. Si vous pouviez déterminer quelle mise à jour est à l'origine du problème, vous pouvez mettre la mise à jour sur liste noire en la modifiant /etc/apt/apt.conf.d/50unattended-upgrades.

S'il ne résout toujours pas le problème, vous pouvez supprimer temporairement le package, pour confirmer si c'est la cause:

sudo apt-get remove unattended-upgrades 

Je vous recommande de le réinstaller même s'il a résolu votre problème. Si tel est le cas, ramenez le rapport de bogue avec plus d'informations afin que les développeurs puissent résoudre votre problème.

Avertissement: si vous choisissez de désactiver la mise à jour automatique et que vous ne mettez pas à jour manuellement votre système, vous risquez d'être menacé du point de vue de la sécurité et de la stabilité.

J'ai tout essayé et après quelques jours, un fanswer de ce forum mal noté a fait l'affaire: Ubuntu 14.04 bloqué à l'arrêt

Pour moi, la solution était de mettre à jour le noyau. J'ai utilisé 4.5.3 sur Ubuntu 15.10 (tout ce qui est supérieur à cela plantera le système d'exploitation après la connexion) et 4.7 RC3 fonctionne sur Ubuntu 16.04.

Fonctionne maintenant parfaitement :-)

Je peux confirmer que cela a certainement quelque chose à voir avec l'ACPI. Mon système présente ce comportement exact si et seulement si je passe acpi = off sous Linux 4.20-rc3 à des fins de développement du noyau. Si votre ACPI a été activé au début, il y a de fortes chances que l'implémentation d'ACPI dans le BIOS soit boguée. Je vois que vous avez dit qu'une mise à niveau du noyau avait aidé. Mais une mise à niveau du BIOS a peut-être aussi fait l'affaire.

J'ai eu le même problème et je crois qu'il est lié au démarrage UEFI. Sur un Acer Aspire V 11, à l'origine Windows 8, j'ai effectué une nouvelle installation d'OpenSUSE Leap 15.0 avec démarrage EFI et démarrage sécurisé défini sur "désactivé" dans le BIOS. Maintenant, l'arrêt, le redémarrage et la suspension fonctionnent correctement.

Auparavant, j'utilisais Ubuntu 16.04, 18.04 et plus récemment 18.10 sous le démarrage hérité et ils ont tous souffert du même problème. J'ai également essayé Fedora 24, OpenSUSE Tumbleweed et OpenSUSE 42.2, tous avec le même problème.

J'ai également essayé Ubuntu 18.10 avec le démarrage EFI et le démarrage sécurisé activés, mais j'ai eu une erreur de périphérique non amorçable. Je n'ai pas essayé le démarrage EFI avec le démarrage sécurisé désactivé.

Votre matériel peut ne pas prendre en charge l'arrêt du logiciel. Je l'ai déjà fait, et la façon de tester est la suivante:

sudo poweroff

Si cela n'arrête pas le matériel, c'est un problème matériel et non logiciel.

1. Redémarrez puis F2
2. Accédez à la configuration et désactivez xHCI
3. Sauvegarder et quitter

N'y pensez pas, faites-moi confiance et faites-le :)