hibernation suite à mise à jour xubuntu

Posté par totof2000 le 09 juin 2014 à 12:56. Licence CC By‑SA.

Étiquettes : aucune

juin

2014

Bonjour.

Encore un problème récurrent lors de mises à jour Linux (xubuntu), et qui comence à me gaver sérieusement.

Je viens de faire la mise à jour vers la nouvelle XUbuntu LTS. Cependant, comme presqu'à chaque fois, l'hibernation ne fonctionne pas:
* le système ne se met pas en hibernation lorsque je ferme le portable : il se met dans un état de pseudo-veille duquel je ne peux revenir.

si je sélectionne l'hibernation en tentant une déconnection :
- j'ai une fenetre de demande d'authentification (soit disant que d'autres utilisateurs sont connectés, mais ce n'est pas le cas)
- j'obtiens un message d' "insulte" DBUS Error, et l'hibernation ne se fait pas. Le message :

Échec à la mise en hibernation de la session

GDBus.Error:org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Cependant, si je refais une tentative d'hibernation, cette fois-ci ça fonctionne (long, mais le système se met en hibernation). La fermeture du portable entraine aussi cette hibernation.

Je soupconne donc un problème de droits dans cette saleté de PolicyKit ou un truc du genre. Ce que je souhaiterais, c'est de ne pas avoir à m'authentifier lorsque je demande une mise en hibernation, ce qui règlerait probablement le problème de fermeture du couvercle.

Auriez-vous une idée ?

Merci d'avance.

Cordialement.

# Et voilà, ça commence ....

Posté par totof2000 le 09 juin 2014 à 14:02. Évalué à 1.

Cette saleté de systemd n'est pas encore intégrée à Ubuntu qu'elle me pourrit déjà la vie. Je le sentais arriver depuis un moment : j'avis déjà un problème d'hibernation sur la précédente version d'Ubuntu (mais qui ne posait pas problème lorsque je fermais le portable) Le message que j'avais :

GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files

totof@bipbip:~$ pkaction --action-id org.freedesktop.login1.hibernate
org.freedesktop.login1.hibernate
totof@bipbip:~$ pkaction --action-id org.freedesktop.login1.hibernate --verbose
org.freedesktop.login1.hibernate:
description: Hibernate the system
message: Authentication is required for hibernating the system.
vendor: The systemd Project
vendor_url: http://www.freedesktop.org/wiki/Software/systemd
icon:

implicit any: auth_admin_keep
implicit inactive: auth_admin_keep
implicit active: yes

