le système ne s'éteint pas sur "poweroff", s'arrête juste
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 2GB. Cela fonctionne principalement, sauf que lorsque je fais un arrêt ou un redémarrage, cela ne coupe pas le courant après avoir tout arrêté:
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 sous Windows, puis installé Xubuntu. Malheureusement, le BIOS UEFI ne m'a pas laissé changer l'ordre de démarrage pour qu'Ubuntu ait réellement démarré par défaut. J'ai essayé bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi, essayé d'éteindre "quickboot" (quel que soit cela) dans le BIOS, essayé le programme Boot-Repair à partir d'une session en direct et essayé d'éteindre SecureBoot, mais cela ne ferait que démarrer Windows. Avec l’aide d’EricC ^^ de #ubuntu sur freenode, j’ai simplement basculé entre les fichiers .efi pour faire croire au gestionnaire de démarrage que 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 cela a un impact sur les problèmes d'arrêt.
EDIT: À bien y penser, le redémarrage à partir 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 de le faire taire:
- acpi = off → pas de différence
- acpi = force → pas de différence
- installez les pilotes propriétaires Nvidia → qui viennent de faire en sorte que X ne commence pas par le message "bbswitch: aucun périphérique VGA discret trouvé"
- variations diverses sur
Sudo poweroff,Sudo shutdown now,Sudo shutdown -h nowetc.
De plus, si je redémarre au lieu d’arrêter, j’obtiens ce jeu de lumières psychédélique sur mon moniteur et je dois cliquer longuement sur le bouton d’alimentation pour l’éteindre:
Si cela est utile, voici un journalctl - toute la sortie juste après le démarrage et peut-être même mieux: journalctl -b -1 (journal du démarrage à l’arrêt) .
Aussi, peut-être lié, je remarque maintenant que le fait d'appuyer sur le bouton d'alimentation alors que je suis connecté à XFCE éteint l'ordinateur, même si les paramètres d'alimentation de XFCE sont définis sur "Demander lorsque le bouton d'alimentation est enfoncé" et sur "Ne rien faire" sur les autres boutons.
Mon /etc/systemd/logind.conf n'a pas de lignes non commentées à part l'en-tête [Login].
Un processus /usr/sbin/acpid est exécuté en tant que root.
EDIT: Plus de révélations: Ctrl + Alt + Suppr réellement redémarrer bien 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 le noyau 4.4 et plus récent.
Essayez d'ajouter
acpi=noirq
aux paramètres de démarrage du noyau. Cela lui permet d’être mis hors tension à l’arrêt/au redémarrage (testé avec les noyaux 4.4 et 4.7rc5).
Il semble suspendre aussi, mais malheureusement pas reprend de suspendre en appuyant sur le bouton d'alimentation.
Cela a bien fonctionné pendant plus de trois mois maintenant sur l'A740, alors j'appelle cela résolu.
Ma meilleure hypothèse 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=262144 comme option de démarrage ou de désactiver xhci dans le fichier 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ésolve le problème.
B) Contactez Support Lenovo et demandez une mise à jour du BIOS qui résout le problème ou encouragez les autres utilisateurs du même problème à s'abonner à votre rapport de bogue. Cela peut être ou ne pas être plus efficace que A.
C) Modifiez le BIOS ou le noya jusqu'à ce que vous obteniez le résultat souhaité (pas pour les faibles de cœur). Je ne recommande pas cette ligne de conduite, je l'inclue seulement par souci de complétude. La modification du BIOS peut facilement vous laisser avec un système non amorçable avec une garantie annulée. Vous devez é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
Après avoir découvert les fichiers système, j’ai vu quelques avertissements concernant le BIOS. J'ai consulté le site Web d'Intel et il y avait une mise à jour disponible qui semblait résoudre un problème de chevauchement d'adresses mémoire. Ce n’est évidemment pas la même chose, mais mes journaux indiquaient que divers secteurs de mon BIOS renvoyaient des valeurs inattendues, ce qui n’empêchait pas le noyau de démarrer mais n’était évidemment pas bon. Le problème n'était pas apparent jusqu'à ce que le noyau ait arrêté d'utiliser upstartet commencé à utiliser systemdname__.
J'ai téléchargé le BIOS mis à jour et je l'ai appliqué. Désormais, mon système s'éteint comme prévu.
Que dit cat /etc/default/halt? Essayez halt -p.
Vous pouvez également éditer /etc/init.d/halt et supprimer ces lignes:
if [ "$INIT_HALT" = "HALT" ]
then
poweroff=""
fi
au dessous de
poweroff="-p"
À partir de vos journaux de noyau (capture d'écran), je suis persuadé que des mises à niveau sans surveillance pourraient être la cause de votre problème. Il y a eu plusieurs rapports de bugs il y a quelques années, mais ils n'ont pas été résolus. Une solution temporaire à ce problème consisterait à désactiver les mises à jour automatiques, mais nous le conserverons en dernier recours. Mais tout d’abord, nous allons essayer une mise à jour manuelle:
Sudo apt-get autoremove
Sudo apt-get dist-upgrade
Si cela ne résout pas votre problème et que la mise à niveau se déroule sans erreur ni avertissement, nous allons essayer de creuser un peu plus en profondeur pour voir si nous pouvons trouver 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 ajouter la mise à jour à une liste noire en 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 s'il en est la cause:
Sudo apt-get remove unattended-upgrades
Je vous recommande de le réinstaller même s'il résout 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 de ne pas mettre à jour manuellement votre système, vous pouvez être exposé au risque du point de vue de la sécurité et de la stabilité.
Je peux confirmer que cela a certainement quelque chose à voir avec 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 est fort probable que la mise en œuvre d'ACPI dans le BIOS ait mal fonctionné. Je vois que vous avez dit qu'une mise à niveau du noyau avait aidé. Mais une mise à niveau du BIOS a peut-être fait l'affaire, également.
J'ai tout essayé et après des jours, un faible score de fanswer de ce forum a fait l'affaire: buntu 14.04 bloqué à l'arrêt
Pour moi, la solution consistait à mettre à niveau le noyau. J'ai utilisé 4.5.3 sur Ubuntu 15.10 (tout dépassement de cette valeur plantera le système d'exploitation après la connexion) et 4.7 RC3 fonctionne sur Ubuntu 16.04.
Fonctionne maintenant parfaitement :-)
J'ai eu le même problème et je pense qu'il est lié au démarrage de l'UEFI. Sur un Acer Aspire V 11, à l'origine Windows 8, j'ai effectué une nouvelle installation d'OpenSUSE Leap 15.0 avec le démarrage EFI et le démarrage sécurisé défini sur "désactivé" dans le BIOS. Maintenant, l'arrêt, le redémarrage et suspendre le travail 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 le 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 une erreur de périphérique non amorçable s'est produite. Je n'ai pas essayé le démarrage EFI avec le démarrage sécurisé désactivé.