Das System schaltet sich beim Ausschalten nicht aus, sondern hält nur an


12

Ich habe Xubuntu 15.04 auf einem Lenovo IdeaCentre A740 QHD mit einer Haswell-CPU (BIOS-Version 00KT19AUS) und NVIDIA GeForce GTX 850A 2 GB installiert. Es funktioniert meistens, außer wenn ich herunterfahre oder neu starte, schaltet es den Strom nicht aus, nachdem alles beendet wurde:

IMG:

Also muss ich auf den Netzschalter klicken, um ihn tatsächlich auszuschalten.


Ich habe die Windows 8.1-Installation beibehalten, falls es eine zukünftige Firmware gibt. Vor der Installation von Xubuntu habe ich Fastboot unter Windows deaktiviert und dann Xubuntu installiert. Leider ließ mich das UEFI-BIOS die Startreihenfolge nicht ändern, sodass Ubuntu tatsächlich als Standard gestartet wurde. Ich habe versucht bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi, "Quickboot" (was auch immer das ist) im BIOS zu deaktivieren, das Boot-Repair-Programm von einer Live-Sitzung aus zu versuchen und SecureBoot zu deaktivieren, aber es würde trotzdem nur Windows booten. Am Ende habe ich mit Hilfe von EricC ^^ von #ubuntu auf freenode einfach die .efi-Dateien umgeschaltet, um den Boot-Manager zu täuschen, Ubuntu sei 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

Ich weiß nicht, ob dies einen Einfluss auf die Probleme beim Herunterfahren hat.

EDIT: Denken Sie mal darüber nach, der Neustart von der Xubuntu-Installation (als ich über ein USB-Laufwerk gebootet wurde) hat auch nicht funktioniert.


Was ich bisher versucht habe, um es zum Herunterfahren zu bringen:

  • acpi = aus → kein Unterschied
  • acpi = Kraft → kein Unterschied
  • Installieren Sie proprietäre Nvidia-Treiber →, bei denen X gerade nicht mit der Meldung "bbswitch: Kein diskretes VGA-Gerät gefunden" gestartet wurde.
  • verschiedene Variationen sudo poweroff, sudo shutdown now, sudo shutdown -h nowusw.

Wenn ich neu starte anstatt herunterzufahren, wird diese psychedelische Lichtshow auf meinem Monitor angezeigt und ich muss lange auf den Netzschalter klicken, um sie auszuschalten:

Neustart Spaß

Wenn es hilfreich ist, ist hier eine journalctl - Ausgabe direkt nach dem Booten und vielleicht sogar noch besser: journalctl -b -1 (Journal vom Booten bis zum Herunterfahren) .


Vielleicht auch im Zusammenhang damit stelle ich jetzt fest, dass das Drücken des Netzschalters während der Anmeldung bei XFCE den Computer sofort ausschaltet, obwohl ich die XFCE-Energieeinstellungen auf "Fragen, wenn der Netzschalter gedrückt wurde" und "Nichts tun" auf anderen Tasten habe.

Mein /etc/systemd/logind.confhat keine unkommentierten Zeilen außer der [Login]Kopfzeile.

Es wird ein /usr/sbin/acpidProzess als root ausgeführt.


BEARBEITEN: Weitere Enthüllungen: Strg + Alt + Löschen starten tatsächlich gut von GRUB neu.

EDIT2: Ich habe einen Fehlerbericht eingereicht , da dies mit den regulären Tricks nicht behoben werden kann .

EDIT3: Gelöst mit acpi = noirq und Kernel 4.4 und neuer.


Ich habe ähnliche Probleme unter Ubuntu 15.04 Desktop / Server, bei denen das System beim Herunterfahren / Starten hängen bleibt. Meine Theorie ist, dass beide verwandt sein können. Ich habe das Startproblem eingegrenzt, indem ich überprüft habe dmesg, dass versucht wurde, ein nicht vorhandenes Dateisystem bereitzustellen, und eine Minute gewartet, bevor es weiter gebootet wurde. Auch die Probleme beim Herunterfahren waren mit einem Bereitstellen verbunden, da ich meinen Desktop mit einem heruntergefahren habe Wenn Sie die NFS-Verbindung zu meinem Server öffnen, ohne sie zwangsweise zu entfernen, bleibt sie hängen. Ich bin mir nicht sicher, ob diese Probleme mit Ihrem Problem zusammenhängen, aber ich dachte, ich würde sie nur in der Hülle ansprechen.
Michael Lindman