Mes pires cauchemars se réalisent : tout ce que je préssentais est hélas en train de se produire. Je crois que je vais laisser tomber Linux et faire comme d'autres ont fait avant moi : passer à MacOSX.
- [^] # Re: Et voilà, ça commence ....
  
  Posté par claudex le 09 juin 2014 à 14:10. Évalué à 5.
  
  Mes pires cauchemars se réalisent : tout ce que je préssentais est hélas en train de se produire. Je crois que je vais laisser tomber Linux et faire comme d'autres ont fait avant moi : passer à MacOSX.
  
  C'est bien, ça nous ferra des vacances.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Et voilà, ça commence ....
    
    Posté par totof2000 le 09 juin 2014 à 14:16. Évalué à 3.
    
    Ne rêve pas: je continuerai à sévir ici. Sinon, pour en revenir au sujet, essaie de défendre sustemd et la bande à Pottering sur ce coup.
    - [^] # Re: Et voilà, ça commence ....
      
      Posté par Julien_J06 le 09 juin 2014 à 15:03. Évalué à 1.
      
      Je ne sais pas si c'est un point faible de Linux ou des distribution Debian et dérivée mais j'ai toujours eu du mal avec la mise en veille sur ma tour. Soit ça ne fonctionnait pas, soit ça fonctionnait mal.
      J'aurais, sans doute, pu trouver un contournement si j'avais eu une vrai raison d'utiliser la veille.
      Juste pour dire que la veille c'est un vrai problème sur Linux et je penses que systemd ou autre, lorsqu'on aura des pilotes fabricants corrects et intégrés comme il faut, j'ai l'impression que les problèmes de mise en veille seront moins fréquent.
      
      Julien_c'est_bien (y'a pas que Seb)
    - [^] # Re: Et voilà, ça commence ....
      
      Posté par gnumdk (site web personnel) le 10 juin 2014 à 14:44. Évalué à 2. Dernière modification le 10 juin 2014 à 14:45.
      
      C'est vrai, j'aimerai connaître le rapport entre une mise à jour qui a foiré et systemd…
      
      Ici, que ce soit Ubuntu ou Kubuntu, l'hibernation fonctionne très bien… Et ça marche aussi avec des OS 100% systemd comme arch.
      - [^] # Re: Et voilà, ça commence ....
        
        Posté par totof2000 le 11 juin 2014 à 11:10. Évalué à 1.
        
        Il suffit de lire ce que j'ai copié/collé.
    - [^] # Re: Et voilà, ça commence ....
      
      Posté par zurvan le 10 juin 2014 à 17:24. Évalué à 4.
      
      Je ne sais pas si c'est spécifiquement lié à systemd, mais je vois qu'on n'est pas si isolé que ça :
      https://fr.wikipedia.org/wiki/PolicyKit#Pol.C3.A9mique
      
      Tous ces trucs dont on ne comprend rien (en tant que simple utilisateur), avec une syntaxe affreuse (yabon l'édition des fichiers xml), et dans des chemins faciles à retrouver et à écrire, du genre /etc/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla … c'est pas la joie…
      
      « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
      - [^] # Re: Et voilà, ça commence ....
        
        Posté par totof2000 le 13 juin 2014 à 11:14. Évalué à 3.
        
        Alors entre :
        - un bout de config XML
        - un bout de config déclaratif de style
        
        [machintruc] xyz=toto.titi.tata abc=yes
        - l'arrivée de Javascript pour déclarer les règles
        - les fichiers répartis entre /etc/polkit-1, /var/polkit1 + les sous-arborescences de ces rep
        - les interactions avec dbus (qui ne sont pas simples non plus),
        
        ça devient compliqué de s'y retrouver. C'est cette horreur qu'il aurait fallu reprendre avant de s'interesser au système de démarrage de Linux : là le système se base sur un truc pourri d'avance, et ça n'aide pas.
- [^] # Re: Et voilà, ça commence ....
  
  Posté par xcomcmdr le 11 juin 2014 à 11:13. Évalué à 2.
  
  J'ai systemd sur Archlnux, sur un ASUS N56VV (UEFI), et la mise en veille/hibernation/arrêt/redémarrage/verrouillage sont OK.
  
  Quant ça ne fonctionnait pas, c'était à cause du BIOS sur mon ancienne machine (ASUS x71SL).
  
  Haters gonna hate…
  
  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Test

Posté par Olivier (site web personnel) le 09 juin 2014 à 15:46. Évalué à 5.

Tu pourrais commencer par vérifier que les mécanismes bas-niveaux d'hibernation fonctionnent.

Pour cela, lance un terminal, log-toi en root (sudo bash), et lance un :

/usr/sbin/pm-suspend pour mettre en veille
ou
/usr/sbin/pm-hibernate pour hiberner

Il y a des fichiers de logs dans /var/log/pm-*

Une fois cette partie-là validée, tu pourras regarder du coté de policikit.

Mais je suspecte que le problème vienne de XFCE : En effet, sur quelques machines que j'ai (Debian Testing) les upgrades de XFCE changent parfois les droits de l'utilisateur pour le shutdown/reboot/etc…

A noter que cela peut aussi venir du gestionnaire de session : gdm/gdm3/lightdm/slim, etc…
- [^] # Re: Test
  
  Posté par totof2000 le 09 juin 2014 à 18:43. Évalué à 2.
  
  Bonjour.
  
  Tu pourrais commencer par vérifier que les mécanismes bas-niveaux d'hibernation fonctionnent.
  
  Déjà fait, et àa fonctionne. D'ailleurs, tu remarqueras que lorsque je tente une fois la mise en hibernation via la déconnection, j'ai une demande d'authentification (parce que soit-disant il y a quelqu'un d'autre de connecté alors que ce n'est pas le cas), un message d'erreur dbus, et ensuite, comme par magie, ça fonctionne …. C'est pour ça que je soupçonnais un problème de droits via policykit, et en y réfléchissant, je suppute un problème de communication via dbus.
  
  Merci cependant pour cette suggestion.
  
  Mais je suspecte que le problème vienne de XFCE : En effet, sur quelques machines que j'ai (Debian Testing) les upgrades de XFCE changent parfois les droits de l'utilisateur pour le shutdown/reboot/etc…
  
  Ca c'est possible, cependant normalement les droits sont OK. Ce que je trouve étrange, c'est cette demande de mot de passe lorsque je mets en veille via la GUI. Il est fort probable que lorsque je ferme le portable, la machine considère que tant que je ne suis pas authentifié, je n'ai pas le droit de mettre la machine en hibernation …
# Aléatoire

Posté par AgentSteel (site web personnel) le 10 juin 2014 à 21:49. Évalué à 2.
Pour ma part :
- 1 machine (4-5 ans) sous (Gnome)buntu 14.04, cpu et gfx AMD (pilotes libres) : fonctionne au poil
- 1 machine (1 an) Debian Wheezy, 100% intel (cpu et gpu intégré, pilotes libres) : idem
- 1 machine (Zotac Nano AD10), Xubuntu 12.04 la veille n'était pas fiable. Upgradée vers la 14.04, toujours pas 100% fiable. Pilotes ati libres.
3 configs totalement différentes.

