Boot buster lvm chiffré cassé

Support Debian
, , ,
Tags: #<Tag:0x00007f509fc5fe80> #<Tag:0x00007f509fc5fc28> #<Tag:0x00007f509fc5f9d0> #<Tag:0x00007f509fc5f890>
#1

Bonjour,

J’ai une machine en buster qui, lors d’une mise à jour, semble avoir perdu des bouts du grub/efi et ne démarre plus.

Elle avait été installée avec une configuration standard utilisant lvm + chiffrement avec un /boot (ext2) et un /boot/efi (vfat) non chiffrés.

Le reste du système (/ et swap) est dans un lvm contenu dans un crypto_luks.

Au boot, j’ai les messages ‘Volume group “pc” not found’ et ‘Cannot process volume group pc’ qui se répètent (normalement ils ne s’affichent que deux fois), la passphrase du volume chiffré ne m’est jamais demandée et il finit par afficher ‘Gave up waiting for suspend/resume device’ avant de tomber sur un busybox.

Les volumes /boot et / ont l’air OK, en bootant sur un liveusb je peux accéder au volume chiffré normalement et le /boot a l’air complet (System.map, config, initrd.img et vmlinuz pour les deux derniers noyaux). /boot/grub a l’air OK aussi, par contre /boot/efi semble cassé. Dans /boot/efi/EFI/debian/ je n’ai que grubx64.efi, il manque BOOTX64.CSV fbx64.efi grub.cfg mmx64.efi et shimx64.efi.

J’ai trouvé un article qui semble donner une solution au problème que je rencontre : Fixing Debian UEFI boot manager with Debian Live mais il date un peu (2017). Si je ne me trompe pas, les images DVD de Buster intègrent l’UEFI, donc l’étape 3 devrait pouvoir être évitée.

Est-ce que j’ai bien compris le problème ? Est-ce que c’est la bonne solution à appliquer ou est-ce que je risque de casser le système encore plus ?

Merci.

#2

Ces fichiers ne sont présents qu’avec la variante signée de GRUB. Si le secure boot n’est pas activé, ils ne servent à rien. D’ailleurs GRUB démarre et le noyau démarre, donc pas de souci.

C’est donc probablement que l’initramfs ne contient plus ce qu’il faut pour ouvrir un volume chiffré.
Depuis le système live, fais un chroot sur la racine du système, monte la partition /boot, puis

lsinitramfs /boot/initrd.img-<version_du noyau> | grep crypt

Si cryptsetup est inclus, ça devrait afficher autre chose que des modules du noyau *.ko.
Sinon, vérifie que les paquets cryptsetup-run, cryptsetup-bin et cryptsetup-initramfs sont bien installés.
Sinon, après les avoir installés,

update-initramfs -u -k <version_du noyau>

et vérifier à nouveau le contenu de l’initramfs.

Note : pour que la construction de l’initramfs se passe bien il vaut mieux que le volume chiffré soit ouvert avec le même nom que celui défini dans /etc/crypttab.

1 J'aime
#3

Bonjour,
Ça m’arrive souvent. En général ça ne bloque pas le démarrage.
Il y plein de posts à ce sujet… Regardez ici, si ça peut aider !

#4

Bonjour Pascal,

Merci infiniment ! Il fallait bien faire un update-initramfs tel que suggéré. Les paquets cryptsetup-* étaient pourtant bien installés mais l’initramfs devait être corrompue.

Pour mémoire, si ce sujet devait servir d’exemple pour quelqu’un d’autre, voici les opérations faites pour résoudre le problème.

J’ai booté sur un liveusb (ubuntu 17.10 en l’occurence, c’est ce que j’avais sous la main et de mémoire les liveusb debian ne gèrent pas de manière aussi transparente les volumes lvm, même si ça se fait aussi).

J’ai ouvert le volume chiffré :

cryptsetup luksOpen /dev/mapper/nvme0n1p3 nvme0n1p3_crypt

le nom utilisé étant celui présent dans le /etc/crypttab.

J’ai monté l’arborescence des filesystems, y compris des bind mounts de proc, sys et dev :

