web-dev-qa-db-fra.com

«Effacement des inodes orphelins» et état perdu en reprise d'hibernation

J'ai installé une nouvelle 16.04 LTS. J'ai eu quelques problèmes avec l'erreur d'affichage de l'applet Wifi (après la reprise de Suspend) et avec la reprise en veille prolongée. J'ai activé l'hibernation sur le menu en utilisant la méthode indiquée ici . Maintenant, le curriculum vitae en hibernation ne fonctionne pas par intermittence. Parfois, cela fonctionne bien, d'autres fois, il affiche un texte sur CV qui dit quelque chose sur le "nettoyage des inodes orphelins" et le système redémarre simplement, sans l'état de mémoire précédent.

Voici quelques informations:

$ Sudo blkid
/dev/sda1: LABEL="System Reserved" UUID="50921EE4921ECE7A" TYPE="ntfs" PARTUUID="dda192f8-01"
/dev/sda2: LABEL="Primary Disk" UUID="765E305F5E3019F7" TYPE="ntfs" PARTUUID="dda192f8-02"
/dev/sda3: LABEL="Secondary Disk" UUID="E2D42C6AD42C42E1" TYPE="ntfs" PARTUUID="dda192f8-03"
/dev/sda5: UUID="dbaad068-46da-4637-9c45-5c32c20d3cfe" TYPE="swsuspend" PARTUUID="dda192f8-05"
/dev/sda6: UUID="31385b29-f351-4a10-9dcf-c92efd58334b" TYPE="swap" PARTUUID="dda192f8-06"
/dev/sda7: UUID="1f734f56-7328-4029-88a0-fa995426d4d2" TYPE="ext4" PARTUUID="dda192f8-07"

$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=31385b29-f351-4a10-9dcf-c92efd58334b
16.04suspendpower-managementhibernate
2
thethakuri

Eh bien, je suis surpris que personne ne l’ait suggéré, car je suis confronté à ce problème depuis assez longtemps. La réponse semblait me regarder droit dans les yeux. Apparemment, ma partition de swap avait à peu près la même taille que ma mémoire. De plus, je n'avais pas ajouté le lien vers l'UUID de ma partition d'échange dans mon fichier grub. Après l’augmentation de la taille de la partition de swap au double de celle de la mémoire et l’ajout de son UUID dans le fichier grub, la reprise en hibernation fonctionne normalement depuis quelques jours. Bien que, le résumé de l'hibernation prenne un peu plus longtemps mais je ne me plains pas.

Vous devez vous assurer que votre partition de swap est définie dans les fichiers suivants:

  • /etc/initramfs-tools/conf.d/resume
  • /etc/default/grub

UPDATE

L'utilisation de l'interface de bas niveau uswsusp comme mécanisme d'hibernation par défaut a considérablement amélioré le temps de reprise à moins d'une minute !!!

Sudo apt-get install uswsusp

Créez le fichier /etc/pm/config.d/00sleep_module et ajoutez la ligne suivante:

  • SLEEP_MODULE="uswsusp"
0
thethakuri

Je viens juste de "corriger" EXACTEMENT le même problème, et donc fournirai ma solution ici, même si votre problème est différent.

