it-swarm.com.de

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!

88
Tdenham

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

Meine einfache Lösung bestand darin, die /etc/default/grub -Zeile zu bearbeiten:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

zu

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=force"

Führen Sie update-grub aus.

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.

43

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. Probieren Sie _Sudo swapoff -a && systemctl poweroff_ als Workaround aus.
  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 (von 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 Informationen zum Abrufen von Protokolldaten und wie vorgeschlagen dort einen neuen Fehlerbericht einreichen. Lesen Sie auch den Fehler: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=7883 .
  4. Befolgen Sie die Anweisungen zum Debuggen, die im Abschnitt "Debuggen von Boot-/Shutdown-Problemen" von _/usr/share/doc/systemd/README.Debian.gz_ beschrieben sind, um zu ü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 eingeben: _systemctl start debug-Shell_ Das Aufnehmen eines Bildschirmfotos von _journalctl -b_ in der Rettungs-Shell _ctl+alt+F9_ ist möglicherweise aufschlussreich. Auch die Ausgabe von _systemctl list-jobs_ und _systemctl --failed_ Neben einem Screenshot können Sie die Ausgabe dieser Befehle ausgeben und durch Hinzufügen von _/_ in denselben "filename.text" auf _>>filename.text_ einfügen ) __ am Ende der Befehle, z _journalctl -b >>filename.text_ _journalctl -xe >>filename.text_ _systemctl list-jobs >>filename.textsystemctl --failed >>filename.textlsblk >>filename.text_ Alle diese Dateien befinden sich in derselben Datei, die Sie beim nächsten Start analysieren können Fehlerbericht Es kann hilfreich sein, die Datei in Ihren Fehlerbericht aufzunehmen.

Update

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.

14
xtrchessreal

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 das Entfernen von quiet und splash wird Text während des Herunterfahrens zugelassen, um festzustellen, 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

entferne # und ändere das Timing in den folgenden Zeilen:

DefaultTimeoutStartSec=5s

DefaultTimeoutStopSec=5s

Dann renne:

Sudo systemctl daemon-reload

Das hat bei mir funktioniert.

10
pst007x

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

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

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

das macht den Trick. Wahrscheinlich sollten Sie sync kurz vor dem zweiten Befehl ausführen.

reboot -f kann helfen, aber ich habe es nicht versucht, da ich nicht auf den Server zugreifen kann, wenn er erneut 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 ([email protected]) (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 dies ein hardwareabhängiges Problem ist, habe ich die Ausgabe von lspci eingefügt, 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)
2
Alek_A

Ich habe hier fast alle Vorschläge ausprobiert. Die einzige Aktion, die mein Problem mit dem Herunterfahren/Zurücksetzen gelöst hat, war, DefaultTimeoutStartSec & DefaultTimeoutStopSec in /etc/systemd/system.conf auf '10' zu ändern:

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

und dann zu bearbeiten

DefaultTimeoutStartSec=10s
DefaultTimeoutStoptSec=10s
2
joelgsf

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

Das Deaktivieren von USB 3.0 legacy mode im BIOS hat bei mir funktioniert.

2
Hieu

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.

Changing from Do not update the CPU microcode to intel-microcode

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

2
Shayan

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 NVIDIA-Treiber VOR allen anderen Updates zu installieren, um zu überprüfen, ob die NVIDIA-Treiber erfolgreich installiert werden können, ohne dass andere Probleme auftreten.

0
Jon