Linux Mint 18 hängt beim Herunterfahren


10

Ich bin beunruhigt über den berüchtigten Fehler beim Herunterfahren / Einfrieren. Immer wenn ich Minze herunterfahre, wird nur der erste Punkt auf dem Begrüßungsbildschirm grün und friert dann ein. Ich hatte dieses Problem auch unter Ubuntu 16.04. Ich beabsichtige, Linux für Spiele zu verwenden. Hier sind meine Systemspezifikationen.

           Desktop: Cinnamon 3.0.7 (Gtk 3.18.9-1ubuntu3.1)
           Distro: Linux Mint 18 Sarah
Machine:   Mobo: Intel model: DG33FB v: AAD81072-307
           Bios: Intel v: DPP3510J.86A.0407.2008.0218.0923 date: 02/18/2008
CPU:       Quad core Intel Core2 Quad Q6600 (-MCP-) cache: 4096 KB
           flags: (lm nx sse sse2 sse3 ssse3 vmx) bmips: 19199
           clock speeds: max: 2394 MHz 1: 1596 MHz 2: 1596 MHz 3: 2128 MHz
           4: 1862 MHz
Graphics:  Card: NVIDIA GT218 [GeForce 210] bus-ID: 01:00.0
           Display Server: X.Org 1.18.4 drivers: nouveau (unloaded: fbdev,vesa)
           Resolution: 1024x768@60.00hz
           GLX Renderer: Gallium 0.4 on NVA8
           GLX Version: 3.0 Mesa 11.2.0 Direct Rendering: Yes
Audio:     Card-1 NVIDIA High Definition Audio Controller
           driver: snd_hda_intel bus-ID: 01:00.1
           Card-2 Intel 82801I (ICH9 Family) HD Audio Controller
           driver: snd_hda_intel bus-ID: 00:1b.0
           Sound: Advanced Linux Sound Architecture v: k4.4.0-21-generic
Network:   Card: Intel 82566DC-2 Gigabit Network Connection
           driver: e1000e v: 3.2.6-k port: 30e0 bus-ID: 00:19.0
           IF: enp0s25 state: up speed: 100 Mbps duplex: full mac: <filter>
Drives:    HDD Total Size: 160.0GB (4.9% used)
           ID-1: /dev/sda model: Hitachi_HDS72101 size: 160.0GB
Partition: ID-1: / size: 17G used: 5.4G (35%) fs: ext4 dev: /dev/sda5
           ID-2: swap-1 size: 2.13GB used: 0.00GB (0%) fs: swap dev: /dev/sda6
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 47.0C mobo: N/A
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 178 Uptime: 6 min Memory: 646.8/1990.4MB
           Init: systemd runlevel: 5 Gcc sys: 5.4.0
           Client: Shell (bash 4.3.421) inxi: 2.2.35 

Das Ausschalten des Netzwerks vor dem Herunterfahren macht keinen Unterschied, sodass es nicht an nicht erreichbaren Remoteservern liegt.

Neustart funktioniert gut.

Ergebnis von journalctl --boot -1 -e --full

Specifying boot ID has no effect, no persistent journal was found

Das ausführliche Booten hatte eine Fehlerzeile, die etwas darüber aussagte, dass Kernelmodule nicht geladen werden konnten.

Ergebnis des ausführlichen Herunterfahrens (letzte beiden Zeilen):

[OK] Reached target shutdown.
[54.278173] reboot: power down

Ergebnis von systemctl status

● lol-desktop
    State: degraded
     Jobs: 0 queued
   Failed: 1 units
    Since: Thu 2016-11-17 18:35:37 IST; 5min ago

PS Ich starte es doppelt mit Windows 7.


Führen Sie aus journalctl --boot -1 -e --full, bearbeiten Sie Ihre Frage und geben Sie die entsprechende Ausgabe dort ein. Dies wird den Leuten zeigen, was systemd damals gedacht hat.
JdeBP

Änderungen werden durchgeführt.
Shivodit Gill

Bitte Leute, antwortet, dieses Problem ist wirklich frustrierend
Shivodit Gill

Das Tagebuch erzählt den Leuten, was los war. "Es friert irgendwie ein." nicht. Leider haben Sie Ihr System so konfiguriert, dass das Journal bei jedem Herunterfahren verworfen wird, anstatt es dauerhaft zu speichern /var/log/journal, sodass Sie der Welt nicht sagen können, was das Journal aufgezeichnet hat, und die Benutzer dann nicht diagnostizieren können, was vor sich ging (oder am wahrscheinlichsten war) falsch.
JdeBP

Wie aktiviere ich es? Muss ich ein ausführliches Herunterfahren durchführen?
Shivodit Gill

Antworten:


7

Ich habe zwei Tage mit dem Linux Mint 18.3-System auf einem Dell 5577-Laptop (Nvidia 1050) gekämpft. Beim Herunterfahren oder Neustart war der Bildschirm schwarz und nichts passierte.

Keine der folgenden Möglichkeiten hat geholfen :(

  • Änderung von grub (Hinzufügen von GRUB_CMDLINE_LINUX = "apm = power_off", "acpi = force" usw.)
  • Deaktivieren von EuP (Einschalten des USB-Anschlusses am ausgeschalteten Computer)

Was hat geholfen :)

  • Wählen Sie Menü -> Administration -> Treiberverwaltung -> wählen Sie nvidia driver anstelle von nouveau . Warten Sie geduldig, da es ein wenig dauert. Der erste Neustart oder das Herunterfahren schlägt fehl, aber nach dem Neustart funktioniert es endlich einwandfrei! :) :)

