Ubuntu 16.04 bleibt beim Herunterfahren / Neustarten hängen

Mein Ubuntu 16.04 hängt sich beim Herunterfahren / Neustart auf und ich muss die Ein- / Aus-Taste gedrückt halten, um den Computer auszuschalten. Ich weiß nicht, wie ich dies als Fehler melden und welche Befehle ausgeführt werden müssen, um das erforderliche Hardware- / Sys-Protokoll anzuzeigen die Info? Jede Hilfe wäre sehr dankbar!

Ich hatte auch dieses Problem. Es scheint ein Fehler in mehreren Distributionen zu sein.

Meine einfache Lösung bestand darin, die /etc/default/grubZeile zu bearbeiten :

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

zu

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=force"

Rennen update-grub.

Funktioniert jetzt jedes Mal. Ich benutze einen Lenovo G50 Laptop. Ich bin mir ziemlich sicher, dass ich diese Zeile in Grub durch frühere (andere) Linux-Distributionen auf diesem Laptop geändert habe.

Nachdem Sie Ihre Arbeit beendet und alle Anwendungen geschlossen haben, um Ihr Betriebssystem herunterzufahren oder neu zu starten, befolgen Sie bitte diese Schritte, um Frustrationen zu lindern.

1. Versuchen Sie es vorerst sudo swapoff -a && systemctl poweroffals Problemumgehung.
2. Es gibt eine mögliche Fehlerbehebung in Xenial, die im Paket systemd 229-4ubuntu5 vorgeschlagen wird. Gehen Sie zu Ihrer Registerkarte Systemeinstellungen-> Software und Updates-> Entwickleroptionen und klicken Sie auf das Kästchen neben Vorabversion (xenial-vorgeschlagen). Geben Sie Ihr Root-Passwort ein. Aktualisieren Sie den Cache. Klicken Sie auf der Registerkarte "Updates" auf "Updates sofort anzeigen", und schließen Sie die Systemeinstellungen. Starten Sie den Software-Updater und installieren Sie ihn jetzt.
3. Wenn das Problem weiterhin besteht, lesen Sie die folgenden Fehler: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1464917, um Informationen zum Abrufen von Protokolldaten zu erhalten, und reichen Sie wie vorgeschlagen einen neuen Fehlerbericht ein. Lesen Sie auch den Fehler: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788303 .
4. Befolgen Sie die Anweisungen zum Debuggen, die im Abschnitt "Debuggen von Boot- / Shutdown-Problemen" unter beschrieben sind, um /usr/share/doc/systemd/README.Debian.gzzu überprüfen, ob beim Herunterfahren hängende Jobs vorhanden sind. Sie müssen die Debug-Shell vor jedem Herunterfahren oder Neustart starten, indem Sie Folgendes systemctl start debug-shell eingeben : Die Aufnahme eines Bildschirmfotos journalctl -bin der Rescue-Shell ist ctl+alt+F9möglicherweise aufschlussreich. Auch die Ausgabe von systemctl list-jobsund systemctl --failedNeben einem Screenshot können Sie die Ausgabe dieser Befehle in den gleichen "filename.text" im /Stammverzeichnis einfügen, indem Sie >>filename.textam Ende der Befehle hinzufügen. Beispiel: journalctl -b >>filename.text journalctl -xe >>filename.text systemctl list-jobs >>filename.text systemctl --failed >>filename.text lsblk >>filename.text Alle diese Befehle befinden sich in derselben Datei, die zusammen angehängt wird Damit Sie beim nächsten Start analysieren und einen Fehlerbericht einreichen können, kann es hilfreich sein, die Datei an Ihren Fehlerbericht anzuhängen.

Aktualisieren

Ich hatte diese Hangs für eine ganze Weile, aber irgendwann erfuhr ich, dass meine Festplatte anfing, Sektoren usw. auszufallen. Also war es Zeit für eine neue Festplatte und eine Neuinstallation. Ich habe das Betriebssystem auf einer einzelnen Boot-Festplatte mit Swap als erster, Root als zweiter und Home als dritter logischer Partition gemäß den Empfehlungen von Ubuntu neu installiert. Technisch gesehen ist sda1 Grub, sda2 Extended, sda5, sda6 und sda7 sind Swap, Root bzw. Home. sda3 und sda4 sind nicht vorhanden. Dieses Problem ist auf dem neu auf der Festplatte installierten Betriebssystem seit ungefähr 9 Monaten nicht mehr aufgetreten. Ich laufe 16.04.02 LTS zu diesem Zeitpunkt ohne einen der Hänge beim Neustart oder Herunterfahren. Das vorherige Betriebssystem war eine Doppelinstallation von Win7 / Ubuntu und die Swap-Partition befand sich am Ende der Festplatte.

Ich behaupte nicht, dass dieses Problem mit einem Dual-Boot-System, einer fehlerhaften Festplatte oder der Reihenfolge, in der ich die Partitionen platziert habe, zusammenhängt, aber in meinem Fall gab es einen, zwei oder alle diese Faktoren. Jetzt habe ich nicht die Verschlechterung der "Reached Target Shutdown" hängen.

