Résumé : si, au boot d'une machine dont le support de stockage est totalement chiffré, cryptsetup
affiche l'erreur « error while loading shared libraries: libcryptsetup.so.4 » (variantes avec libgcrypt.so.20 et libgpg-error.so.0), vérifie que le paquet logiciel cryptsetup-initramfs
est bien installé et réinstalle-le le cas échéant.
Mes serveurs perso ont 315 jours d'uptime. Je décide de les redémarrer. Ça permet d'appliquer entièrement les mises à jour de sécurité et de se prémunir contre un redémarrage inopportun / forcé à un moment où on n'aura pas le temps de corriger un éventuel problème.
Sur celui dont tout le disque dur est chiffré (sauf /boot), je teste la passphrase, je vérifie que l'accès VNC distant est fonctionnel, je reboot
, et là, c'est le drame : /sbin/cryptsetup: error while loading shared libraries: libcryptsetup.so.4: cannot open shared object file : No such file or directory
. Une saisie correcte de la passphrase se termine en « cryptsetup failed, bad password or options? ».
Une recherche sur le web donne rien de satisfaisant.
Il s'agit d'un VPS OVH, donc je tente le mode rescue. Le mot de passe est envoyé par email. L'email de contact de mon compte OVH est géré par le serveur qui ne démarre plus… Néanmoins, le mot de passe du mode rescue est affiché sur la console VNC (KVM). \o/ Le clavier est en qwerty, donc je mets trop de temps à saisir le mot de passe, donc l'écran se rafraîchit et le mot de passe disparaît. Note pour la prochaine fois : prendre une capture d'écran du mot de passe. Je redémarre la machine avec ctrl+alt+suppr. Je me retrouve à nouveau sur le cryptsetup foireux. Je demande à nouveau de démarrer en mode rescue. L'interface web crache « Une erreur est survenue lors de la demande de réinitialisation du mot de passe. ». Plusieurs fois.
Je joue un peu avec l'accès VNC distant. J'atterris dans un initramfs. WTF ?! Je croyais que ce comportement avait pris fin en 2016, quand on avait estimé qu'il s'agit d'une faille de sécurité. Bon ben… tant mieux.
cryptsetup luksOpen /dev/sda2 sda2_crypt
crache directement l'erreur sus-mentionnée sans même demander la phrase de passe.
Sur une autre machine Debian 10 avec disque dur chiffré, apt-file search
ne trouve pas libcryptsetup.so.4 dans un quelconque paquet logiciel. Un sudo find / -iname 'libcryptsetup.so.4'
la trouve dans /usr/src/initramfs/lib/x86_64-linux-gnu/libcryptsetup.so.4. Si tu ne l'as pas, il faudra la récupérer dans le paquet logiciel distribué dans la version Stretch de Debian.
Je configure la pile IP. Le manager d'OVH ne semble pas exposer les paramètres (masque, routeur, etc.) donc je sors /etc/network/interfaces de mes sauvegardes. Je sors sur le net. \o/ Toutefois : pas de /etc/resolv.conf donc pas de résolution DNS.
Je récupère la bibliothèque de fonctions manquante avec wget
depuis l'un de mes serveurs web pour la mettre dans /lib/x86_64-linux-gnu
. Pas de DNS dans l'initramfs, donc, ça nécessite un serveur web avec un hôte virtuel qui écoute pour tous les noms possibles.
cryptsetup
se plaint désormais de l'absence de libgcrypt.so.20. Je la wget
. Désormais, l'objet de la plainte est libgpg-error.so.0. Je la récupère.
cryptsetup luksOpen /dev/sda2 sda2_crypt
fonctionnee. \o/
Je quitte initramfs (exit
), le serveur démarre. \o/
IPv6 ne fonctionne pas. C'est normal : j'ai monté l'interface dans initramfs eet je lui ai affecté une adresse IPv4, donc ifup
échoue et ne traite donc pas le bloc « inet6 » du fichier interfaces. Pour m'en assurer, je reboot
… tout en comprenant immédiatement ma connerie : je n'ai pas réparé l'initramfs, celui stocké sur le disque dur, donc ça ne va pas démarrer… Je recommence la configuration IP et le téléchargement des bibliothèques manquantes…
Les paquets logiciels libgpg-error0, libgcrypt20 et libcryptsetup12 (nouvelle version de libcryptsetup.so.4 arrivée avec la version Buster de Debian) sont installés (sinon je n'aurais pas pu tester la passphrase avant de redémarrer). Pour rappel : apt-file search
permet d'identifier le paquet logiciel qui contient un fichier précis.
Reconstruisons l'initramfs avec update-initramfs -uk 4.19.0-13-amd64
. Vérifions avec lsinitramfs /boot/initrd.img-4.19.0-13-amd64 | grep libcryptsetup
: aucun résultat, la bibliothèque n'a pas été incorporée à l'initramfs.
Je décide de réinstaller les paquets logiciels de la forme « cryptsetup » : apt-get install --reinstall cryptsetup cryptsetup-bin cryptsetup-run
. apt-get
m'informe que le paquet cryptsetup-initramfs (dont dépend le paquet cryptsetup) n'est pas installé et qu'il va l'installer. Ooook, tout s'explique !
Après l'installation de cryptsetup-initramfs, lsinitramfs
nous confirme que libcryptsetup.so.20 est bien présente dans l'initramfs. \o/
Un reboot
fonctionne parfaitement. \o/
Au final, à quelle ocassion le paquet cryptsetup-initramfs a-t-il été désinstallé ? Aucune idée, /var/log/dpkg.log
n'en dit pas un mot. libgcrypt20 et libcryptsetup12 ont été installées le 14/02/2020, date à laquelle j'ai mis à jour de Stretch à Buster. libcryptsetup4 a été supprimée ce jour-là. Le système a correctement redémarré le 16/02/2020, c'est /var/log/kern.log
qui l'affirme, mais un calcul "28/12/2020 - 315 jours d'uptime" permettait d'avoir une estimation.