« Je pensais que 4 Go de swap suffisaient largement » : pourquoi votre session disparaît à chaque sortie d’hibernation

Votre session disparaît après une hibernation parce que le noyau Linux a besoin d’écrire l’intégralité du contenu de la RAM sur le disque avant de couper l’alimentation, et que 4 Go de swap ne suffisent tout simplement plus dès que votre machine embarque 8, 16 ou 32 Go de mémoire. Le système commence à copier l’image mémoire, arrive au bout de l’espace disponible, et abandonne en silence ou redémarre à froid. Résultat : vous perdez vos onglets, vos documents non enregistrés et parfois carrément votre session graphique.

Le calcul que (presque) personne ne fait avant d’installer sa distro

La règle technique est restée stable depuis des années et elle n’a rien de mystérieux : pour hiberner correctement, l’espace de swap doit être au moins équivalent à la quantité de RAM installée. La fonction d’hibernation (suspend-to-disk) écrit le contenu de la RAM sur la partition de swap avant d’éteindre la machine, donc la partition de swap doit être au moins aussi grande que la taille de la RAM. Le wiki communautaire d’Ubuntu propose même un barème détaillé selon la mémoire installée, et les chiffres donnent le vertige comparés à l’époque où 4 Go semblaient un luxe : pour 16 Go de RAM avec hibernation activée, le tableau recommande 16Go de swap, et pour 32 Go de RAM, on grimpe à 32 Go de swap recommandés.

Le détail technique est encore plus précis côté noyau. Un développeur du kernel expliquait sur la mailing-list linux-kernel que pour hiberner, il faut grosso modo un espace de swap équivalent à la taille de la RAM moins la taille des fichiers mappés en mémoire, et que, par prudence, le volume total de swap dédié à l’hibernation doit correspondre à la taille de la RAM, même si dans la pratique il peut être un peu inférieur. : vos 4 Go de swap, hérités d’une époque où la RAM plafonnait à 4 ou 8 Go, sont devenus une antiquité incompatible avec votre machine actuelle. Le système ne plante pas par bug exotique, il manque juste littéralement de place pour stocker votre travail en cours.

Le piège invisible des distributions modernes qui n’ont même plus de vrai swap

Il y a pire que le swap trop petit : l’absence pure et simple de swap sur disque. Depuis plusieurs versions, Fedora installe par défaut un swap compressé directement en mémoire, le zram, plutôt qu’une partition classique. Or le zram ne peut pas être utilisé pour l’hibernation puisqu’il repose sur de la RAM volatile, il faut donc créer une partition de swap traditionnelle. Sans cette étape, votre « hibernation » plante silencieusement ou ne se déclenche jamais vraiment.

Le blog officiel du projet Fedora est d’ailleurs limpide sur le sujet : les installations Fedora n’utilisent par défaut ni un périphérique swap classique ni un fichier swap. Un périphérique zram est créé à la place, une zone de swap compressée en mémoire. Elle n’est pas adaptée à l’hibernation, ce qui signifie que l’hibernation ne fonctionne pas immédiatement sur Fedora Linux. Bonne nouvelle tout de même : quand un vrai swap coexiste avec le zram, le système sait faire le tri. Comme le swap-on-zram reste activé par défaut, deux swaps coexistent, le zram ayant une priorité plus élevée, mais le noyau est assez intelligent pour savoir qu’il ne peut pas hiberner vers un périphérique zram et utilisera à la place le swap sur disque. Encore faut-il que ce dernier existe, et qu’il soit assez grand.

Ces erreurs sournoises qui trahissent une hibernation ratée

Le symptôme le plus frustrant, ce n’est pas toujours un message d’erreur clair, c’est le crash silencieux au réveil. Un vieux rapport de bug du noyau documente exactement ce cas : après un bricolage pour forcer l’hibernation malgré un swap limite, l’utilisateur constate qu’il peut hiberner et reprendre la machine, mais que ce n’est pas fiable, car sa session de bureau meurt de façon violente, avec des messages de segfault en cascade dans les logs noyau. C’est exactement ce phénomène qui se cache derrière votre « session qui disparaît » : le noyau a réussi à écrire une partie de l’image mémoire, mais pas la totalité, et ce qui revient au réveil est une reconstruction corrompue.

Autre piège moins connu : même avec un swap suffisamment grand, son emplacement compte. Sur les systèmes utilisant systemd, un fichier swap placé dans /home pose problème car systemd-logind ne pourra pas déterminer sa taille et empêchera donc l’hibernation. Sur des installations récentes, l’échec se manifeste parfois de façon plus explicite, avec un message d’erreur direct lors de la commande d’hibernation signalant qu’il n’y a pas assez d’espace swap adapté disponible pour l’hibernation plutôt qu’un simple plantage muet.

Ce qu’il faut réellement faire pour que ça ne se reproduise plus

La correction n’a rien de sorcier, mais elle demande un peu de rigueur. Trois points à vérifier dans l’ordre : la taille du swap doit au minimum égaler votre RAM totale, l’emplacement du fichier swap ne doit pas se trouver dans /home, et le paramètre noyau resume= doit pointer vers le bon périphérique ou fichier pour que le processus de démarrage sache où aller chercher l’image sauvegardée.

Un détail rassurant pour ceux qui hésitent à sacrifier des dizaines de gigaoctets de disque : la vieille règle du swap égal à 1,5 ou 2 fois la RAM, héritée des années 2000, n’a plus vraiment de sens pour un usage courant sans hibernation. La règle du 1,5 fois la RAM a plus de quinze ans et n’a plus lieu d’être, sous Linux comme sous Windows. Elle ne redevient pertinente que si vous comptez précisément sur l’hibernation, auquel cas la contrainte « swap au moins égal à la RAM » reste, elle, bien réelle et non négociable. Sur un portable avec 32 Go de RAM et un SSD confortable, prévoir un fichier swap de 32 Go dédié exclusivement au réveil n’a rien d’excessif : c’est le prix à payer pour retrouver ses fenêtres exactement où on les a laissées.

Sources : forum.ubuntu-fr.org | forum.ubuntu-fr.org