Uswsusp: raccourcis sur bureau?

Support Debian
#21

En fait, le chemin complet ne peut fonctionner que sous root puisque le fichier /usr/sbin/s2disk, appartient à root.
Donc, si chemin complet : root (ou sudo)
si KDE clic direct menu/quitter/hiberner, user suffit.
idem pour les raccourcis.

#22

Cette information ne suffit pas…

  1. A quel groupe appartient le fichier ?
  2. Ce groupe a-t-il les droits d’exécution ?
  3. Le programme qui souhaite exécuter “/usr/sbin/s2disk” fait-il partie du groupe ?
  4. Est-ce que “other” peut exécuter le fichier ?
  5. Le fichier possède-t-il le droit SGID ?

C’est seulement en ayant répondu à ces questions qu’on sera en mesure de dire si “/usr/sbin/s2disk” peut être exécuté par quelqu’un d’autre que root ou non.

#23

t’a essayé en désactivant le splash dans le fichier de conf comme je te proposais un peu plus haut ?
Comme il à l’air de planter juste après la tentative de détection du splash system…

#24

Bon ben j’ai essayé et j’ai exactement le même problème que laso6… J’ai essayé de mettre les droits “rwx” de “other” pour le fichier “/dev/mem” mais ça ne change rien au problème.

#25

@ricardo: désolé je suis sous gnome.
@cluxter: je me sens moins seul.
@dric64: apparemment je n’ai pas de splash. Quand j’hiberne (méthode console graphique normale), je n’en vois pas, c’est à dire que j’ai vue directe sur la console si je comprends bien ce qu’il se passe dans cette bécane qu’on appelle un ordi pour collégien. Néanmoins, la non-détection d’un splash avant l’hibernation, ne pose aucun problème à ‘sudo s2disk’ lorsque je le lance dans un terminal. Je pense pas que ça joue, mais si tu insistes, je veux bien faire la modif suggérée plus haut.

Pour rappeler où nous en sommes:

  1. Je réussis, en console, à mettre en veille (gros progrès) et à hiberner (autre gros progrès), après avoir installé le paquet ‘uswsusp’ (et pas le paquet ‘splashy’ comme suggéré).
  2. J’ai suivi la doc-ubuntu sur le lien présent dans mon dernier post (plus haut).
  3. En console graphique, je tape
sudo s2ram -fa 3

etsudo s2disk
pour mettre en veille et hiberner, respectivement. Cela fonctionne très bien.
4. En essayant de me fabriquer deux lanceurs sur le bureau (gnome), je découvre que le lanceur de mise en veille marche nickel et que le lanceur d’hibernation ne marche pas du tout.
5. J’ai le sentiment d’avoir mis le doigt sur un c** de problème à la c**. :114

#26

Histoire de faire quelque chose, j’ai essayé de créer des lanceurs dans le tableau de bord et pas sur le bureau, pour voir s’il ya une différence de comportement: aucune. Le lanceur s2ram fonctionne, pas le lanceur s2disk.

#27

Je n’insiste pas, c’est comme tu veux, je te propose juste une piste facile à tester. Je suis d’accord que le splash n’a pas de raison de poser problème (puisqu’il fonctionne en mode terminal), pas plus que le lanceur ne devrait poser de problème puisqu’il ne fait ni plus ni moins que ce que fait une commande dans un terminal, et pourtant…

#28

Eh bien non. J’ai été modifier le fichier de configuration.
Je suis allé en console graphique pour lancer les commandes. J’ai pu vérifier qu’uswsusp ne cherche plus de splash, il hiberne plus vite, mais en revanche cela n’a rien changé au problème.
Mon problème de lanceur = ton problème d’emmental, je crois.

#29

En essayant de l’installer sur ma debian, aptlistbug m’a reporté 5 bugs non corrigés sur ce paquet, dont celui-ci (ouvert depuis 2009 !):

bugs.debian.org/cgi-bin/bugreport.cgi?bug=521147

qui semble correspondre à ton problème (problème qui semble ne pas exister avec ce même paquet sur un noyau 2.6.26). C’est peut être toi qui a ouvert ce rapport d’incident ?

#30

non, niet, nein, no, pas du tout, ce n’est pas moi, qui viens juste de me mettre à Linux.
Ce rapport d’incident, je dirais qu’il décrit plus ou moins pas ce dont il s’agit ici. Mais il est révélateur des bugs qui trainent dans uswsusp, à mon avis, comme le confirme ton aptlistbug (que je ne connais pas, je vais me renseigner, ça a l’air utile).

Néanmoins:

  1. uswsusp me rend bien service, puis que mon ubuntu lucid est incapable de mettre en veille mon ordi, ni de le faire hiberner.
  2. le schmilblick du lanceur qui marchait et de l’autre lanceur qui ne marchait pas, ne dépend peut-être pas d’uswsusp?
#31

Je les trouve tres semblables, pour ma part.

#32

Pour information, informations sur le noyau, le système:

so6@so6-laptop:~$ uname -a Linux so6-laptop 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:26:08 UTC 2010 i686 GNU/Linux

#33

Bonjour laso6,

as-tu le même comportement que celui décrit
en utilisant les commandes pm-suspend et pm-hibernate ?

#34

@dric64: oui, en relisant bien, je te donne raison, ça ressemble. A ceci près que:

  1. moi ça ne bugue pas, ni en console, ni en terminal graphique! ça bugue avec ce ?!§§£$µ’@’ de lanceur à la c**.
  2. Contrairement à ce que disait mon post #1, je ne suis pas obligé d’éteindre brutalement. Ctrl+Alt+F8 me ramène au bureau.

@BBT1: Bonjour. Chez moi, en commande graphique, la commande ‘sudo pm-suspend’ m’envoie directement dans le bugue complet: écran noir, curseur fixe, clavier mort, aucun retour possible, extinction brutale nécessaire.
Mais je ne sais pas si je réponds à ta question.

#35

Mmm si ça aide à cerner le problème…
Tu as quoi comme carte graphique ? Tu utilises quel pilote ?

#36

Voici:

so6@so6-laptop:~$ lspci | grep VGA 01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266]

Plus de détails ici, peut-être:

01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] Subsystem: Packard Bell B.V. Device e004 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (1000ns min, 63750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 10 Region 0: Memory at e0000000 (32-bit, non-prefetchable) [size=512K] Region 1: Memory at 90000000 (32-bit, prefetchable) [size=128M] Expansion ROM at 98000000 [disabled] [size=64K] Capabilities: <access denied> Kernel modules: savagefb

#37

Ah… j’avais eu des problèmes au début avec la mise en veille avec les pilotes radeon des cartes ATI,
mais là ça n’a pas l’air d’être le cas.

#38

[quote=“BBT1”]Ah… j’avais eu des problèmes au début avec la mise en veille avec les pilotes radeon des cartes ATI,
mais là ça n’a pas l’air d’être le cas.[/quote]
Je confirme que ce n’est pas ça puisque j’ai une carte graphique Intel intégrée.

#39

Peut-être que le problème viens de la nouvelle gestion du frame buffer ?
Le problème est toujours là avec un vieu noyau (faudrait rechercher à partir
de quelle version la gestion du framebuffer a été assignée au noyau)