Suche: Linux Mint wird nicht heruntergefahren oder neu gestartet, Linux Ubuntu wird nicht heruntergefahren oder neu gestartet, Linux Mint wird nicht heruntergefahren oder neu gestartet, Linux Ubuntu wird nicht heruntergefahren oder neu gestartet


1
Genau das gleiche gilt für mich mit Dell XPS 15. Leider sind die Nvidia-Treiber unbrauchbar, da es ausreicht, nur ein Vollbildvideo anzusehen, um die Lüfter so stark anzutreiben, dass Sie eigentlich nichts hören können. Dies tritt auf, wenn Prime auf Nvidia- oder Intel-Grafik eingestellt ist.
Neutrino

Legende, das hat bei mir auf einem HP Zbook Studio G3 funktioniert.
Sean Missingham

Arbeitete für ein Asus Zenbook Pro UX550. Vielen Dank !!
Ether_Joe

Super langsame Neustarts und Herunterfahren auf meinem Lenovo T430 mit Nvidia NVS 5400M wurden durch Auswahl des Nvidia-Treibers anstelle des Jugendstils gelöst. Vielen Dank!
Jaxian

3

Was für mich unter Gentoo Linux (Kernel 4.17.5) zur Lösung dieses Problems funktioniert hat, war das Hinzufügen einer Option für den Nouveau-Treiber:

vram_pushbuf=1

( nouveau.vram_pushbuf=1wenn Nouveau in den Kernel eingefügt wird).

Ich habe dies anhand einer Fehlermeldung am Ende des Stoppvorgangs festgestellt. Das System blieb hängen, als versucht wurde, das Video als letzten Vorgang für ein vollständiges Herunterfahren ohne diese Option für meine NVIDIA-GPU auszuschalten.


1

Dieses Problem war auch für mich aktuell. Was am interessantesten ist - als ich zuerst die Benutzersitzung manuell schloss und dann das System herunterfuhr, verlief alles reibungslos und ohne Verzögerung. Heute habe ich einige Zeit aufgewendet, um das Problem zu lösen, und hier sind einige Ergebnisse. Das Problem entsteht, weil das System beim Herunterfahren auf etwas wartet, was seiner Meinung nach passieren muss. Das Ding ist für jeden einzelnen Fall individuell. In meinem Fall waren es sogar zwei Probleme, von denen ich eines gefunden habe. Das System suchte nach einer Festplatte, die es nicht gab. Wie? Weil ich mit einigen anderen Linux-Versionen experimentiert und für alle Versionen das gleiche Laufwerk wie swap ausgewählt habe. Während der Installation des zweiten Linux, UUIDdes Geräts wurde geändert, aber in Systemdateien des ersten Linux blieb es unverändert. Aber noch einmal - es war mein Problem, deins ist vielleicht überhaupt nicht gleich. Nachdem ich das obige Problem behoben hatte, hatte ich noch ein anderes. Ich verlor meine Hoffnung und gab einfach die Versuchung auf, das Problem mit brutaler Gewalt zu lösen. Ich habe den Parameter /etc/systemd/user.confund /etc/systemd/system.conffiles DefaultTimeoutStopSecvon 90 secondsauf geändert 5 seconds. Vergessen Sie nicht, die Zeile zu kommentieren (um das #Zeichen am Zeilenanfang mit dem Parameter zu entfernen DefaultTimeoutStopSec).

Jetzt funktioniert es gut, das System fährt sehr schnell herunter.


1

Eine andere mögliche Lösung - insbesondere für neuere Hardware mit (U) EFI - ist das Hinzufügen des Boot-Parameters apm=power_off. Sie können es der Definition von GRUB_CMDLINE_LINUX_DEFAULTin /etc/default/grubhinzufügen oder die Zeile hinzufügen, wenn sie noch nicht vorhanden ist.

GRUB_CMDLINE_LINUX_DEFAULT="apm=power_off"

Aktualisieren Sie dann die Grub-Installation gemäß dem Handbuch Ihres Betriebssystems, z.

update-grub # Debian/Ubuntu
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg # EFI on Fedora etc
grub2-mkconfig -o /boot/grub2/grub.cfg # BIOS

0

Ich nehme an, Ihr System schaltet sich nach den 54ern aus. Es ist möglicherweise ein blockierter Prozess. Wenn Sie beim Herunterfahren von / var / lib / systemd / coredump / for files viel Festplattenaktivität haben, können Sie die Core-Dumps deaktivieren (als Workaround und nicht als Root-Lösung).


0

Ausschalten USB 3.0 legacy modeoder usb3.0 configuration in pre-osim BIOS , hat bei mir funktioniert.


0

Linux Mint 18.1:

Mein Problem war, dass mein neuer PC in unsystematischen Momenten beim Herunterfahren / Ausschalten hängen blieb. Ich musste den Ein- / Ausschalter einige Sekunden lang drücken (auch mechanisches Ausschalten).

Nachdem ich eine Einstellung im UEFI / BIOS geändert hatte, war das Problem behoben:

  1. Öffnen Sie das UEFI / BIOS:

  2. Erweitert → Powermanagement → EuP-Einstellung deaktiviert

  3. Beenden Sie das Programm, indem Sie die Einstellungen speichern

Starten Sie dann Ihren Computer neu und alles sollte in Ordnung sein.


1
Was macht die EuP-Einstellung oder wofür steht sie?
Xen2050

0

Für mich wurde dieses Problem behoben, nachdem ich die Werte "quiet" und "splash" aus dem Parameter GRUB_CMDLINE_LINUX_DEFAULT in grub gelöscht hatte.

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.