Freeze au lieu de s'éteindre / redémarrer Résolu

Question

Bonjour à tous,

J'ai installé récemment Ubuntu 15.10 64 bits et mon problème est que l'ordinateur freeze au lieu de s'éteindre / redémarrer. Plus précisément tous les processus se ferment correctement mais une fois ceci fait Ubuntu freeze sur le fond d'écran et ne répond plus, me forçant à éteindre de force depuis le bouton d'alimentation.  L'écran de shutdown n’apparaît donc même pas (je ne peut donc pas appuyer sur ESC pour vérifier la console d'éteinte).

J'ai effectué toutes les mises a jours possibles (grub, paquets...).

Je n'ai qu'une souris branchée en usb lors de la tentative d'éteinte (un conflit provenant des périphériques me semble donc peu probable).
Peut importe le nombre de combinaisons de commande effectuées le résultat reste le même (shutdown, poweroff, reboot, etc et cela même avec toutes les options).

J'ai également tenté de modifier les paramètre ACPI (shutdown -h now ...)

Editer le menu GRUB pour ajouter au kernel (acpi=off) ne m'a pas plus avancé.

En voguant de forum en forum je suis tombé sur ce topic qui décrit parfaitement mon problème et qui semble être résolu par :

http://ubuntuforums.org/showthread.php?t=1694262&p=10489760#post10489760

, ce qui serait cohérent vu que de temps en temps la carte wifi de mon Pc semble ne pas fonctionner au démarrage.

Je ne m'y connais pas du tout sur le domaine technique pointé par la solution proposée quelqu'un peut il me l'expliqué et m'aider a appliquer cette solution à mon driver wifi ?

Merci d'avance.

mamiemando · Accepted Answer

Bonjour,

Un pilote bizarre (les pilotes wifi en faisant partie) peuvent effectivement expliquer ton problème.

1) Peux-tu nous indiquer  le modèle de la carte wifi ? Dans un terminal, tu peux retrouver le modèle exact avec la commande lspci ou lsusb, selon la manière dont elle est branchée :
https://doc.ubuntu-fr.org/terminal

2) En admettant que la carte wifi soit suspecte, il serait intéressant de voir si le module incriminé dans ton lien est effectivement chargé. Pour cela, reporte-nous le résultat des commandes : /sbin/iwlist et lspci

Note importante : sous linux, les commandes sont documentées. Si tu te demandes à quoi sert la commande lsusb, tu peux taper dans un terminal man lsusb. Les noms sont aussi construit de manière logique (le préfixe ls signifie "list"). C'est l'occasion de comprendre notamment les commandes suggérées dans ton lien.

Pré-requis techniques

Tout d'abord, quelques pré-requis. Sous linux, le matériel est géré par le noyau (kernel en anglais). Il remplace donc la notion de pilote (driver) que l'on connaît de windows. Ce noyau est complété, au démarrage du système, par des "morceaux de noyaux" chargés dynamiquement, appelés modules.

Un module permet ainsi de ne pas charger la gestion de tous le matériel de l'univers et de ne charger que les fragments nécessaires à la prise en charge de ton matériel. C'est la raison pour laquelle une large partie du matériel est gérée par des modules, au lieu d'être gérée directement par le noyau.

Plus concrètement les modules sont les fichiers .ko (kernel object) stockés dans /lib/modules/<version du noyau> (la version du noyau étant le résultat de la commande uname -r).

Les noyaux récents déterminent automatiquement, à partir du matériel découvert, quels modules sont nécessaires. Le problème c'est que si le noyau plante (ou un module) cela peut geler la machine. Les symptômes que tu décrives correspondent donc à ce genre de situation.

Dans le cas particulier des cartes wifi, une partie du pilote reste propriétaire. Ce petit bloc de code est appelé firmware. Celui-ci est implicitement chargé par le module correspondant.