1
Der Kommentar von M. Lindman macht einen guten Punkt schräg. Es gibt ein Protokoll, das Ihnen detailliert zeigt, was los ist. Lesen Sie es mit journalctl --all. Bearbeiten Sie Ihre Antwort und zeigen Sie sie anderen, wenn Sie Hilfe beim Verständnis benötigen.
JdeBP

JdeBP: hinzugefügt, aber soweit ich das beurteilen kann, gibt journalctl nur Informationen aus diesem Bootup - gibt es eine Möglichkeit, die vorherigen beizubehalten?
Unhammer


Danke JdeBP, ich habe mich gefragt, warum diese Protokolle nicht gespeichert wurden :) Ich habe einen neuen Link am Ende der Frage hinzugefügt, obwohl ich selbst nichts Verdächtiges finden kann.
Unhammer

Antworten:


4

Meine beste Vermutung basierend auf den bereitgestellten Informationen ist ein fehlerhaftes UEFI-BIOS. Beim Durchsuchen der Kernel-Bugs nach Haswell fand ich eine mögliche Problemumgehung. Versuchen Sie es xhci_hcd.quirks=262144als Startoption oder deaktivieren Sie xhci in der UEFI.

Die einzigen anderen Optionen, die mir einfallen, sind folgende:

A) Warten Sie und hoffen Sie, dass entweder das Kernel-Entwicklungsteam oder Lenovo ein Update vorlegen, mit dem das Problem behoben wird.

B) Wenden Sie sich an den Lenovo Support, und fordern Sie ein BIOS-Update an, mit dem das Problem behoben wird, oder ermutigen Sie andere Personen mit demselben Problem, Ihren Fehlerbericht zu abonnieren. Dies kann effektiver sein oder auch nicht als A.

C) Ändern Sie das BIOS oder den Kernel selbst, bis Sie das gewünschte Ergebnis erzielen (nichts für schwache Nerven). Ich empfehle diese Vorgehensweise nicht, sondern nur der Vollständigkeit halber. Durch Ändern des BIOS kann es leicht zu einem nicht bootfähigen System mit ungültiger Garantie kommen. Sie sollten auch die Gründe für und gegen das Kompilieren Ihres eigenen Kernels im oben genannten verknüpften Dokument sorgfältig lesen.

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


Das ist für Broadwell-Systeme ( support.lenovo.com/us/en/products/desktops-and-all-in-ones/… ), Mine ist ein Haswell (BIOS-Revision 00KT19AUS)
Unhammer

Neue Informationen für Sie in Frage gestellt.
Elder Geek

Ich habe meine Antwort bearbeitet
Elder Geek

Hinweis: Es scheint, dass Christopher M. Penalver zu derselben falschen Schlussfolgerung gekommen ist, die ich in Bezug auf das BIOS gezogen habe. Möglicherweise möchten Sie sie über Ihren gemeldeten Fehler auf den neuesten Stand bringen.
Elder Geek

1
XHCI-Einstellungen beziehen sich auf USB - ich hoffe, das hilft Ihnen, sie in Ihrem BIOS zu finden. Wenn nicht, wenden Sie sich an den Lenovo Kundendienst unter 1 (855) 253-6686 und fragen Sie, wo sie zu finden sind oder ob ein BIOS-Update in Arbeit ist. Alles Gute!
Elder Geek

4

Versuchen Sie es hinzuzufügen

acpi=noirq

zu den Kernel-Boot-Parametern. Dadurch kann es beim Herunterfahren / Neustart ausgeschaltet werden (getestet mit den Kerneln 4.4 und 4.7rc5).

Es scheint ebenfalls anzuhalten, wird jedoch beim Drücken des Netzschalters leider nicht fortgesetzt.

Das hat auf der A740 seit über drei Monaten gut funktioniert, also nenne ich das gelöst.


Ich bin froh, dass meine Option A) für Sie funktioniert hat! :-)
Elder Geek

Wie in "Warten und hoffen"? Was ich tatsächlich getan habe, war, es als Fehler im Ubuntu-Linux-Paket zu melden und einige neuere Hauptversionen auszuprobieren. Als das dann nichts löste, meldete ich es stromaufwärts zuerst an die falsche Komponente bugzilla.kernel.org/show_bug.cgi?id = 118401 , wurde dann an ide / ahci gesendet und fand nach einigen E-Mail-Austauschen und dem Versuch, eine nützliche Debug-Ausgabe zu erhalten, marc.info/?t=146296312800002&r=1&w=2 und versuchte verschiedene dort vorgeschlagene Optionen, die funktionierende. Nur warten und aktualisieren löst es nicht, die Grub-Einstellungen müssen bearbeitet werden.
Unhammer