Pour résoudre ton souci, il faudrait au moins ré-essayer avec un OS fraîchement réinstallé.
- [^] # Re: Aléatoire
  
  Posté par totof2000 le 11 juin 2014 à 11:21. Évalué à 2.
  
  Je ne pense pas que ce soit utile, et surtout je n'ai pas de disque dispo pour une réinstallation complète.
  
  Sinon, après quelques recherche, je constate qu'il s'agit bien d'un problèùme de règle policykit.
  
  Sinon, j'ai fait une petite modif dans la configuration xfce4 : l'insulte dbus a disparue. Cependant, j'ai toujours une demande d'authentification lors de l'hibernation via la fenêtre de déconnection. La ou c'est intéressant, c'est que la fenêtre de demande de mot de passe me donne l'identifiant de l'action qui nécessite l'authentification : je devrais pouvoir m'en sortir avec ça.
  
  Sinon, y a-t-il un moyen de lancer le daemon polkit en debug pour pouvoir tracer les actions autorisées ou refusées par polkit ?
  - [^] # Re: Aléatoire
    
    Posté par totof2000 le 12 juin 2014 à 11:48. Évalué à 3.
    
    Problèmes résolus : je détaillerai un peu plus tard (je n'ai pas le portable à portée de main pour le moment), mais il y avait deux causes :
    - une liée à polkit, qui est une horreur à gérer (il y a des fichiers de conf un peu partout, et si on ne met pas les directives dans le bon fichier ça ne marche pas)
    - une liée à logind qui semble vouloir s'occuper de la gestion d'énergie (ce n'est pas son rôle à priori), et qui se moque totalement des directives que j'ai configurées via l'IHM.
    - [^] # Re: Aléatoire
      
      Posté par AgentSteel (site web personnel) le 12 juin 2014 à 19:10. Évalué à 1. Dernière modification le 12 juin 2014 à 19:11.
      
      Un truc à savoir :
      
      l'hibernation n'est plus automatiquement activée depuis ubuntu 14.04, selon les machines.
      (Voire même désactivée par défaut)
      
      Du coup c'est peut-être pour ça que depuis ton upgrade ça ne fonctionnait plus.
      
      https://help.ubuntu.com/community/PowerManagement/Hibernate#Hibernate_Disabled_by_Default
      
      https://help.ubuntu.com/14.04/ubuntu-help/power-hibernate.html
      - [^] # Re: Aléatoire : La solution
        
        Posté par totof2000 le 13 juin 2014 à 11:08. Évalué à 3.
        
        Ce n'est pas suffisant : j'avais fait cette manip, et ça ne fonctionnait toujours pas : voir plus bas mon explication.
        
        Voici un extrait de la manpage de logind pour les explications :
        
        http://manpages.ubuntu.com/manpages/trusty/man5/logind.conf.5.html
        
        IdleAction= Configures the action to take when the system is idle. Takes one of ignore, poweroff, reboot, halt, kexec, suspend, hibernate, hybrid-sleep, lock. Defaults to ignore. Note that this requires that user sessions correctly report the idle status to the system. The system will execute the action after all sessions reported that they are idle, and no idle inhibitor lock is active, and subsequently the time configured with IdleActionSec= (see below) has passed. [ ... ] HandlePowerKey=, HandleSuspendKey=, HandleHibernateKey=, HandleLidSwitch= Controls whether logind shall handle the system power and sleep keys and the lid switch to trigger actions such as system power-off or suspend. Can be one of ignore, poweroff, reboot, halt, kexec, suspend, hibernate, hybrid-sleep and lock. If ignore logind will never handle these keys. If lock all running sessions will be screen locked. Otherwise the specified action will be taken in the respective event. Only input devices with the power-switch udev tag will be watched for key/lid switch events. HandlePowerKey= defaults to poweroff. HandleSuspendKey= and HandleLidSwitch= default to suspend. HandleHibernateKey= defaults to hibernate.
        
        Il faut donc éditer dans /etc (ou le sous répertoire logind de /etc, je ne me rappelle plus) le fichier logind.conf, décommenter la ligne HandleLidSwitch=suspend (me semble-t-il, ou autre chose …) et remplacer suspend(ou autre chose) par hibernate pour obtenir :
        
        HandleLidSwitch=hibernate
        
        Pour polkit et l'hibernation depuis le menu de déconnection : il y a eu modification de comportement depuis la mise à jour : autrefois, le mot de passe n'était demandé uniquement lorsque d'autres utilisateurs étaient connectés. Maintenant, le mot de passe est demandé même s'il n'y a pas d'autres utilisateurs connectés.
        
        Deux possibilités :
        - soit une nouvelle règle polkit a été ajoutée
        - soit un bug : le système croit qu'il y a d'autres utilisateurs de connectés alors que ce n'est pas le cas ( personnellement, j'ai de gros soupçons envers logind ). J'ai du modifier la conf de polkit pour que le mot de passe ne soit pas demandé. Par contre dans un premier temps je n'avais pas placé mon fichier au bon endroit donc ma modif n'était pas pris en compte.
        
        Ce changement de comportement m'a quelque peu induit en erreur sur la cause initiale du problème. Je n'ai pas essayé de supprimer la règle polkit que j'ai modifiée suite à cette modification de comportement. Il est possible, voire fort probable que la mise en hibernation se fasse en fermant le portable sans cette règle. Je testerai ce week-end (là pour le moment, ça fonctionne, et je n'ai pas envie de passer des heures à tout reconfigurer).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.