Les modules se gèrent avec les commandes ayant pour suffixe "mod" :
- lsmod : lister les modules actuellement chargés
- insmod : insère un module en précisant le chemin du fichier ko (jamais utilisé en pratique, au profit de modprobe)
- modprobe : charge (décharge avec l'option -r) un module à partir du nom du module (son emplacement est automatiquement retrouvé)
- rmmod : ("signifie remove module") décharge un module.

Les chargements/déchagement de modules sont enregistrés dans un fichier de logs (qui sont tous dans /var/log) : notamment /var/log/messages, /var/log/syslog et /var/log/dmesg. Il serait intéressant de regarder dans ces fichiers aux heures des freezes si on n'a pas une information permettant de déterminer le coupable.

Bien entendu, tout ce qui est expliqué ici concerne l'administration de la machine. Il faut donc des droits administrateurs (appelé "root") pour lancer avec succès ces commandes ou examiner ces fichiers. Sous ubuntu, c'est réalisé au travers de sudo pour une commande en mode texte, et au travers de gksudo pour les applications graphique (kdesudo si tu es sous kubuntu, où plus généralement, sous KDE) .

Explication de ton lien :

La solution préconisée est :

sudo modprobe -rf rt2860stasudo modprobe rt2860staecho blacklist rt2800pci | sudo tee -a /etc/modprobe.d/blacklist.conf

La première commande décharge le module rt2860sta, qui est donc le module suspecté. 
Je pense d'ailleurs que c'est plutôt, vu la suite sudo modprobe -rf rt2800pci que l'auteur voulait écrire (tu vas comprendre pourquoi).

Bien entendu, si ce module est chargé automatiquement, c'est vraisemblablement que le PC contient une carte wifi realtek nécessitant ce module. Ce n'est bien entendu pas forcément ton cas, et donc pas forcément ce module particulier qui te concerne... d'où mes questions en première partie de message. Il faut bien entendu que ce module soit actuellement chargé pour qu'il y ait lieu de le décharger (voir lsmod).

La deuxième commande charge le module rt2860sta, a priori le "bon" driver. C'est un peu contradictoire avec la première commande (qui à mon avis est plutôt sudo modprobe -rf rt2800pci).

La troisième commande met sur une liste noire (= interdit) le module rt2800pci en l'ajoutant au fichier adéquat (/etc/modprobe.d/blacklist.conf). Sous linux toute la configuration est dans /etc, donc jusqu'ici tout est normal. /etc contient (en gros) un dossier par application.

C'est très logique de configurer modprobe puisque comme expliqué dans les pré-requis, le chargement des modules est fait automatiquement. Ainsi on peut parfois vouloir aller à l'encontre de la décision prise par le noyau (soit en lui interdisant certains modules "foireux" comme ici, soit en précisant les options à passer à ces modules). Ainsi, au prochain redémarrage, le module incriminé ne sera plus chargé par le noyau.

Bonne chance

darkazeron · Answer

Bonjour,

Après m'être renseigné sur la signification de cette ligne j'ai effectué la commande systemctl dans le retour j'y ai localisé : 
● systemd-modules-load.service loaded failed failed    Load Kernel Modules. 

Pour plus de précision j'ai tapé :
systemctl status systemd-modules-load.service -l.

Retour de systemctl status systemd-modules-load.service -l :
augrain@msi-GS60-2PE:~$ systemctl status systemd-modules-load.service -l● systemd-modules-load.service - Load Kernel Modules   Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static; vendor preset: enabled)   Active: failed (Result: exit-code) since mar. 2015-12-29 12:42:19 CET; 2h 0min ago     Docs: man:systemd-modules-load.service(8)           man:modules-load.d(5)  Process: 825 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE) Main PID: 825 (code=exited, status=1/FAILURE)déc. 29 12:42:19 msi-GS60-2PE systemd[1]: Starting Load Kernel Modules...déc. 29 12:42:19 msi-GS60-2PE systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILUREdéc. 29 12:42:19 msi-GS60-2PE systemd[1]: Failed to start Load Kernel Modules.déc. 29 12:42:19 msi-GS60-2PE systemd[1]: systemd-modules-load.service: Unit entered failed state.déc. 29 12:42:19 msi-GS60-2PE systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
Si cela peut aider ...

Cordialement,