Trotzdem bin ich froh, dass du es sortiert hast. Ob es A oder B war :-)
Elder Geek

2

Nachdem ich die Systemdateien durchsucht hatte, sah ich einige Warnungen bezüglich des BIOS. Ich habe die Website von Intel überprüft und es war ein Upgrade verfügbar, das ein Problem mit überlappenden Speicheradressen zu lösen schien. Nicht offensichtlich dasselbe, aber meine Protokolle zeigten an, dass verschiedene Sektoren meines BIOS unerwartete Werte zurückgaben, was den Start des Kernels nicht verhinderte, aber offensichtlich nicht gut war. Das Problem war erst offensichtlich, als der Kernel die Verwendung einstellte upstartund mit der Verwendung begann systemd.

Ich habe das aktualisierte BIOS heruntergeladen und angewendet und jetzt schaltet sich mein System wie erwartet aus.


Welches System / BIOS war das? (Lenovo hat noch kein aktualisiertes BIOS für meine Prozessorarchitektur veröffentlicht.)
Unhammer

0

Was cat /etc/default/haltsagt? Versuchen Sie es halt -p.

Sie können /etc/init.d/haltdiese Zeilen auch bearbeiten und entfernen:

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

unten

poweroff="-p"

halt -pist nicht anders, es wird immer noch nicht vollständig heruntergefahren.
Unhammer

oh, und / etc / default / halt sagt HALT=poweroff. Aber sollte nicht halt -poder poweroff oder shutdown nownoch arbeiten , unabhängig davon , was da drin ist?
Unhammer

0

Aus Ihren Kernel-Protokollen (Screenshot) geht hervor, dass unbeaufsichtigte Upgrades die Ursache für Ihr Problem sein könnten. Vor diesem Jahr gab es mehrere Fehlerberichte , die jedoch nicht behoben wurden. Eine vorübergehende Lösung wäre, automatische Updates durch Updates zu deaktivieren. Wir werden dies jedoch als letzten Ausweg beibehalten. Aber zuerst werden wir ein manuelles Upgrade versuchen:

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

Wenn dies Ihr Problem nicht gelöst hat und das Upgrade ohne Fehler oder Warnungen verlief, werden wir versuchen, etwas tiefer zu graben, um herauszufinden, was das Problem verursacht. Sie könnten einen Hinweis erhalten, indem Sie den Inhalt von überprüfen /var/log/unattended-upgrades. Wenn Sie herausfinden könnten, welches Update das Problem verursacht, können Sie das Update durch Ändern auf die schwarze Liste setzen /etc/apt/apt.conf.d/50unattended-upgrades.

Wenn das Problem immer noch nicht behoben wird, können Sie das Paket vorübergehend entfernen, um zu bestätigen, ob es die Ursache ist:

sudo apt-get remove unattended-upgrades 

Ich empfehle, dass Sie es neu installieren, auch wenn es Ihr Problem gelöst hat. Wenn dies der Fall ist, bringen Sie den Fehlerbericht mit weiteren Informationen zurück, damit die Entwickler Ihr Problem lösen können.

Warnung: Wenn Sie die automatische Aktualisierung deaktivieren und Ihr System dann nicht manuell aktualisieren, besteht unter Sicherheits- und Stabilitätsgesichtspunkten möglicherweise ein Risiko für Sie.


Dies ist eine Neuinstallation - autoremoveund dist-upgrade"0 zum Upgrade, 0 zum Entfernen" usw. und / var / log / unbeaufsichtigte Upgrades ist leer: $ wc -c < /var/log/unattended-upgrades/unattended-upgrades-shutdown.loggibt0
unhammer

Außerdem sind keine Programme enthalten /lib/systemd/system-shutdown, sodass keine Dienste aufgerufen werden sollten, wenn ich das Gerät ausschalte . Und das unattended-upgradesvollständige Entfernen hatte keine Wirkung.
Unhammer

0

Ich habe alles versucht und nach Tagen hat ein schlecht bewerteter Fanswer aus diesem Forum den Trick gemacht: Ubuntu 14.04 blieb beim Herunterfahren hängen