Ich hatte ein Problem beim Herunterfahren. Das habe ich getan:

OFFENES TERMINAL

sudo -H gedit /etc/default/grub

Ändern Sie die Zeile:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

zu

GRUB_CMDLINE_LINUX_DEFAULT="acpi=force"

Durch Entfernen quietund splashZulassen von Text während des Herunterfahrens können Sie feststellen, wo sich der Hang möglicherweise befindet.

GRUB_CMDLINE_LINUX_DEFAULT = "quiet splash" Wenn Sie "quiet" hier draußen entfernen, wird während des Startvorgangs ein Text ausgegeben, während beim Entfernen von "splash" anstelle des Begrüßungsbilds ein schwarzer Bildschirm angezeigt wird.

Speichern und schließen Sie Gedit

Dann aktualisiere Grub im Terminal:

sudo update-grub

ZUSÄTZLICH:

Mir ist aufgefallen, dass auch ein "STOP JOB" ausgeführt wurde. Daher reduziere ich die Zeitüberschreitung in /etc/systemd/system.conf:

sudo -H gedit /etc/systemd/system.conf

Entfernen #und ändern Sie die Zeiteinstellungen in den folgenden Zeilen:

DefaultTimeoutStartSec=5s

DefaultTimeoutStopSec=5s

Dann renne:

sudo systemctl daemon-reload

Das hat bei mir funktioniert.

Tdenham. Ich habe die gleiche Situation. Ich habe gerade das System von 14.04 auf 16.04 mit aktualisiert do-release-upgrade -d.

Wenn Sie keinen direkten Zugriff auf das System haben und wirklich neu starten müssen, versuchen Sie möglicherweise, einen Hard-Reset durchzuführen (wie hier beschrieben: https://major.io/2009/01/29/linux-emergency- Neustart oder Herunterfahren mit Magic-Befehlen / )

echo 1 > /proc/sys/kernel/sysrq 
echo b > /proc/sysrq-trigger

das macht den Trick. Wahrscheinlich sollten Sie synckurz vor dem zweiten Befehl ausgeführt werden.

reboot -f Vielleicht hilft es, aber ich habe es nicht ausprobiert, da ich nicht auf den Server zugreifen kann, wenn er wieder hängt.

Sie können die Datei / var / log / syslog überprüfen. Suchen Sie die Stelle, an der Sie den Computer einschalten, und überprüfen Sie die Leitungen direkt davor. Sie können es hier einfügen.

Mein Syslog:

Apr 29 11:21:48 bow NetworkManager[875]: <warn>  [1461907308.0752] dhcp4 (em0): request timed out
Apr 29 11:21:48 bow NetworkManager[875]: <info>  [1461907308.0753] dhcp4 (em0): state changed unknown -> timeout
Apr 29 11:21:48 bow NetworkManager[875]: <info>  [1461907308.0918] dhcp4 (em0): canceled DHCP transaction, DHCP client pid 2437
Apr 29 11:21:48 bow NetworkManager[875]: <info>  [1461907308.0918] dhcp4 (em0): state changed timeout -> done
Apr 29 11:21:48 bow NetworkManager[875]: <info>  [1461907308.0929] device (em0): state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]
Apr 29 11:21:48 bow NetworkManager[875]: <warn>  [1461907308.0943] device (em0): Activation: failed for connection 'Wired connection 1'
Apr 29 11:21:48 bow NetworkManager[875]: <info>  [1461907308.0970] device (em0): state change: failed -> disconnected (reason 'none') [120 30 0]
Apr 29 11:21:48 bow NetworkManager[875]: <info>  [1461907308.1062] policy: auto-activating connection 'Wired connection 1'
Apr 29 11:21:48 bow NetworkManager[875]: <info>  [1461907308.1101] device (em0): Activation: starting connection 'Wired connection 1' (df58434d-16fc-4036-b1d2-2cae515dbf19)
Apr 29 11:21:48 bow NetworkManager[875]: <info>  [1461907308.1108] device (em0): state change: disconnected -> prepare (reason 'none') [30 40 0]
Apr 29 11:21:48 bow NetworkManager[875]: <info>  [1461907308.1133] device (em0): state change: prepare -> config (reason 'none') [40 50 0]
Apr 29 11:21:48 bow NetworkManager[875]: <info>  [1461907308.1152] device (em0): state change: config -> ip-config (reason 'none') [50 70 0]
Apr 29 11:21:48 bow NetworkManager[875]: <info>  [1461907308.1167] dhcp4 (em0): activation: beginning transaction (timeout in 45 seconds)
Apr 29 11:21:48 bow NetworkManager[875]: <info>  [1461907308.1221] dhcp4 (em0): dhclient started with pid 2444
Apr 29 11:21:48 bow dhclient[2444]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 3 (xid=0x6cc9f4a)
Apr 29 11:21:51 bow dhclient[2444]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 4 (xid=0x6cc9f4a)
Apr 29 11:21:55 bow dhclient[2444]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 11 (xid=0x6cc9f4a)
Apr 29 11:22:01 bow CRON[2453]: (root) CMD (/usr/local/lib/wifictl)
Apr 29 11:22:01 bow CRON[2450]: (CRON) info (No MTA installed, discarding output)
Apr 29 11:22:06 bow dhclient[2444]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 20 (xid=0x6cc9f4a)
.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Apr 29 11:23:34 bow rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="860" x-info="http://www.rsyslog.com"] start
Apr 29 11:23:34 bow rsyslogd-2222: command 'KLogPermitNonKernelFacility' is currently not permitted - did you already set it via a RainerScript command (v6+ config)? [v8.16.0 try http://www.rsyslog.com/e/2222 ]
Apr 29 11:23:34 bow rsyslogd: rsyslogd's groupid changed to 104
Apr 29 11:23:34 bow rsyslogd: rsyslogd's userid changed to 101
Apr 29 11:23:34 bow kernel: [    0.000000] Initializing cgroup subsys cpuset
Apr 29 11:23:34 bow kernel: [    0.000000] Initializing cgroup subsys cpu
Apr 29 11:23:34 bow kernel: [    0.000000] Initializing cgroup subsys cpuacct
Apr 29 11:23:34 bow kernel: [    0.000000] Linux version 4.4.0-21-generic (buildd@lgw01-21) (gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2) ) #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 (Ubuntu 4.4.0-21.37-generic 4.4.6)

