Gave up waiting for suspend/resume device

Support Debian
,
Tags: #<Tag:0x00007f63f60973b8> #<Tag:0x00007f63f6097200>
#1

Bonjour,

Suite à un manque d’espace j’ai repartitionné le disque /dev/sda sur lequel j’ai les partitions /var /home et swap. J’en ai profité pour passer à LVM.
Je n’ai pas touché à l’autre disque (/dev/sdb).

Depuis, j’ai ce message d’erreur au boot.

Les conseils donnés dans ce post Gave up waiting for suspend/resume device sont prometteurs. Moi aussi j’avais oublié de reconstruire initramfs.

Cela n’a rien changé et je ne sais plus qu’essayer.
Voici quelques informations.

blkid

/dev/sdb1: UUID="6E89-F272" TYPE="vfat" PARTUUID="0cc4122a-e890-4bdd-b0d6-5e6e7b65fb25"
/dev/sdb2: UUID="5b4fa555-15be-45c1-ab6b-1175c4935bc4" TYPE="ext4" PARTUUID="69657af1-2ca6-4743-9452-680b87882f47"
/dev/sda: UUID="ogA1I6-fF0M-3L0o-lk4R-vMKh-SWki-uWzKpW" TYPE="LVM2_member"
/dev/mapper/vg_debian-lv_swap: UUID="39d284c4-6ae3-47ef-be7d-4cf2d83ae6d1" TYPE="swap"
/dev/mapper/vg_debian-lv_var: UUID="269b467f-bb10-4490-aedf-5f1a34fd0ac6" TYPE="ext4"
/dev/mapper/vg_debian-lv_home: UUID="16f226aa-3d12-4203-931f-d6a9ef5594b5" TYPE="ext4"

/etc/fstab

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

# / was on /dev/sdb2 during installation
UUID=5b4fa555-15be-45c1-ab6b-1175c4935bc4 /               ext4    errors=remount-ro 0       1

# /boot/efi was on /dev/sdb1 during installation
UUID=6E89-F272  /boot/efi       vfat    umask=0077      0       1

# /home
UUID=16f226aa-3d12-4203-931f-d6a9ef5594b5 /home           ext4    defaults        0       2

# /var
UUID=269b467f-bb10-4490-aedf-5f1a34fd0ac6 /var            ext4    defaults        0       2

# swap
UUID=39d284c4-6ae3-47ef-be7d-4cf2d83ae6d1 none            swap    sw              0       0

Et puis j’ai suivi les conseils du post cité plus haut. J’ai corrigé le fichier « resume » parcequ’il contenait l’UUID de l’ancienne partition swap.

# cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=39d284c4-6ae3-47ef-be7d-4cf2d83ae6d1

# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.19.0-12-amd64

# grub-install
Installation pour la plate-forme x86_64-efi.
Installation terminée, sans erreur
#2

Suggestion : remplacer les notations UUID=xxx dans fstab et resume par les noms de périphériques des volumes logiques /dev/mapper/vg_debian-lv_* qui sont stables, contrairement aux noms de périphériques des disques et partitions /dev/sd*, et plus lisibles que les UUID. D’autre part ça peut aider l’initramfs à comprendre qu’il doit utiliser les volumes logiques.

Edit : Je viens de tester et apparemment c’est indispensable dans resume pour que l’initramfs active le volume logique du swap.

Sinon, si RESUME n’est pas défini alors update-initramfs va utiliser automatiquement le swap actif.

#3

Super. J’ai utilisé le path à la place de l’UUID dans la config de mkinitramfs :

> cat /etc/initramfs-tools/conf.d/resume
RESUME=/dev/mapper/vg_debian-lv_swap

Puis reconstruit initramfs et réinstallé grub.
Et ça marche.
Merci mille fois pour votre aide.

Ça doit être un bug. J’en ai trouvé un qui me semble identique: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883735
À ce que je comprends, je devrais avoir la correction mais ce n’est visiblement pas le cas.

#4

Non, c’est un bug différent. Le bug #883735 concernait uniquement la détection automatique du swap lorsqu’il n’était pas défini explicitement par RESUME (absente ou vide), et a bien été corrigé dans buster. Mais le problème de fond, qui est par conception, demeure, comme expliqué par le mainteneur :

This is the correct way to refer to LVs used as root, /usr or resume partition. The reason for this is that lvm2 only activates VGs that are definitely needed, and there is no way to determine whether a filesystem UUID or label refers to an LV (or which VG it’s in).

En clair, l’initramfs n’active pas tous les volumes logiques. Au lieu de cela, il active seulement ceux dont il a besoin (resume, racine, /usr…) à condition qu’ils aient été déclarés sous leur forme /dev/mapper/vg-lv pour être identifiables en tant que volumes logiques, et non avec leur UUID qui n’est pas visible tant que le volume logique n’est pas activé.

EDIT
Par curiosité, j’ai voulu savoir ce que ça donnait avec une configuration un peu plus compliquée comme la racine ou le swap dans un volume logique A dans un volume chiffré dans un volume logique B, soit un sandwich LVM-LUKS-LVM [1].

Le fichier /etc/crypttab généré par l’installateur identifie le volume logique B par l’UUID LUKS et non par son chemin de volume logique /dev/mapper/… Le chemin du volume logique B n’apparaît donc dans aucun fichier de configuration (fstab, crypttab, resume). Mais update-initramfs est malin : il convertit l’UUID dans crypttab en chemin de volume logique dans le fichier cryptroot inclus dans l’initramfs, ce qui semble permettre à l’initramfs d’activer le volume logique B avant d’ouvrir le volume chiffré.

Du coup je me dis qu’update-initramfs aurait pu faire la même chose avec l’UUID du swap dans le fichier resume…

[1] Si vous vous demandez à quoi ça peut servir, ça permet d’avoir un groupe de volumes LVM chiffré sur de multiples partitions ou disques mais dans un volume chiffré unique, donc une seule passphrase à gérer.

1 J'aime