Für mich bestand die Lösung darin, den Kernel zu aktualisieren. Ich habe 4.5.3 unter Ubuntu 15.10 verwendet (alles, was größer ist, stürzt das Betriebssystem nach der Anmeldung ab). Und 4.7 RC3 funktioniert unter Ubuntu 16.04.

Funktioniert jetzt perfekt :-)


Das hat bei meinem System nicht funktioniert. Wie die Fehlerberichte zeigen, habe ich bereits viele 4.7-Kernel ausprobiert - diese machten das Booten einfach unmöglich! Nachdem ich die Upstream- und Debugging-Hilfe von der Kernel-Liste gemeldet hatte, war die Problemumgehung für meine beiden Probleme (Booten überhaupt und Ausschalten beim Herunterfahren) acpi=noirq askubuntu.com/a/794739/25639
Unhammer

0

Ich kann bestätigen, dass es definitiv etwas mit ACPI zu tun hat. Mein System zeigt genau dieses Verhalten, wenn ich acpi = off in Linux 4.20-rc3 für Kernel-Entwicklungszwecke übergebe. Wenn Ihr ACPI zuerst aktiviert wurde, besteht eine gute Chance, dass die ACPI-Implementierung im BIOS fehlerhaft war. Ich sehe, Sie sagten, ein Kernel-Upgrade habe geholfen. Aber möglicherweise hat auch ein BIOS-Upgrade den Trick getan.


Dies beantwortet die Frage nicht wirklich. Ihr Vorschlag zum BIOS weist lediglich auf eine mögliche Lösung hin, die Sie anscheinend noch nicht ausprobiert haben. Tatsächlich gab das OP an, dass er sein Problem durch "Hinzufügen von acpi = noirq zu den Kernel-Boot-Parametern" gelöst hatte.
CentaurusA

0

Ich hatte das gleiche Problem und glaube, dass es mit dem UEFI-Boot zusammenhängt. Auf einem Acer Aspire V 11, ursprünglich Windows 8, habe ich OpenSUSE Leap 15.0 neu installiert, wobei der EFI-Start und der sichere Start im BIOS auf "deaktiviert" eingestellt waren. Jetzt funktioniert das Herunterfahren, Neustarten und Anhalten korrekt.

Zuvor habe ich Ubuntu 16.04, 18.04 und zuletzt 18.10 unter Legacy-Boot verwendet und alle hatten das gleiche Problem. Ich habe auch Fedora 24, OpenSUSE Tumbleweed und OpenSUSE 42.2 ausprobiert, alle mit dem gleichen Problem.

Ich habe auch Ubuntu 18.10 mit aktiviertem EFI-Boot und sicherem Boot ausprobiert, aber einen nicht bootfähigen Gerätefehler erhalten. Ich habe nicht versucht, EFI mit deaktiviertem sicheren Start zu starten.


-1

Ihre Hardware unterstützt möglicherweise kein Herunterfahren der Software. Ich habe das schon einmal erlebt und der Weg zum Testen ist folgender:

sudo poweroff

Wenn die Hardware dadurch nicht heruntergefahren wird, handelt es sich um ein Hardwareproblem und nicht um Software.


3
Wie die Frage besagt, habe ich das ohne Erfolg versucht. Aber GRUB verwaltet den Neustart der Software einwandfrei (nicht sicher, wie das Ausschalten dort getestet werden soll), während Windows 8.1 das Ausschalten der Software und den Neustart auf dieser Hardware einwandfrei durchführt. Es scheint ein Kernel-Problem zu sein, daher habe ich einen Fehlerbericht eingereicht .
Unhammer

1
Upvote für die Einreichung eines Fehlerberichts.
Daniel

-1 Weil ich etwas anderes finde. Es endet mit systemd-shutdown[1]: Powering off.Die Maschine ist mit 12.04 und 14.04 einwandfrei ausgeschaltet, aber keine Neuinstallation von 16.04.
Nateowami

-1
  1. Starten Sie dann F2 neu
  2. Gehen Sie zur Konfiguration und deaktivieren Sie xHCI
  3. Speichern und schließen

Denk nicht darüber nach, vertraue mir einfach und mach es :)


Ich kann nirgendwo im BIOS XHCI-Einstellungen finden. Ich kann den gesamten USB-Anschluss ausschalten, aber das ist für mich keine Option.
Unhammer

Dies wird nicht alle USB drehen, es wird nur USB3 drehen
Talal
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.