Buster: Volume group not found

Support Debian
Tags: #<Tag:0x00007f46abed96a0>
#1

Bonjour à toutes et tous,

J’ai franchi un cap avec Debian en passant de Stretch à Buster car j’ai lu lu toute la “Release note” pour que le passage se déroule au mieux. (C’est ma première fois :clap::clap::clap:)

Et si tout s’est relativement bien passé, je rencontre maintenant un problème plutôt facheux.

SI je redémarre avec la version:
4.19.0-5-amd64 (et la recovery)
Le joli petit message d’erreur suivant apparait:

Volume group "XXX--vg" not found
Cannot process volume group XXX-vg

juste avant de me proposer un semblant de prompt ( initramfs )

Si je démarre avec la version:
4.9.0-9-amd64
Je fini sur un très beau fond d’écran Debian 10 que je peux uniquement contempler.

Si je démarre avec la version:
4.9.0-9-amd64 recovery
Je démarre en shell après avoir entré le mdp root (Le mode recovery fonctionne en gros :blush:)

Il me semble, mais ma mémoire me trahi peut être, que j’ai pu redémarré au moins une fois sans problème et je ne pense pas avoir fait de mise à jour.
Lors de mes recherches, ceux qui avaient des problèmes similaires, avaient du parfois modifier le GRUB pour utiliser le UUID plutôt que le label mais cela semble être bien comme cela que ça fonctionne.
D’autre me parle de /etc/fstab/ a modifier mais, je n’arrive pas a monter le dd et donc ne peux rien modifier.

Quelqu’un aurait il l’amabilité de m’aider parce que la, je sèche complètement et je ne vaut pas prendre les mauvais habitudes que j’avais quand j’utilisais Windows (Format c:)

Merci d’avance pour votre aide Ô combien précieuse.

Bien à vous.

#2

Même Ctrl+Alt+F4 ne te fait pas passer sur un terminal console ?
Une fois en console, soit avec la séquence précédente, soit en passant par le recovery, est ce que tu trouves des messages d’erreur un peu significatifs dans /var/log/Xorg.0.log (si le probléme vient comme je le pense d’X window) ou bien dans /var/log/syslog (en commençant à éplucher par la fin).
Pour ouvrir les 2 fichiers en console en root, tu dois pouvoir utiliser nano (et sinon apt install nano avant).

#3

Merci mattotop pour ces pistes.

Malheureusement, le système semble figé.

Je n’ai pas ce fichier dans mes logs et il me semble avoir lu que dans Debian 10, le system d’affichage par defaut est passé de Xorg à Wayland.(La confirmation est ici.)

Je pense que mon problème se situe plutot dans le fait que j’utilise LVM avec un disque crypté.
J’ai lu beaucoup d’information sur le sujet mais ne suis pas sur d’avoir bien tout compris la documentation étant surtout anglaise.

#4

Etat d’avancement:

mon /dev/sda5 est une partition de type crypto_LUKS
(commande blkid -o value -s TYPE /dev/sda5 depuis le initramsfs
Resultat de la commande fstype /dev/sda5
FSTYPE=luks
FSSIZE=0 :scream::scream::scream:

Je pense donc avoir trouver le problème…
Tout ce passe sur cette partition.

Reste a trouver la solution… :+1:

#5

Un conteneur chiffré LUKS n’est pas un système de fichiers et n’a pas de taille par lui-même, donc je ne considère pas FSSIZE=0 comme une anomalie.

Si la racine est dans un volume logique chiffré, l’initramfs devrait demander la passphrase de déchiffrement. Est-ce le cas ? Si oui, l’ouverture réussit-elle et entraîne-t-elle la création d’un volume /dev/mapper/sda5_crypt contenant le PV LVM ?

A ta place je profiterais du shell de l’initramfs pour faire quelques vérifications.
La présence et le contenu d’un fichier /etc/crypttab ou /conf.d/cryptdisks (ou approchant).
L’ouverture manuelle du volume chiffré avec cryptsetup

cryptsetup luksOpen /dev/sda5 sda5_crypt

En cas de succès, vérifier le contenu du volume chiffré /dev/mapper/sda5_crypt.
Activer LVM avec vgchange -ay et quitter le shell pour poursuivre le démarrage.

#6

Merci PascalHambourg.

Je me coucherai donc moins bête ce soir.

J’étais parti du principe que vu que c’était une partition chiffré, elle devait automatiquement avoir une taille.

Non, le déchiffrement n’est pas demande du tout.

Je ne demande pas mieux mais quelqu’un a quelques informations sur ce “shell”, beaucoup de commande ne fonctionne pas. J’imagine que la syntaxe doit être différentes.

Je ne trouve aucun de ces deux fichiers et le fichier fstab est vierge. Est ce normal?

La commande cryptsetup/crytpsetup n’est pas trouvé.

#7

Par contre il est demandé avec le noyau 4.9 ?

Pas du tout. C’est ash, un shell compatible POSIX comme bash inclus dans busybox. Busybox inclut en interne un grand nombre de commandes qui sont habituellement des commandes externes (faisant appel à un exécutable distinct). Mais tous les exécutables du système ne sont pas inclus dans l’initramfs, donc seuls ceux qui sont inclus sont utilisables comme commandes externes. Normalement quand la racine est chiffrée, cryptsetup est inclus lors de la construction de l’initramfs. Si ce n’est pas le cas, l’initramfs a été mal construit.

Démarre en mode dépannage avec le noyau 4.9. Recherche les fichiers dont le nom contient “crypt” dans l’initramfs du noyau 4.19 avec

lsinitramfs /boot/initrd.img-4.19.0-5-amd64 | grep crypt

S’il n’y a pas cryptsetup et compagnie, vérifie si le paquet cryptsetup-initramfs est installé. S’il ne l’est pas, installe-le. Dans les deux cas, essaie ensuite de reconstruire l’initramfs du noyau 4.19 avec

update-initramfs -u -k 4.19.0-5-amd64

et revérifie le contenu de l’initramfs.

#8

Waouw…
Quelle magnifique communauté d’entre aide et de savoir a partager.

Effectivement, le cryptosetup n’était pas installé. Une fois celui-ci present et la fin de la commande update-initramfs, la machine est repartie convenablement.

Merci encore.

#9

Donc quelque chose s’est mal passé pendant la mise à niveau de stretch vers buster.
Avec une racine chiffrée, les paquets cryptsetup* étaient forcément installés donc ils ont été désinstallés au lieu d’être mis à jour. Si ça t’intéresse, tu peux regarder dans les logs d’apt /var/log/apt/history.log* et term.log* à quel moment ces paquets ont été désinstallés.

Par contre je suppose que l’environnement graphique ne démarre toujours pas correctement avec le noyau 4.9 ? Peut-être pas compatible avec Wayland ?

#10

A moins que ce soit moi qui ai gaffé puisque j’essayait d’installer une nouvelle version de LibreOffice et que la place est assez limité.
Un nettoyage peut être trop efficace.
Surtout qu’il me semble que j’ai utiliser “autoremove” et peut être que ce(s) paquet(s) ont été supprimé a ce moment la.

#11

Ceci n’a pas encore été testé vu que j’ai récupéré la dernière version stable du système… Est ce une bonne idée?

#12

Si c’est le cas tu retrouveras la liste des paquets désinstallés par cette commande autoremove dans le fichier /var/log/apt/history.log* correspondant à la date de l’opération.

A toi de voir. Ça ne risque rien de plus que la fois précédente. Si le noyau 4.9 de stretch n’est pas compatible avec Wayland, autant le désinstaller surtout si tu manques d’espace disque.