[RESOLU] LVM chiffrée : Démarrage Impossible

Support Debian
#1

Bonjour à tous,

Voila mon nouveau problème qui me paralyse ma Debian. Je vais vous donner un maximum d’info pour essayer d’être le plus complet possible.
Déjà en pièce jointe, vous trouverez la capture d’écran des erreurs.

J’ai redémarré mon poste fin de semaine dernière (je précise qu’il n’ai jamais éteint ni redémarrer) et là BOOMM !!! :anguished: le voila qui m’indique qu’il ne trouve plus ma LV ROOT et qu’il ne peut donc pas me demander ma passphrase. Suite aux différents conseils que j’ai pu avoir j’ai exécuté les commandes suivantes via un live-CD :

cryptsetup luksOpen /dev/sda3 root
mount /dev/mapper/VG_SSD_VL_ROOT /mnt/
vi /mnt/user/shared/.../scripts/local-top/cryptroot
// Je précise que j'avais modifié ce fichier là pour combler une faille de sécurité : [Lien](https://korben.info/faille-cryptsetup-permet-dobtenir-acces-root-certaines-machines-linux.html)
J'ai donc remis tout "d'origine"
chroot /mnt/
update-initramfs -v -u

Malgré cela il m’affiche toujours le même problème, alors que la ligne 360 est maintenant commentée et que la commande “update-initramfs” ne m’indique maintenant plus d’erreur.
Je n’ai plus d’idée … donc si vous en avez je suis preneur.

Merci d’avance

gudbes

#2

Quel même problème ? L’erreur de syntaxe ?
Avec une installation standard sur LVM chiffré, /boot, qui contient l’initramfs, est une partition séparée. Dans ce cas l’avais-tu montée avant d’exécuter update-initramfs ? Sinon tu n’as pas modifié le bon fichier initramfs.

Tu as écris que update-initramfs n’indique plus d’erreur. Quelle erreur indiquait-elle auparavant, et dans quelles conditions ?

Quand le démarrage s’arrête avec le shell de l’initramfs, tu peux vérifier le contenu du script voire exécuter manuellement les commandes cryptsetup et compagnie pour ouvrir le volume chiffré et activer les volumes LVM. Ensuite, Ctrl+D pour terminer le shell devrait poursuivre le démarrage. Ainsi pas besoin de système live.

#3

Bonjour et merci @PascalHambourg de te pencher de nouveau sur l’un de mes problèmes.

Alors pour essayer de répondre le plus explicitement à tes questions :

Quel même problème -> en effet le même problème reste les erreurs affichées au démarrage (sur la pièce jointe dans le 1er post).

L’erreur que m’indiquait update-initramfs (avant que je ne remets d’origine le fichier cryptroot) était que mon fichier cryptroot contenant une erreur de synthaxe à la ligne 360.

Sinon je viens d’utiliser la commande cryptsetup via le shell initramfs pas de soucis mais par contre quand j’essaye de monter la VL ROOT dans /tmp (par exemple) via la commande #mount /dev/mapper/VL_ROOT /tmp/, il m’indique no such file or directory alors que le dossier tmp existe bien.
Si je trouve deux minutes dans ma journée, j’essayerai de passer par le live-cd.

Encore merci de ton aide et j’espère avoir répondu à tes questions.

gudbes

#4

Je ne suis pas sûr de comprendre. Il y a deux types de scripts liés à l’initramfs, qui sont stockés dans des répertoires distincts (que je n’ai pas sous la main) :

  • ceux qui sont exécutés lors de la création de l’initramfs par l’exécution de update-initramfs
  • ceux qui sont inclus dans l’initramfs et exécutés lors du déroulement de ce dernier au démarrage.

Lequel as-tu modifié ?

Note : /tmp n’a pas vocation à servir de point de montage temporaire, c’est plutôt le rôle de /mnt. Le point de montage de la racine dans l’initramfs est /root.

Vérifie le nom du fichier de périphérique que tu spécifies : la forme générale est /dev/mapper/VG-LV ou /dev/VG/LV donc dans ton cas /dev/mapper/VG_SSD-VL_ROOT ou /dev/VG_SSD/VL_ROOT. S’il n’est pas présent, il faut activer les LV avec vgchange -ay.

#5

Pour répondre à tes questions :

  • Je ne sais pas lequel que j’ai modifié (je ne m’y connais pas assez :s ), la seule chose que je suis sur c’est que le chemin est (une fois ma partition sur /mnt) : /usr/share/initramfs-tools/scripts/local-top/cryptroot