Es scheint, dass dhclient versucht, die IP-Adresse zu erreichen, auch wenn ein Neustart angefordert wird.

Falls es sich um ein hardwareabhängiges Problem handelt, dessen Ausgabe ich eingefügt habe lspci, um die Fehlerbehebung zu erleichtern.

00:00.0 Host bridge: Intel Corporation Atom Processor D2xxx/N2xxx DRAM Controller (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller (rev 09)
00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 2 (rev 02)
00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] (rev 02)
00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 02)
01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
03:00.0 Network controller: Qualcomm Atheros AR9227 Wireless Network Adapter (rev 01)

Ich habe verschiedene Methoden ausprobiert, darunter: Bearbeiten /etc/default/grub, Ausführen sudo swapoff -avor dem Herunterfahren usw. Aber keine davon hat bei mir funktioniert.

Das Ausschalten USB 3.0 legacy modeim BIOS hat bei mir funktioniert.

Ich habe hier fast alle Vorschläge ausprobiert. Die einzige Aktion, die mein Problem des Herunterfahrens / Zurücksetzens löste, war die Änderung von DefaultTimeoutStartSec& DefaultTimeoutStopSecin /etc/systemd/system.conf'10':

sudo -H gedit /etc/systemd/system.conf

und dann zu bearbeiten

DefaultTimeoutStartSec=10s
DefaultTimeoutStoptSec=10s

Ich hatte nur das gleiche Problem, ein Neustart brachte mich auf einen schwarzen Bildschirm oder manchmal auf einen schwarzen Bildschirm mit blinkendem Cursor und es gelang nie. Ich musste beachten, dass ich kein Problem mit dem Herunterfahren hatte.

Also habe ich Drive Manager geöffnet, die Intel-Microcode-Firmware für die CPU installiert, den Computer heruntergefahren und dann das Betriebssystem müde neu gestartet, und es hat endlich funktioniert.

Ich verwende Linux Mint Cinnamon 18.3, das auf Ubuntu Xenial Xerus 16.04 LTS basiert.

Hinzufügen des Kommentars des Benutzers ssasa in der Antwort, da er anderen helfen und möglicherweise mit dem Flag "Nicht mehr benötigt" gelöscht wird:

Versuchte jede Antwort hier und keine Hilfe. Aber das war am nächsten. In meinem Fall hat mir der Wechsel vom Open-Source-Treiber-Nouveau zum Nvidia-eigenen Treiber geholfen.

Ich hatte dieses Problem auf meinem ASUS Zenbook UX433FN und die Lösung, die ich benutzte, war, das BIOS zu aktualisieren. Die BIOS-Version, die ich hatte, war 301 und hat sie auf 305 aktualisiert. Alle diese Probleme sind sofort nach dieser Aktualisierung verschwunden.

Ich habe dann Ubuntu 18.04 neu installiert und anschließend die NVIDIA-Treiber ohne Probleme installiert.

Hinweis : Ich empfehle die Installation der NVIDIA-Treiber, BEVOR andere Aktualisierungen vorgenommen werden, um zu überprüfen, ob die NVIDIA-Treiber erfolgreich installiert werden können, ohne dass andere Probleme auftreten.

Meine Lösung ist hier

Aber in einfachen Worten:
sudo vim /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="splash quiet noefi"