[Résolu]Hiberner dans un swapfile

otyugh · 16-12-2018 01:03:42

Salut,
donc. L'objectif est écrit dans le titre. Voilà ce que j'ai fait :

#le truc qui s'occupe de l'hibernation

apt install uswsusp

#Créer une swap & l'activer

sw="/swapfile"

fallocate -l "1G" "$sw"

chmod 0600 "$sw"

mkswap "$sw" &>'/dev/null'

echo "$sw none swap sw 0 0" >> '/etc/fstab'

swapon "$sw"

swoff="resume_offset=$(swap-offset $sw | cut -d' ' -f4)"

#Enable hibernation to grub

sed -i "s/^GRUB_CMDLINE_LINUX_DEFAULT=.*/GRUB_CMDLINE_LINUX_DEFAULT=\"$swoff\"/" '/etc/default/grub'

#Config hibernation

echo "resume device = /dev/sda1

compress = y

early writeout = y

image size = 200000000

shutdown method = platform

resume offset = $swoff" > '/etc/uswsusp.conf'

#Apply

update-grub

update-initramfs -u

#test

s2disk

...Ça hiberne bien (ça dit que stock des choses avant de s'éteindre) mais ça ne restaure pas la session.

Je me suis aidé du tuto suivant : https://wiki.debian.org/Hibernation/Hib … _Partition

Edit : j'ai trouvé. Fallait ajouter "resume=/dev/sda1" dans grub

Dernière modification par otyugh (16-12-2018 11:50:33)

raleur · 16-12-2018 10:14:29

L'utilisation d'un fichier de swap est un hack, et n'est pas supportée par certains systèmes de fichiers comme btrfs (excusez du peu).
C'est sale et risqué car ça court-circuite la gestion du système de fichiers pour accéder directement au périphérique, donc ne viens pas te plaindre si un jour la racine est corrompue. Tu es prévenu.

D'autre part, je répète encore une fois que l'utilisation des noms de périphériques /dev/sd* n'est pas fiable car ces noms ne sont pas persistants dès qu'il y a deux supports utilisant ce nommage. Il est recommandé d'utiliser des identifiants persistants comme les UUID. Mais voilà, le noyau ne comprend pas les UUID. En revanche il comprend les PARTUUID pour désigner le périphérique contenant la racine (root=PARTUUID=) mais je ne sais pas s'il le fait aussi pour le paramètre resume=.

otyugh · 16-12-2018 11:48:32

Mhmmm. Je vois, merci. Autant "exclusivement ext4" ça n'aurait pas été éliminatoire, mais un risque de corruption ? Zut.
C'est con avec j'y ai passé une soirée pour que ça marche et vlan "mauvaise pratique" >.<

Je pense que je vais revenir à la swap normale. ...Qui était géré par défaut par l'installateur live en plus. Fuh

EDIT : voilà le script "fonctionnel" que je n'utiliserai probablement pas.

#Add swapfile with swap-size=ram-size

if ! grep '^[^# ]*swap' '/etc/fstab' -q; then

  sw="/swapfile"

  #use dd instead of fallocate (which could have holes on ext4/XFS)

  dd if='/dev/zero' of="$sw" bs=1024 count=$(free | grep 'Mem:' | sed -r 's/^[^0-9]+([0-9,]+).*/\1/')

  chmod 0600 "$sw"

  mkswap "$sw" &>'/dev/null'

  echo "$sw none swap sw 0 0" >> '/etc/fstab'

  swoff="$(swap-offset $sw | cut -d' ' -f4)"

  swdev="$(df "$sw" | tail -n1 | cut -d' ' -f1)"

  swpartuuid="/dev/disk/by-partuuid/$(lsblk "$swdev" -o 'PARTUUID' | tail -n1)"

#Enable hibernation

  sed -ri "s|^(GRUB_CMDLINE_LINUX_DEFAULT=).*|\1\"resume=$swpartuuid resume_offset=$swoff\"|" '/etc/default/grub'

fi

#Grub's timeout

sed -ri 's/^(GRUB_TIMEOUT=).*/\12/' '/etc/default/grub'

#Fresh

update-grub

update-initramfs -u

Dernière modification par otyugh (16-12-2018 12:58:29)

raleur · 16-12-2018 13:43:05

Mon message était volontairement alarmiste car le risque existe, même s'il est faible. Un pilote de système de fichiers non partagé s'attend à être le seul maître de l'allocation et de l'accès aux blocs de données physiques. Il n'est donc pas exclu qu'il modifie l'allocation des blocs physiques d'un fichier par exemple pour défragmenter ou redimensionner, ce qui est transparent quand on accède aux fichiers de façon "normale", mais pas quand on accède directement aux blocs physiques. Certains ont eu l'idée de marquer le fichier comme "immuable" avec chattr, mais j'ai pu vérifier que cela n'empêche pas le déplacement des blocs physiques.

Le même problème est susceptible d'affecter GRUB (et LILO) lorsqu'il est installé en utilisant les listes de blocs pour charger la core image au lieu de l'embarquage. De fait, il m'est arrivé au moins une fois de devoir le réinstaller car visiblement la core image n'était pas chargée correctement, sans que j'ai rien fait de particulier avant.

Mon conseil est donc d'utiliser une partition (ou autre type de volume) dédiée pour le swap si c'est possible et de n'utiliser un fichier de swap que si on n'a pas le choix.

otyugh · 16-12-2018 19:45:34

J'avais tendance à favorise le swapfile à cause de sa flexibilité et du fait que "tu te fais pas chier, tu fais une grosse partition" était pratique pour orienter les débutants (et flexible s'il change d'avis). D'autant que Ubuntu le fait par défaut il me semble ?* (*sans garantie)

Personnellement j'utilise beaucoup "l'astuce swapfile", sans avoir vu de problème survenir. Cela dit vu que je dédiais ce script à une étape de mon installateur de debian-live pour mes futures install party... Autant être élégant - d'autant que ça m'obligeait justement à hacker l'installateur - qui par défaut veut ajouter une partition swap.

Je vais garder mon script pour le cas "s'il y a aucune swap et que le système de fichier est ext4".

raleur · 16-12-2018 22:20:19

otyugh a écrit :

D'autant que Ubuntu le fait par défaut il me semble ?* (*sans garantie)

Cela me surprendrait beaucoup.

Debian-facile

#1 16-12-2018 01:03:42

[Résolu]Hiberner dans un swapfile

#2 16-12-2018 10:14:29

Re : [Résolu]Hiberner dans un swapfile

#3 16-12-2018 11:48:32

Re : [Résolu]Hiberner dans un swapfile

#4 16-12-2018 13:43:05

Re : [Résolu]Hiberner dans un swapfile

#5 16-12-2018 19:45:34

Re : [Résolu]Hiberner dans un swapfile

#6 16-12-2018 22:20:19

Re : [Résolu]Hiberner dans un swapfile

Pied de page des forums