Mon soucis vient peut être de là ce n’est peut être pas le bon.

  • Pour le montage sous /tmp, j’avais créer le dossier “mnt” car il n’existait pas et cela n’avait rien changé et vu que j’avais redémarré mon P.C. (par feignantise) j’ai utilisé le dossier tmp :slight_smile:

  • Je viens de trouver mon VG grâce à la commande “vgchange -ay”.

Je vais donc continuer la montage de tout cela et refaire le tests en espérant que le fichier cryptroot est le bon.

gudbes

[edit]

J’essaye ma commande “mount /dev/mapper/VG_SSD-LV_ROOT /mnt/” mais toujours la même erreur : mount : mouting dev/mapper/VG_SSD-LV_ROOT on /mnt/ failed : No such file or directory.

#6

/dev/mapper/VG_SSD-LV_ROOT et /mnt existent ?
Et en spécifiant le type de système de fichiers dans la commande mount avec l’option -t ? Si ext4 : -t ext4

#7

Merci @PascalHambourg,

En effet il manquait l’option “-t ext4” (pourquoi j’y ai pas pensé :rage:) …
La partition ROOT est donc montée, … pour le reste c’est un peu flou … Dis moi si je me trompe :

  • Je vais monter la partition BOOT sur /mnt/BOOT (il faut que je regarde de quel type elle est.
  • Je vais un “chroot” de /mnt/ROOT (ma partition chiffrée)
  • Je vérifie que mon fichier “cryptroot” dans /mnt/ROOT/s=usr/share/initramfs-tools/scripts/local-top/ est sans erreur.
  • Puis je lance un “update-initramfs” (on m’a parlé aussi de la commande “mkinitramfs”
  • et je fini par un “CTRL+D”

C’est bien cela ?

Je te remercie encore pour le temps que tu passe à me rendre ce grand service (et ce n’est pas la première fois :slight_smile: )
et surtout un grand merci (car malheureusement je trouve que c’est le problème avec d’autres) pour ta patience car mes connaissances ne sont pas grandes mais grâce à toi j’en apprend un peu plus à chaque fois et ça c’est super !!! MERCI !!!

gudbes

#8

Parce que le message d’erreur “no such file or directory” est très ambigu, et habituellement le type de système de fichiers est automatiquement détecté. Mais les commandes de busybox incluses dans l’initramfs ont moins de fonctionnalités que celles du système normal.

En fait il devrait suffire de faire Ctrl+D pour fermer le shell et poursuivre le déroulement de l’initramfs juste après avoir activé les volumes logiques. Tu ne devrais pas laisser le volume racine monté sur /mnt/ROOT (mais c’était bien de le monter pour vérifier que ça marche), car l’initramfs devrait le monter de lui-même sur /root après Ctrl+D. Si quelque chose coince encore un nouveau shell s’ouvrira.

Si tu veux faire un chroot manuel depuis l’initramfs (en supposant que chroot est inclus dans l’initramfs), il ne faut pas monter la partition /boot sur /mnt/BOOT mais sur le répertoire boot relatif au point de montage du volume racine, qui serait donc /mnt/ROOT/boot dans ton cas, ou plus simplement monter tous les systèmes de fichiers définis en auto dans /etc/fstab avec mount -a une fois dans le chroot.

#9

MERCI !!! @PascalHambourg.
J’ai donc activé les volumes avec “vgchange -ay” puis un petit “CTRL+D” et voila que ma debian se lance …
Merci milles fois comme d’habitude tu me sors de mes problèmes complexes.

Bonne continuation à toi et bon courage… à très bientôt :yum:

gudbes

#10

Ce n’est pas terminé, il reste à réparer l’erreur du script cryptroot dans l’initramfs. Mais au moins tu peux le faire depuis le système Debian lui-même, avec tout le confort disponible.

#11

Bonjour @PascalHambourg,

J’ai du faire une bêtise. J’ai démarré sur ma debian, j’ai vérifié le fichier “cryptroot” et j’ai fais un update-initramfs. Je n’ai pas eu de message d’erreur (et le fichier initramfs dans le dossier /boot était bien à la date du jour donc bien modifié) mais au redémarrage, toujours la même erreur et le même shell que la capture d’écran. Mais en plus maintenant il ne reconnais plus ma commande cryptsetup donc je ne peux plus monter ma partition chiffrée.

As tu une idée ?

Merci d’avance.

Gudbes

#12

Si cryptsetup n’est plus dans l’initramfs, et si tu n’as pas configuré update-initramfs.conf pour garder une copie de sauvegarde de l’ancien initramfs (option backup_initramfs), il va falloir démarrer d’une autre façon, par exemple avec un système live ou avec l’installateur Debian en mode “rescue”, puis faire un chroot (ce que le mode “rescue” automatise assez bien), monter les systèmes de fichiers. Là, je forcerais la réinstallation du paquet cryptsetup, ce qui devrait remettre les scripts dans leur état originel et automatiquement regénérer un initramfs.

PS : tu peux enlver le “résolu” du titre tant que le problème demeure.

#13

Alors j’ai démarré sur un live cd car malheureux avec le recovery je n’arrivais à rien.
J’ai donc monté ma partition chiffrée (cryptsetup+vgchange+mount) puis j’ai “chrooter” sur /mnt/. Jusque là tout est bon… J’ai fais un “apt remove --purge cryptsetup” puis un “apt install cryptsetup”. J’ai une confirmation que le fichier /boot/initiales.img-3.16.0-4-amd64 est généré. Je quitte mon chroot et je redémarre. Mais toujours pas de commande cryptsetup ? :slightly_frowning_face:

Gudbes

#14

Tu avais bien monté la partition boot sur /boot après être entré dans le chroot ?

Avant de quitter le chroot, tu peux vérifier le contenu d’un initramfs avec la commande lsinitramfs. L’initramfs est un fichier /boot/initrd.img-*.

#15

@PascalHambourg, je ne vois pas comment monter ma partition lors que j’ai exécuté mon chroot car je n’ai rien dans mon /dev ?

Je dois la monter avant ?

Gudbes

#16

Tu peux monter la partition boot avant, ou bien remonter /dev, /proc et /sys dans le chroot.

mount -t proc proc /proc
mount -t devtmpfs dev /dev
mount -t sysfs sysfs /sys

Dans les deux cas tu auras probablement aussi besoin de /proc et éventuellement de /sys. C’est pour cela que je suggérais le mode rescue de l’installateur Debian qui monte tout ça automatiquement avant de lancer le shell sur la racine (en fait dans un chroot).

Au pire, tu peux faire simple en laissant update-initramfs créer l’initramfs dans le LV racine et puis tu le copies dans la partition boot montée n’importe où hors du chroot, après avoir vérifié qu’il contient bien cryptsetup.

#17

Ah !!! J’essayais le mode rescue de grub et non celui de l’installateur :rage:.
J’ai donc indiqué la partition /dev/VG_SSD_LV_ROOT en racine.
A première vue mon /boot est bien monté (il contient vmlinuz, initrd.img,efi,grub,…).

Alors pour ne plus faire de bêtises… Il faut que je fasse update-initramfs, c’est bien ça et je vérifie avec lsinitramfs que le fichier cryptsetup est bien présent.
Si je fais cela est ce que cela mon problème sera réglé (capture d’ecran) sachant que j’ai mis à jour mon fichier cryptroot comme d’origine.

Merci d’avance :slight_smile:️

Gudbes

#18

Je pense que oui.

Note : update-initramfs risque de couiner parce que l’initramfs présent ne correspondra pas à celui généré précédemment, ce qui est normal puisque ce dernier est dans le répertoire /boot de la racine et non dans la partition boot.

D’ailleurs, comme je l’écrivais dans mon message précédent, s’il contient cryptsetup tu peux juste le mettre au bon emplacement.

#19

Alors (roulement de tambour) tout est ok☺️☺️☺️

C’est bon plus de message d’erreur. J’ai donc démarré sur le recovery du DVD d’installation de debian et j’ai utilisé la commande : “update-initramfs -v -u” Il n’y a eu aucun message d’erreur.
J’ai redémarré et maintenant il me propose comme avant d’entrer ma passphrase pour déchiffrer mes partitions.

Encore et encore et encore merci @PascalHambourg

Bon week-end

Gudbes

#20

Ça marche beaucoup mieux quand on fait les choses comme il faut. Et pour faire les choses comme il faut, il vaut mieux comprendre comment ça marche et savoir ce qui se passe.

Au passage, on a trop tendance à se jeter sur un système live pour dépanner une installation de Debian alors que le mode rescue de l’installateur Debian peut rendre bien des services, même s’il n’est pas aussi complet.

Un mot concernant la faille de cryptsetup que tu essayais de combler : elle n’est pertinente que sur un système dont l’amorçage est protégé contre les modifications de la ligne de commande du noyau. Sur une installation par défaut, on peut facilement obtenir un shell root dans l’initramfs sans avoir besoin d’exploiter cette faille, juste en modifiant la ligne de commande du noyau dans le chargeur d’amorçage.

PS : il y a une case à cocher pour marquer le sujet comme résolu.