Je n’avais jamais rencontré ce problème :
Quand je veux hiberner mon ordibureau avec s2disk, j’ai la réponse suivante :
# /usr/sbin/s2disk
s2disk: Could not stat the resume device file. Reason: No such file or directory
uswsusp est bien installé
la swap (8 Gb) est bien présente dans fstab
s2ram fonctionne parfaitement.
De quel fichier absent parle-t-il ; resume, je n’ai jamais eu besoin de créer ce genre de fichier, où devrait-il se trouver 
Merci.
Bonjour Ricardo
je crois que le pc ne trouve pas l’image lors du resume. Peut être devrais tu ajouter dans /etc/default/grub le chemin de ta swap
ou l’UUID de la swap
Ensuite tu fais un #update-grub
L’autre option que je vois c’est de dire à s2disk où se trouve la partition swap en ligne de commande : s2ram -r /dev/sda1
En espérant que cela t’aide…
mais est-ce que le système l’utilise ?
michel@deb9550:~$ free
total used free shared buffers cached
Mem: 4060896 885436 3175460 0 145036 323440
-/+ buffers/cache: 416960 3643936
Swap: 5119996 0 5119996
michel@deb9550:~$ OK, là, je vois que ma partition de swap est active.
Mais il m’est arrivé, qu’après une installation d’une distribution de plus sur ce disque,
que le fichier swap ait été re-formaté car je n’avais pas dé-selectionné la partition de swap au moment de l’installation d’un système supplémentaire.
Du coup, elle avait été formatée par le programme d’installation, et l’UUID de la partition de swap formatée avait donc été modifié.
J’ai dû faire un :
et un :
pour me rendre compte que l’UUID de la partition de swap dans le fichier “/etc/fstab” devait être mis à jour en fonction du nouvel UUID.
Une fois le fichier “/etc/fstab” renseigné avec le bon UUID de la swap, je n’ai pas eu besoin de redémarrer le système,
je me suis juste connecté sous le compte “root” pour faire un :
pour activer et constater que le swap était pris en compte.
Vous avez raison, ce doit être une histoire de ce genre car je viens d’installer une autre “stable” sur un second DD.
je vais vérifier les UUIDs.
Je donne la réponse ensuite.
Bingo 
L’UUID avait bien été modifié.
J’ai remis la bonne dans fstab et ça devrait fonctionner.
ricardo@ordibureau:~$ sudo swapon -a && free
[sudo] password for ricardo:
total used free shared buffers cached
Mem: 8158024 2320680 5837344 0 60812 1143036
-/+ buffers/cache: 1116832 7041192
Swap: 7812092 0 7812092
[/code]
Merci, je note tout ça.
Ben fausse joie car même après un reboutage ;
ricardo@ordibureau:~$ sudo /usr/sbin/s2disk
[sudo] password for ricardo:
s2disk: Could not stat the resume device file. Reason: No such file or directory
Cet AM j’essaie de rajeunir Grub.
Content d’avoir pu t’aider. 
Le truc, c’est qu’au moment de l’installation, si l’on ne fait pas attention, toutes les partitions swap du disque cible sont formatées.
Il faut donc sélectionner chaque partition de swap pour “décocher” “formatage de cette partition” pour ne laisser formater que la swap qui nous intéresse.
EDIT: Zut, je viens de voir le dernier message qui est arrivé pendant que je rédigeais celui-ci.
Donc:
Le “swapon -a” active bien le swap => c’est OK pour le “/etc/fstab”
mais c’est pas bon pour "sudo /usr/sbin/s2disk"
Si c’est bien ça, il va falloir que je regarde du côté de ce fichier/programme/paquetage (que je n’ai pas installé…).
Une autre idée consisterait à démonter la partition de swap (swapoff) et changer l’UUID de la partition swap elle même pour lui redonner l’UUID qu’elle avait avant le formatage,
ce qui reviens à ne pas avoir modifié le “/etc/fstab”
Ou alors, je crois comprendre ce qui s’est passé:
tu as mis en veille prolongée avant d’installer une autre distribution, mais cette installation a formaté le swap qui était utilisé pour la mise en veille.
Mais lors de cette mise en veille prolongée un drapeau a été positionné dans le “/boot/grub/grub.cfg” (et peut-être aussi dans un autre fichier de l’application de mise en veille),
ce qui fait qu’à chaque redémarrage, il recherche la partition qui avait été formatée.
Comme, de toute façons, il ne retrouvera pas la partition de swap qui avait été utilisée pour la veille prolongée, je pense qu’une réinstallation de “grub” par un “update-grub” pourrait suffire,
si ça ne suffit pas, une désinstallation avec “purge des fichiers de configuration” du paquetage de l’application “s2disk” par “synaptic” ou “apt-get” suivie d’une réinstallation devrait remettre les choses en ordre.
bonjour,
le strace ne montre rien?
A+
JB1
strace ?
commande ?
swapoff
laissé dans fstab celle qui est marquée dans /dev/disk/byUUID
swapon
reboutage
essaie
NIET, toujours même message.
strace nom_exécutable sous root,
si un fichier est absent, on le voit,
sous réserve, faire touch le_nom_du_fichier puiis le bon propriétaire et droit 755
JB1
il y a aussi ldd nom_de…
tu as bien étè voir le petit cousin de debian:
doc.ubuntu-fr.org/uswsusp
j’ai pourtant beaucoup de choses chez moi mais s2disk introuvable
A+
JB1
[quote=“jb1”]tu as bien étè voir le petit cousin de debian:
doc.ubuntu-fr.org/uswsusp
j’ai pourtant beaucoup de choses chez moi mais s2disk introuvable
A+
JB1
[/quote]
Merci, je teste tout ça ce soir.
“s2disk” et “s2ram” font partie du paquet “uswsusp”.
J’aime me servir des deux: ram pour maxi 1 heure de pose et disk pour la nuit.
Même si je ne gagne pas de temps depuis le SSD, ça a l’avantage de ne pas tuer certains raccourcis pratiques, que je n’ai pas envie de décrire ici 
[quote=“ricardo”]
swapon
reboutage
NIET, toujours même message.[/quote]
Essaye plutôt :
swapon
/usr/sbin/s2disk
reboutage
essaie
Oui, ça j’avais essayé mais sans résultat.
en fait la seule chose qui soit, en partie, valable, c’est la dernière possibilité du tuto de Ubuntu :
[code]3- Vérifier le fichier uswsusp.conf
sudo gedit /etc/uswsusp.conf
Vérifier les lignes suivantes, en adaptant /dev/sda2 en fonction de ce que vous a retourné blkid pour la partition swap :
snapshot device = /dev/snapshot
resume device = /dev/sda2
4- Reconfigurer uswsusp :
sudo dpkg-reconfigure uswsusp
[/code]
L’UUiD était différente. j’ai donc revérifié la bonne avec blkid, présente aussi dans fstab et dans /dv/disk/par UUIDs, le tout concordant bien.
J’ai reconfiguré uswsusp, en laissant ce qui était proposé comme le mieux adapté.
j’ai tenté le
le résumé a bien été chargé avec les % qui défilent et la machine s’est éteinte.
Jusqu’à là : aucun problème ça fonctionne.
Je rallume, le chargement se fait correctement avec toujours les % qui défilent
MAIS
l’écran reste noir et la machine travaille en vain.
Plantage donc.
deuxième essai = idem.
Ça sent le bogue assez classique donc on va patienter et laisser ça dormir jusqu’à une MAJ réparatrice 
Abandon provisoire !
bonjour,
as-tu déjà utilisé kdump?
tu auras le nom du thread!
A+
JB1
Tu imites Gérard, tu parles par énigmes 
ricardo@ordibureau:~$ man kdump
Aucune entrée de manuel pour kdump
pour info:
google ==> kdump
ou
wiki.incloudus.com/display/DOC/Debian±+Kdump
attention c’est pour mon environnement ssd et ma version d’OS,
je viens de le mettre en oeuvre pour ma dernière debian télèchargée
A+
JB1
[quote=“jb1”]pour info:
google ==> kdump
ou
wiki.incloudus.com/display/DOC/Debian±+Kdump
attention c’est pour mon environnement ssd et ma version d’OS,
je viens de le mettre en oeuvre pour ma dernière debian télèchargée
A+
JB1[/quote]
Très intéressant !
Je garde sous le coude car j’ai beaucoup d’autres priorités actuellement.
Merci.
[quote=“ricardo”][quote=“jb1”]pour info:
google ==> kdump
ou
wiki.incloudus.com/display/DOC/Debian±+Kdump
attention c’est pour mon environnement ssd et ma version d’OS,
je viens de le mettre en oeuvre pour ma dernière debian télèchargée
A+
JB1[/quote]
Très intéressant !
Je garde sous le coude car j’ai beaucoup d’autres priorités actuellement.
Merci.[/quote]
Hello,
Je rajoute ce lien : wiki.incloudus.com/display/DOC/Kdump±+Analyse
Avoir un core c’est bien mais l’analyser c’est mieux !