Vincent.

mamiemando · Answer

Bonjour,

Ta carte wifi est une carte intel (prise en charge par le module iwlwifi). Pour avoir beaucoup de PC équipés de carte wifi intel, je pense sans trop me tromper pouvoir te dire que ça ne vient pas de ce module, qui marche bien en temps normal.

rfkill n'a rien à voir avec un modèle spécifique de carte wifi. C'est un outil classique qui permet d'activer ou de désactiver le wifi au niveau du système d'exploitation.
https://linux.die.net/man/1/rfkill

L'absence de /var/log/messages me parait très étonnante (vérifie à tout hasard ?) car c'est vraiment standard. Vérifie aussi que le paquet rsyslog est installé (sudo apt-get update && sudo apt-get install rsyslog)

Il est par contre étrange que certains modules aient du mal à se charger.Surtout si tu n'as rien installé manuellement (est-ce bien le cas ?). Il serait intéressant de dérouler cette piste conformément à ce qui est expliqué ici :
https://wiki.archlinux.org/index.php/Systemd#Troubleshooting

Le lien est en anglais donc si tu as des difficultés à le suivre, n'hésite pas à demander des précisions ou des clarifications.

Quoi qu'il en soit, un module est suspect (a priori, autre que celui qui gère ta carte wifi) et c'est peut-être lui la source du problème. 

Bonne chance

darkazeron · Answer

Bonsoir,

En approfondissant ton lien je suis arrivé à ce point :
En exécutant la commande journalctl _PID=[le pid interessant] je suis arrivé au résultat suivant :

Retour de journalctl _PID=828 :
augrain@msi-GS60-2PE:~$ journalctl _PID=828-- Logs begin at mar. 2015-12-29 20:12:06 CET, end at mar. 2015-12-29 22:11:15 CET. --déc. 29 20:12:09 msi-GS60-2PE systemd-modules-load[828]: Failed to find module 'apm power_off=1'

En ce qui concerne le reste de manipulations je ne peux pas les effectuer car je ne possède pas le reste des fichiers demandés : 

Dans le lien :
4. We see that some of the kernel module configs have wrong settings. Therefore we have a look at these settings in /etc/modules-load.d/:$ ls -Al /etc/modules-load.d/...-rw-r--r--   1 root root    79  1. Dez 2012  blacklist.conf-rw-r--r--   1 root root     1  2. Mär 14:30 encrypt.conf-rw-r--r--   1 root root     3  5. Dez 2012  printing.conf-rw-r--r--   1 root root     6 14. Jul 11:01 realtek.conf-rw-r--r--   1 root root    65  2. Jun 23:01 virtualbox.conf...5. The Failed to find module 'blacklist usblp' error message might be related to a wrong setting inside of blacklist.conf. Lets deactivate it with inserting a trailing # before each option we found via step 3:/etc/modules-load.d/blacklist.conf# blacklist usblp# install usblp /bin/false 
Chez moi :

   -  Contenu de /etc/modules-load.d/ :augrain@msi-GS60-2PE:/etc/modules-load.d$ ls -latotal 20drwxr-xr-x   2 root root  4096 déc.  25 21:37 .drwxr-xr-x 138 root root 12288 déc.  29 20:09 ..-rw-r--r--   1 root root   119 sept. 14 18:26 cups-filters.conflrwxrwxrwx   1 root root    10 déc.  25 19:12 modules.conf -> ../modules
   -  Contenu de cups-filters.conf :
augrain@msi-GS60-2PE:/etc/modules-load.d$ cat cups-filters.conf # Parallel printer driver modules loading for cups# LOAD_LP_MODULE was 'yes' in /etc/default/cupslpppdevparport_pc
   -  Contenu de modules.conf :
augrain@msi-GS60-2PE:/etc/modules-load.d$ cat modules.conf # /etc/modules: kernel modules to load at boot time.## This file contains the names of kernel modules that should be loaded# at boot time, one per line. Lines beginning with "#" are ignored.apm power_off=1

Mettre la ligne en commentaire ne fonctionne pas.