mount /dev/mapper/ws--vg-lv-root /mnt/ws
mount /dev/nvme0n1p2 /mnt/ws/boot
mount /dev/nvme0n1p1 /mnt/ws/boot/efi
mount --bind /proc /mnt/ws/proc
mount --bind /dev /mnt/ws/dev
mount --bind /sys /mnt/ws/sys
chroot /mnt/ws

fait un update de l’initramfs :

update-initramfs -u -k <version_du noyau>

et fini par une sortie du chroot (Ctrl-D), un démontage des montages, désactivation des lv (lvchange -a n ws-vg), fermeture du volume chiffré (cryptsetup luksClose nvme0n1p3_crypt) et un reboot.

Au redémarrage le système était de nouveau opérationnel.

Merci beaucoup pour ton aide et cette plongée très intéressante dans l’initramfs.

3 J'aime
#5

Bonjour, et merci beaucoup pour ce tuto qui m’a été fort utile.
Pour la petite histoire, mon problème était simplement d’avoir voulu mettre un disque avec une debian chiffrée déjà installée, dans une nouvelle machine (une récup plus récente quoi)
Et il ne trouvait plus le volume chiffré, en effet à cause d’initramsf.
C’est résolu maintenant !

J’ai cependant quelques remarques/compléments à apporter sur ce dernier post de reykir (celui que j’ai suivi/adapté) :

  • ouverture du volume chiffré : depuis un live ubuntu, le /dev/mapper est (logiquement) presque vide, il se remplira après activation du volume crypté. Donc je pense que la commande est plutôt

cryptsetup luksOpen /dev/sda5 sda5_crypt

étant entendu que sda5 est ma partition contenant le volume chiffré, et sda5_crypt le nom utilisé dans /etc/crypttab (précision : on parle du premier nom de la ligne, et non du nom long type UUID=*****)

  • juste une remarque sur le update-initramfs : je l’ai fait une première fois, mais sans faire attention à l’importance de reprendre le nom utilisé dans crypttab. Résultat, j’ai eu un message d’erreur fort instructif (un warning qui me disait justement que je n’étais pas en accord avec le contenu de crypttab), et j’ai donc refait l’opération en utilisant le bon nom ; nickel.
    Mais pour la petite histoire, il y a une petite complication à devoir utiliser le nom utilisé dans crypttab alors qu’il faut d’abord pouvoir accéder à son lv-root pour pouvoir lire crypttab… donc sans doute il faut faire un premier montage sans connaître le nom utilisé par crypttab ; puis le mettre de côté, démonter, remonter en utilisant le bon nom

  • dernière remarque : un raccourci que j’utilise pour désactiver les lv et vg

vgchange -an

En tout cas merci encore !

#6

Curieux. Un initramfs générique (construit avec MODULES=most dans /etc/initramfs-tools/initramfs.conf) devrait fonctionner à peu près dans n’importe quelle machine.

Il est possible de renommer le volume chiffré avec dmsetup rename ou encore d’en profiter pour modifier le nom du volume dans /etc/crypttab (et /etc/fstab le cas échéant), car “sda5_crypt”, c’est plutôt mal choisi. Primo parce que la partition n’est pas garantie de toujours avoir ce nom (il suffit d’ajouter un disque ou une partition pour que ça puisse changer), secundo parce qu’on se moque bien de savoir de quelle partition provient le volume chiffré ; à titre de comparaison, est-ce que le nom d’un ensemble RAID reprend le nom de ses partitions membres, ou est-ce que le nom d’un groupe de volumes LVM ou de ses volumes logiques reprend le nom de la partition qui lui sert de volume physique ? Non, alors pourquoi le ferait-on pour un volume chiffré ? Il serait préférable de le nommer en rapport avec son utilisation.

#7

Merci pour ces réponse. Mais je m’étonne un peu qu’elles soient si… étonnées, car sauf erreur, la debian dont je parle avait été tout d’une « générique », càd installée avec l’installeur de la distro (sans doute celui de Jessie pour le coup).
De même, le nom sda5_crypt n’est pas vraiment un « choix » de ma part ; je constate plutôt que je le retrouve sur toutes les machines sur lesquelles je fais une install générique, en suivant juste les écrans de l’installeur.
Voilà…

#8

Je sais. Je parlais du choix de l’installateur (en fait de ses développeurs).