J'ai tout d'abord parcouru les problèmes liés à by-uuid (lors de la suppression de systemd, je pensais que sysvinit pouvait gâcher l'ordre des périphériques, comme suggéré par ailleurs, et une référence uuid aurait dû résoudre le problème. C'est ce que j'ai pensé.

Cela semblait être bon pour une semaine, voire deux, puis tout a recommencé.

Après cela, je me suis souvenu de mes problèmes avec Gentoo, où je devais définir explicitement le resume=/dev/disk/by-uuid/{} dans grub.cfg, sinon il ne reprenait pas, quoi qu'il arrive. Là, ça a réglé mon problème. J'ai même installé dracut pour gérer mes initramfs. Cela a encore fonctionné pendant un certain temps, puis cela n'a pas fonctionné.

Ensuite, j'ai essayé différentes choses, telles que la rétrogradation du noyau, l'installation de bootlogd, mais rien ne suggérait rien de spécial.

À ce stade, j'ai commencé à chercher plus d'aide. J'ai saisi toutes les informations - pas tout à fait lisibles ici sur kernel.org . J'ai essayé ceci et cela, je ne me souviens plus très bien de ce que j'ai fait exactement, mais bon.

Encore une fois, cela a fonctionné parfois, mais cela n’a pas fonctionné.

C'est là que je suis devenu paranoïaque, en cherchant des modules cachés dans le noyau et en envisageant des attaques par démarrage à froid, pensant que quelqu'un avait probablement mon mot-clé BIOS, sortait de l'hibernation, réinitialisait l'ordinateur et vidait la mémoire à partir de un système d'imagerie étranger. (Veuillez noter que tout ceci n'est absolument pas tiré par les cheveux, mais, comme il s'est avéré, complètement indépendant.)

Dans cette quête - aujourd'hui soir - j'ai réussi à trouver ce site: https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues . De là, j’ai ajouté les paramètres à 2.1 initcall_debug , 2.3 ignore_loglevel , et 2.4 débogage dynamique à mon grub.cfg en tant que paramètres de démarrage du noyau.

Puis c'est arrivé, encore.

Mais maintenant j'étais plus attentif. J'ai remarqué que mon "inode orphelin" est dû à " la dernière heure d'écriture est dans le futur ". J'ai passé quelques heures à découvrir ce qui n'allait pas, environ six mois plus tôt, encore une fois en vain. J'ai juste supposé que cela était lié au manque de systemd et à mon habitude d'utiliser l'heure locale en tant que hwclock (à cause du double démarrage occasionnel avec W7), il doit donc être compris entre 6 et 10 minutes (source d'horloge imprécise) sur 2 heures maximum (je suis à l'heure GMT + 1 DST).

Bon Dieu, je me suis trompé.

Il se trouve que maintenant, avec le paramètre de noyau ignore_loglevel ajouté, le journal de démarrage contient la date EXACT à laquelle mon horloge était au moment du démarrage, ainsi que l'heure de modification.

Mon horloge a en fait été réglée sur 06 juin 2013, ce qui est probablement la date de publication du BIOS, ou quelque chose de similaire. C'est une différence de trois ans (97010350.488716 secondes) selon ntpdate).

En tant que tel, j'ai finalement compris que ma batterie CMOS est épuisée . Cela peut être un peu chargé - même s’il n’est pas rechargeable - et quand j’ai laissé l’ordinateur allumé pendant une période prolongée, il aurait pu se recharger suffisamment pour "survivre" pendant 1-2 jours - ou c’était peut-être juste la température , qui sait. (Ce n’est pas mon ordinateur principal, il s’est donc éteint plusieurs jours de suite toutes les deux semaines.)

tl; dr :

Cela dit, je vous recommande d’échanger votre batterie CMOS ou, s’il s’agit d’un ordinateur portable ou similaire,

  1. (facultatif, si vous utilisez l'installation par défaut de Xenial 16.04, vous n'en avez pas besoin) , installez et configurez bootlogd afin que vous trouviez votre journal de démarrage dans/var/log/boot. (avec systemd, il suffit d'exécuter journalctl -b pour obtenir le journal de démarrage.)

  2. Modifiez votre fichier /boot/grub/grub.cfg et ajoutez initcall_debug ignore_loglevel à la fin de la première ligne en commençant par linux /boot/vmlinuz... sous la première ligne en commençant par menuentry.

  3. Redémarrez maintenant. Ceci est très important pour pouvoir mettre en veille prolongée les nouveaux paramètres activés.

  4. Mettez Hibernate en veille, laissez la machine hors tension pendant une période assez longue, au moins plusieurs heures, puis continuez.

  5. Enfin, exécutez journalctl -b > /var/log/boot si vous ne vous êtes pas souvenu d’avoir supprimé un élément appelé systemd et/ou de l’installation de quelque chose appelé upstart, openrc ou sysvinit.

Pour toutes ces étapes, vous devez être root, il est donc conseillé de commencer par une commande Sudo -s après chaque redémarrage, puis d'installer quelque chose comme Midnight Commander (apt install mc ou Software Center) et de l'utiliser. que (mc) fonctionne avec les configs et les journaux.

Vous avez maintenant un identifiant dans /var/log/boot, dans lequel vous pouvez rechercher des événements au démarrage, tels que la cause réelle des "inodes orphelins". Si vous rencontrez des problèmes avec "l'heure de modification future", avec plusieurs heures ou plus de différence, votre batterie CMOS/RTC est définitivement vouée et doit être remplacée.

0
Victor