Pour la suite je en suis pas sur de savoir quoi faire j'ai effectué plusieurs recherches dont l'une m'a mené au non fonctionnement d'ubuntu jusqu'à peu (le sauvetage miraculeux du grub recue XD).

Aurait tu des idées de pourquoi le apm power_off=1 n'est pas chargé ?

Cordialement,

Vincent

mamiemando · Answer

Ah je n'avais pas vu le message. Il faut dire que je vois tous ceux qui ont été filtrés par le site et donc du coup ce n'est pas très lisible chez moi :-)

Aurais-tu des idées de pourquoi le apm power_off=1 n'est pas chargé ? 

Je me demande surtout ce que c'est que ce module. Il n'existe pas chez moi.

J'imagine que c'est toi qui a ajouté cette ligne dans /etc/modules.conf ? En théorie il faut aussi avoir passé au noyau l'option acpi=force apm=power_off, après avoir corrigé le menu de démarrage (grub) en conséquence et redémarré, conformément à ce qui est expliqué dans le lien suivant, l'as-tu fait ?
https://askubuntu.com/questions/162211/shutdown-does-not-depower

Mais comme tu le vois ici, apm est un module (puisqu'il est chargé avec modprobe) et tu n'as probablement pas un tel fichier ".ko" dans /lib/modules (en tout cas chez moi ça n'existe pas), d'où l'erreur.
http://www.togaware.com/linux/survivor/APM_Power.html

find /lib/module/$(uname -r) | grep "/apm.ko$"

Je pense donc que ce "tip" soit encore d'actualité pour un noyau récent (4.3.0-1 dans mon cas, conformément au résultat de uname -r).

Peux-tu nous indiquer le modèle exact de ton portable ou de ta carte mère ? À mon avis c'est plus ça le point de départ.
 
Bonne chance

mamiemando · Answer

Bonjour Vincent,

Quelques idées que l'on peut essayer d'explorer :

1) Essaye de mettre à jour ta distribution : peut-être qu'un kernel plus récent prendra mieux en charge ton matériel.

2) Es-tu parvenu à faire disparaître tes erreurs une fois les références à "apm" supprimées (options passées au kernel + modules.conf) ?

3) Si oui, est-ce que tu parviens à éteindre ton PC avec la commande sudo halt ? 

4) Si ce n'est pas le cas il faut chercher une option "magique" à passer au noyau. Apparemment, APM est la norme qui a précédé ACPI. Je chercherais donc du côté des options correspondantes à ACPI en premier lieu :
https://fr.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface
http://www.linuxpedia.fr/doku.php/materiel/acpi_apic_et_lapic

Options correspondantes : lapic/nolapic, noapic, acpi=off
https://www.kernel.org/doc/Documentation/kernel-parameters.txt

Je n'ai pas trouvé sur internet de messages de gens qui avaient ton problème avec ce modèle de portable :-(

Bonne chance

mamiemando · Answer

Bon on semble avancer :-)

Donc si ce n'est pas lié au profil utilisateur, c'est vraiment au niveau du système d'exploitation qu'il faut configurer quelque chose ou le matériel qui pose problème. Les messages les plus suspects sont :

Jan  3 17:55:13 msi-GS60-2PE kernel: [  675.904243] WARNING: CPU: 2 PID: 196 at /build/linux-cRemOf/linux-4.2.0/net/mac80211/util.c:1800 ieee80211_reconfig+0x399/0x15e0 [mac80211]()Jan  3 17:55:13 msi-GS60-2PE kernel: [  675.904244] Hardware became unavailable during restart.....Jan  3 17:57:21 msi-GS60-2PE kernel: [  804.969132] NMI watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [swapoff:2944]

Surtout le dernier message.

On tombe alors sur :
http://ubuntuforums.org/showthread.php?t=2205211

Ils parlent de problème d'alimentation (dans ton cas, ça me paraît bizarre, mais ça reste crédible) et de tenter de passer les options acpi=off noapic nolapic au noyau.

