Je suis troublé par la tristement célèbre erreur d'arrêt / gel de l'arrêt. Chaque fois que j'arrête la menthe, seul le premier point de l'écran de démarrage devient vert, puis il se fige. J'ai également eu ce problème sur Ubuntu 16.04.J'ai l'intention d'utiliser Linux pour les jeux. Voici mes spécifications système-
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: [email protected]
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
La désactivation du réseau avant la fermeture ne fait aucune différence, donc ce n'est pas dû à des serveurs distants inaccessibles.
Le redémarrage fonctionne bien.
Résultat de journalctl --boot -1 -e --full
Specifying boot ID has no effect, no persistent journal was found
Le démarrage détaillé avait une ligne d'échec, ce qui en disait long sur le fait de ne pas pouvoir charger les modules du noyau.
Résultat de l'arrêt détaillé (deux dernières lignes):
[OK] Reached target shutdown.
[54.278173] reboot: power down
Résultat de systemctl status
● lol-desktop
State: degraded
Jobs: 0 queued
Failed: 1 units
Since: Thu 2016-11-17 18:35:37 IST; 5min ago
PS Je le double boot avec Windows 7.
la source
journalctl --boot -1 -e --full
, modifiez votre question et mettez-y la sortie appropriée. Cela montrera aux gens ce que Systemd pensait qu'il faisait à l'époque./var/log/journal
, vous ne pouvez donc pas dire au monde ce que le journal a enregistré, et les gens ne peuvent pas ensuite diagnostiquer à partir de cela ce qui se passait (ou était le plus probable) faux.Réponses:
J'ai combattu deux jours avec le système Linux Mint 18.3 sur un ordinateur portable Dell 5577 (Nvidia 1050). À l'arrêt ou au redémarrage, l'écran était noir et rien ne s'est produit.
Aucun des éléments suivants n'a aidé :(
Qu'est-ce qui a aidé :)
Recherche: Linux Mint ne s'arrête ni ne redémarre, linux ubuntu ne s'arrête ni ne redémarre, linux mint ne s'arrête ni ne redémarre, linux ubuntu ne s'arrête ni ne redémarre
la source
Ce qui a fonctionné pour moi dans Gentoo linux (noyau 4.17.5) pour résoudre ce problème a été d'ajouter en option pour le nouveau pilote de suivant:
(
nouveau.vram_pushbuf=1
lorsque nouveau est inséré dans le noyau).J'ai découvert cela à partir d'un message d'erreur à la fin du processus d'arrêt. Le système s'est bloqué lors de la tentative de fermeture de la vidéo en tant que porc final pour un arrêt complet sans cette option pour mon GPU nvidia.
la source
Ce problème était réel pour moi aussi. Quel est le plus intéressant - lorsque j'ai fermé la première session utilisateur manuellement, puis arrêté le système, tout s'est bien passé sans aucun délai. Aujourd'hui, j'ai consacré du temps à résoudre le problème et voici quelques résultats. Le problème se pose parce que le système attend à l'arrêt quelque chose qui, à son avis, doit se produire. La chose même est individuelle pour chaque cas distinct. Dans mon cas, c'était même deux problèmes dont l'un que j'ai trouvé. Le système recherchait un disque dur qui n'existait pas. Comment? Parce que j'ai expérimenté avec d'autres versions de Linux et choisi pour toutes les versions le même périphérique de lecteur que swap. Lors de l'installation du deuxième Linux, UUIDde l'appareil a été changé, mais dans les fichiers système du premier Linux, il est resté inchangé. Mais, encore une fois, - c'était mon problème, le vôtre ne se ressemble peut-être pas du tout. Après avoir résolu le problème ci-dessus, j'en avais encore un autre. J'ai perdu espoir et j'ai abandonné la tentation de résoudre le problème avec une force brute. J'ai changé le paramètre
/etc/systemd/user.conf
et les/etc/systemd/system.conf
fichiersDefaultTimeoutStopSec
de90 seconds
à5 seconds
. N'oubliez pas de décommenter la ligne (pour supprimer le#
signe au début de la ligne avec le paramètreDefaultTimeoutStopSec
).Maintenant, cela fonctionne bien, le système s'arrête très rapidement.
la source
Une autre solution possible - en particulier pour les nouveaux matériels utilisant (U) EFI - consiste à ajouter le paramètre de démarrage
apm=power_off
. Vous pouvez l'ajouter à la définition deGRUB_CMDLINE_LINUX_DEFAULT
dans/etc/default/grub
ou ajouter la ligne si elle n'existe pas encore.Mettez ensuite à jour l'installation de grub conformément au manuel de votre système d'exploitation, par exemple:
la source
je suppose que votre système s'éteint après les années 54? c'est peut-être un processus bloqué, si vous avez beaucoup d'activité sur le disque lors de la vérification de l'arrêt / var / lib / systemd / coredump / pour les fichiers, vous pouvez ensuite désactiver les vidages de mémoire (comme solution de contournement plutôt que comme solution racine)
la source
Désactiver
USB 3.0 legacy mode
ouusb3.0 configuration in pre-os
dans le BIOS , a fonctionné pour moi.la source
Linux Mint 18.1:
Mon problème était que mon nouveau PC se bloquait à des moments non systématiques à l'arrêt / hors tension. J'ai dû appuyer sur le bouton marche / arrêt pendant plusieurs secondes (également hors tension mécanique).
Après avoir modifié un paramètre dans l'UEFI / BIOS, le problème avait disparu:
Ouvrez l'UEFI / BIOS:
Avancé → Powermanagement → Paramètre EuP désactivé
Quittez en enregistrant les paramètres
Redémarrez ensuite votre ordinateur et tout devrait être OK.
la source
Pour moi, ce problème a été résolu après avoir supprimé les valeurs "silencieux" et "splash" du paramètre GRUB_CMDLINE_LINUX_DEFAULT dans grub.
la source