Je n'ai regardé que le premier lien par manque de temps, mais je t'invite à explorer par toi-même les autres pour explorer d'autres pistes. Je peux juste te dire à ce stade que ce n'est un problème que je n'ai jamais vu, donc je ne sais a priori pas le résoudre. Je peux juste te dire les solutions qui me paraissent ou non sensées.

Bonne chance

mamiemando · Answer

Bonjour Vincent, Pour l'erreur boot-efi.mount Visiblement ton système est uefi, donc il y effectivement une partition dédiée efi sensée être montée sous linux dans le dossier /boot/efi. Ici, le mount échoue d'où ton erreur. Il faudrait voir la table des partitions par exemple avec sudo fdisk -l. Exemple : (root@velvet) (~) # fdisk -lDisk /dev/sda: 238,5 GiB, 256060514304 bytes, 500118192 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: 87A4ABFC-5361-4921-968E-559EEAF0AFC1Device Start End Sectors Size Type/dev/sda1 2048 616447 614400 300M Windows recovery environment/dev/sda2 616448 1148927 532480 260M EFI System/dev/sda3 1148928 1411071 262144 128M Microsoft reserved/dev/sda4 1411072 467618891 466207820 222,3G Microsoft basic data/dev/sda5 467619840 468660223 1040384 508M Windows recovery environment/dev/sda6 468660224 500117503 31457280 15G Microsoft basic dataDisk /dev/sdb: 59,6 GiB, 64023257088 bytes, 125045424 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk identifier: 0x000c20abDevice Boot Start End Sectors Size Id Type/dev/sdb1 2048 7813119 7811072 3,7G 82 Linux swap / Solaris/dev/sdb2 7815166 125044735 117229570 55,9G 5 Extended/dev/sdb5 7815168 27344895 19529728 9,3G 83 Linux/dev/sdb6 27346944 125044735 97697792 46,6G 83 Linux Ici on voit que ce PC a deux disques (/dev/sda et /dev/sdb) et que la partition /dev/sda2 correspond à la partition efi. Elle est donc montée au démarrage conformément à ce qui est spécifié dans /etc/fstab : Exemple : (root@velvet) (~) # cat /etc/fstab # /etc/fstab: static file system information.## Use 'blkid' to print the universally unique identifier for a# device; this may be used with UUID= as a more robust way to name devices# that works even if disks are added and removed. See fstab(5).## / was on /dev/sdb5 during installation# /boot/efi was on /dev/sda2 during installation# /home was on /dev/sdb6 during installation# swap was on /dev/sdb1 during installation## UUID=a72ddf98-983e-4865-a8ea-81ed5f32890a / ext4 errors=remount-ro 0 1UUID=4C56-716E /boot/efi vfat defaults 0 1UUID=fff5b34c-c4c3-46a3-9dfb-a72d00c1a3c4 /home ext4 defaults 0 2UUID=8cc6f746-30f2-4f19-9472-ec901c939ff3 none swap sw 0 0proc /proc proc defaults 0 0none /sys sysfs defaults 0 0/dev/sda4 /media/windows ntfs ro,defaults 0 0 Ici on voit dans la première colonne qu'au lieu de /dev/sdb1 figure un UUID pour la ligne contenant /boot/efi. Les deux syntaxes sont fonctionnent. La syntaxe à base d'UUID est privilégiée pour éviter que le fichier ne devienne caduque si les disques sont branchées physiquement ailleurs. Pour la petite histoire l'UUID associé à une partition se retrouve dans /dev/disk/by-uuid : Exemple : (root@velvet) (~) # ls -l /dev/disk/by-uuid/total 0lrwxrwxrwx 1 root root 10 janv. 27 10:35 02D05489D05484B7 -> ../../sda1lrwxrwxrwx 1 root root 10 janv. 27 10:35 0CA062C7A062B6BC -> ../../sda4lrwxrwxrwx 1 root root 10 janv. 27 10:35 4C56-716E -> ../../sda2lrwxrwxrwx 1 root root 10 janv. 27 10:35 5C2C07942C0767FA -> ../../sda5lrwxrwxrwx 1 root root 10 janv. 27 10:35 8cc6f746-30f2-4f19-9472-ec901c939ff3 -> ../../sdb1lrwxrwxrwx 1 root root 10 janv. 27 10:35 a72ddf98-983e-4865-a8ea-81ed5f32890a -> ../../sdb5lrwxrwxrwx 1 root root 10 janv. 27 10:35 F8B6672BB666EA18 -> ../../sda6lrwxrwxrwx 1 root root 10 janv. 27 10:35 fff5b34c-c4c3-46a3-9dfb-a72d00c1a3c4 -> ../../sdb6 Essaye de voir dans quelle mesure ta partition existe toujours et si le fichier /etc/fstab est cohérent avec l'état de ton disque dur. Concernant l'erreur nvidia Je ne connais pas assez ubuntu pour dire, mais de manière générale je ne suis pas très fan des dépôts tiers (par exemple les ppa), car on est jamais vraiment sûr d'avoir un tout cohérent. De plus ça me surprend que les pilotes nvidia ne soient pas directement disponibles dans les dépôts officiels. Si c'est comme sous debian, tu devrais avoir un paquet nvidia-kernel-dkms qui s'occupe de tout installer proprement, à installer via ta logithèque ou apt. https://doc.ubuntu-fr.org/software-center Si ceux-ci ne fonctionnent pas, à la limite, il vaut mieux passer par le script d'installation nvidia, comme expliqué ici. https://forums.commentcamarche.net/forum/affich-37604206-installer-les-pilotes-nvidia-sous-linux-debian#a-installation-avec-le-script-nvidia Bonne chance

darkazeron · Answer

Bonsoir,

Bonne nouvelle j'ai réussi a résoudre mes problèmes !!!!!
Je vais vous expliquer ma démarche pour d'éventuelles personnes qui se trouverait dans cette situation.

Pour restaurer l'accès à mon pc j'ai effectué un boot sur la session de récupération de ubuntu et ai choisi le lancement d'une console en root. Par la suite j'ai fait une purge des installations nvidia : sudo apt-get purge nvidia*  sudo reboot 
Lors du redémarrage le système n'ayant plus de pilote nvidia il va charger le pilote xorg nouveau par defaut. J'ai donc pu récupérer ma session.

Par la suite n'ayant mes drivers gpu mon problème était revenu à zéro. Le pc ne voulait plus ni redémarrer ni s'éteindre et restait gelé sur le fond d'écran après avoir tué tous les processus. J'ai donc installer la mise à jour du pilote nvidia : sudo apt-get install nvidia-352sudo apt-get updatesudo reboot
Une fois le pilote installer cette fois le redémarrage était possible mais toujours pas l'éteinte (bloqué sur le logo de logout).

J'ai donc effectué de nouveau l'ajout du dépôt externe : sudo add-apt-repository ppa:graphics-drivers/ppasudo apt-get update
Cette fois une mise à jour non disponible avant sur les dépôts officiels était disponible :  nvidia-361
Je l'ai donc installé avec l'outil prime (permettant de jongler entre la carte nvidia et intel):  sudo apt-get install nvidia-361 nvidia-primesudo reboot

Le problème restait le même je me suis donc pencher sur les options Acpi (Advanced Configuration and Power Interface) passée au grub car l'ancienne option apm est désormais (en tout cas pour mon noyau) obsolète. En tentant toutes les combinaisons possibles c'est finalement l'option acpi=force qui a réglé mes problèmes.

Pour ce faire j'ai édité /etc/default/grub   ->  :
sudo gedit /etc/default/grub
j'ai localisé la ligne avec GRUB_CMDLINE_LINUX_DEFAULT
pour ma part la ligne avant modification était comme ça :
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
j'y ai ajouté l'option donnée plus haut pour obtenir :
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=force"
Voilà mon pc est désormais capable de s'éteindre et de redémarrer !!
Un grand merci à mamiemando pour son aide très précieuse et je vous souhaite courage si vous vous retrouvez dans mon cas :)

Vincent

Freeze au lieu de s'éteindre / redémarrer

9 réponses

Discussions similaires

Newsletters