Forums Linux Autres OS Linux

Problème de l'installeur Debian qui ne reconnaît pas les disques cryptés.

Le mardi 10 Décembre 2019 à 18:34

moondump

Bonjour à tous,

j'ai pris l'habitude de faire coexister, grâce à LVM, plusieurs v=
ersions de cette distribution sur une même station afin de passer sere=
inement d'une version à sa supérieure. Cela me donne du temps pou=
r configurer la nouvelle.

Il y quelques temps, j'ai décidé de chiffrer les disques de mes s=
tations. J'ai donc rincé ceux-ci et j'y ai réinstallé la der=
nière version en production (V9, dite Stretch). Tout c'est bien pass=
é et voici ce que cela donne une fois le tout monté :

:-) mount | awk '/^/dev//' | sort =
=
=
=

/dev/mapper/s02_boot-Deb--Stretch_v9--boot on /boot type ext4 (rw,relatime,=
data=ordered)
/dev/mapper/s02_crypt-Deb--Stretch_v9--Racine on / type ext4 (rw,relatime,e=
rrors=remount-ro,data=ordered)
/dev/mapper/s02_crypt-Deb--Stretch_v9--usr on /usr type ext4 (rw,relatime,d=
ata=ordered)
/dev/mapper/s02_crypt-Deb--Stretch_v9--var on /var type ext4 (rw,relatime,d=
ata=ordered)
/dev/mapper/s02_crypt-home on /home type ext4 (rw,relatime,data=ordered)
/dev/mapper/s02_crypt-root on /root type ext4 (rw,relatime,stripe=4,data=
=ordered)
/dev/mapper/s02_crypt-tmp on /tmp type ext4 (rw,relatime,data=ordered)
:-)

J'espère que mes règles de nommage sont assez explicites, «s=
02_boot» et «s02_crypt» étant des groupes de volumes. L=
e reste est constitués des volumes logiques.

Mais, lorsque j'ai voulu installer la version 10, dite «Buster», =
quelle ne fut pas ma surprise de constater que l'installeur ne «voyait=
» mon disque chiffré ! Ou plus exactement, le groupe de volumes =
«s02_crypt» à l'intérieur du disque chiffré.

J'ai donc essayé de contourner la difficulté en passant par le mo=
de expert de l'installeur. Avant le partitionnement, j'ouvre un shell (Dash=
) et j'utilise «cryptsetup» pour déchiffrer le sda5, qui est=
le volume physique supportant «s02_crypt». Je peux alors cr�=
�er tous les volumes logiques et finir l'installation sans problème.=
J'ai donc en définitive :

:-) ls -1 /dev/mapper/
control
s02_boot-Deb--Buster_10--boot
s02_boot-Deb--Stretch_v9--boot
s02_crypt-Deb--Buster_v10--Racine
s02_crypt-Deb--Buster_v10--usr
s02_crypt-Deb--Buster_v10--var
s02_crypt-Deb--Stretch_v9--Racine
s02_crypt-Deb--Stretch_v9--usr
s02_crypt-Deb--Stretch_v9--var
s02_crypt-home
s02_crypt-root
s02_crypt-swap
s02_crypt-tmp
sda5_crypt
:-)

avec deux magnifiques OS installés aux bons endroits.

Oui mais voila, lors du boot, je tombe sur un os… Le noyau se plain=
t de ne pas trouver la partition Racine (s02_crypt-Deb--Buster_v10--Racine).

J'ai comparé les deux initrd.img, et j'ai d'une part pour la premi�=
�re version :

:-) lsinitramfs /boot/initrd.img-4.9.0-7-amd64 | awk '/crypt/' | sort | mo=
re
bin/cryptroot-unlock
conf/conf.d/cryptroot
lib/cryptsetup
lib/cryptsetup/askpass
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto/aesni-intel.ko
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto/aes-x86_64.ko
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto/blowfish-x86_64.ko
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto/camellia-aesni-avx2.ko
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto/camellia-aesni-avx-x86_64.=
ko
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto/camellia-x86_64.ko
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto/cast5-avx-x86_64.ko
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto/cast6-avx-x86_64.ko
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto/chacha20-x86_64.ko
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto/crc32c-intel.ko
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto/crc32-pclmul.ko
lib/modules/4.9.0-7-amd64/kernel/arch/x86/crypto/crct10dif-pclmul.ko
# Plein de lignes…
lib/modules/4.9.0-7-amd64/kernel/crypto/wp512.ko
lib/modules/4.9.0-7-amd64/kernel/crypto/xcbc.ko
lib/modules/4.9.0-7-amd64/kernel/crypto/xor.ko
lib/modules/4.9.0-7-amd64/kernel/crypto/xts.ko
lib/modules/4.9.0-7-amd64/kernel/drivers/crypto
lib/modules/4.9.0-7-amd64/kernel/drivers/crypto/padlock-aes.ko
lib/modules/4.9.0-7-amd64/kernel/drivers/md/dm-crypt.ko
lib/modules/4.9.0-7-amd64/kernel/fs/crypto
lib/modules/4.9.0-7-amd64/kernel/fs/crypto/fscrypto.ko
lib/x86_64-linux-gnu/libcryptsetup.so.4
lib/x86_64-linux-gnu/libcryptsetup.so.4.7.0
lib/x86_64-linux-gnu/libgcrypt.so.20
lib/x86_64-linux-gnu/libgcrypt.so.20.1.6
sbin/cryptsetup
scripts/local-block/cryptroot
scripts/local-bottom/cryptopensc
scripts/local-top/cryptopensc
scripts/local-top/cryptroot
:-)

et pour la nouvelle version :

:-) lsinitramfs /…/initrd.img-4.19.0-6-amd64 | awk '/crypt/' | sor=
t | more
cryptroot
cryptroot/crypttab
etc/lvm/backup/s02_crypt
scripts/local-block/cryptroot
scripts/local-bottom/cryptgnupg-sc
scripts/local-bottom/cryptopensc
scripts/local-top/cryptopensc
scripts/local-top/cryptroot
usr/bin/cryptroot-unlock
usr/lib/modules/4.19.0-6-amd64/kernel/arch/x86/crypto
usr/lib/modules/4.19.0-6-amd64/kernel/arch/x86/crypto/aesni-intel.ko
usr/lib/modules/4.19.0-6-amd64/kernel/arch/x86/crypto/aes-x86_64.ko
usr/lib/modules/4.19.0-6-amd64/kernel/arch/x86/crypto/crc32c-intel.ko
usr/lib/modules/4.19.0-6-amd64/kernel/arch/x86/crypto/glue_helper.ko
usr/lib/modules/4.19.0-6-amd64/kernel/crypto
usr/lib/modules/4.19.0-6-amd64/kernel/crypto/arc4.ko
usr/lib/modules/4.19.0-6-amd64/kernel/crypto/async_tx
usr/lib/modules/4.19.0-6-amd64/kernel/crypto/async_tx/async_memcpy.ko
usr/lib/modules/4.19.0-6-amd64/kernel/crypto/async_tx/async_pq.ko
usr/lib/modules/4.19.0-6-amd64/kernel/crypto/async_tx/async_raid6_recov.ko
usr/lib/modules/4.19.0-6-amd64/kernel/crypto/async_tx/async_tx.ko
usr/lib/modules/4.19.0-6-amd64/kernel/crypto/async_tx/async_xor.ko
usr/lib/modules/4.19.0-6-amd64/kernel/crypto/crc32c_generic.ko
usr/lib/modules/4.19.0-6-amd64/kernel/crypto/cryptd.ko
usr/lib/modules/4.19.0-6-amd64/kernel/crypto/crypto_simd.ko
usr/lib/modules/4.19.0-6-amd64/kernel/crypto/ecb.ko
usr/lib/modules/4.19.0-6-amd64/kernel/crypto/xor.ko
usr/lib/modules/4.19.0-6-amd64/kernel/drivers/crypto
usr/lib/modules/4.19.0-6-amd64/kernel/drivers/crypto/padlock-aes.ko
usr/lib/modules/4.19.0-6-amd64/kernel/fs/crypto
usr/lib/modules/4.19.0-6-amd64/kernel/fs/crypto/fscrypto.ko
usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
usr/lib/x86_64-linux-gnu/libgcrypt.so.20
usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.4
:-)

Je n'ai pas, en autres, de «sbin/cryptsetup» dans le initrd.img d=
e la version Buster et je pense que le problème vient de là.

J'ai essayé plusieurs approches techniques, dont un «dracut chroo=
té» ou avec la possibilité qu'a Grub de déchiffrer Luks=
1, mais sans succès pour l'instant. Pas de résultat non plus en f=
ouillant de l'installeur Debian.

Au début, j'ai même tenté l'installation façon «Ge=
ntoo», voir https://www.debian.org/releases/stable/amd64/apds03.en.htm=
l, mais sans modification du initrd.img.

Je suis passé peut être à coté d'une solution toute sim=
ple, mais pour l'instant, je tourne en rond.

Merci de votre attention.

Partager ce contenu :

Vos réponses

Trier par : date / pertinence

Pascal Hambourg

Le 10/12/2019 à 19:56 #26532850

Le 10/12/2019 à 18:34, a écrit :

/dev/mapper/s02_crypt-root on /root type ext4 (rw,relatime,stripe=4,data=ordered)

/root n'est pas censé être détaché de la racine, afin d'être accessible
au cas où un problème à l'initialisation empêcherait le montage des
systèmes de fichiers. Si tu veux un espace de stockage pour root partagé
entre les versions, tu peux le monter en /home/root.

/dev/mapper/s02_crypt-tmp on /tmp type ext4 (rw,relatime,data=ordered)
:-)
J'espère que mes règles de nommage sont assez explicites, «s02_boot» et «s02_crypt» étant des groupes de volumes. Le reste est constitués des volumes logiques.

J'aurais au moins créé une partition classique pour /boot/grub afin que
le chargeur d'amorçage soit indépendant de LVM.

Mais, lorsque j'ai voulu installer la version 10, dite «Buster», quelle ne fut pas ma surprise de constater que l'installeur ne «voyait» mon disque chiffré ! Ou plus exactement, le groupe de volumes «s02_crypt» à l'intérieur du disque chiffré.

Problème connu, le partitionneur de l'installateur Debian ne permet pas
de réutiliser des volumes chiffrés existants.

J'ai donc essayé de contourner la difficulté en passant par le mode expert de l'installeur. Avant le partitionnement, j'ouvre un shell (Dash) et j'utilise «cryptsetup» pour déchiffrer le sda5, qui est le volume physique supportant «s02_crypt». Je peux alors créer tous les volumes logiques et finir l'installation sans problème.

Classique, mais pas suffisant...

Oui mais voila, lors du boot, je tombe sur un os… Le noyau se plaint de ne pas trouver la partition Racine (s02_crypt-Deb--Buster_v10--Racine).

Ben oui, comme l'installateur n'a pas créé de volume chiffré il n'a pas
installé les paquets qui gèrent le chiffrement, et probablement même pas
initialisé /etc/crypttab. Pour buster il faut compléter /etc/crypttab si
besoin et installer le paquet cryptsetup-initramfs (ce qui devrait
reconstruire l'initramfs automatiquement, sinon le faire avec
update-initramfs -u).
Tout cela doit être faisable avec l'installateur en mode rescue,
ouverture des volumes chiffrés (c'est pris en charge), sélection de la
racine puis lancement d'un shell sur la racine du système installé,
montage des autres volumes. Ou bien avec chroot depuis l'autre système.

-1 Répondre en citant

Pascal Hambourg

Le 11/12/2019 à 07:07 #26532865

Le 10/12/2019 à 23:57, a écrit :

Root chrooté (Deb Buster) :

(...)

apt-cache show initramfs-tools
apt-get install initramfs-tools # Des erreurs !

Pourquoi initramfs-tools ? Ce paquet est déjà installé.

Autre session Root non chrooté (Deb Stretch) :
cd /mnt/debinst_buster/
mv dev dev-ref
cp -a /dev/ . # Capillotracté ???
ls dev/
ls dev/mapper/
cp -a etc etc-ref

Très maladroit.
Pour ./dev, il faut soit monter avec -t devtmpfs, soit monter /dev en
--bind. Dans ./etc, il suffit de renseigner les DNS dans /etc/resolv.conf.

mv etc/crypttab etc/crypttab-ref
cp -p /etc/crypttab etc/

-1 Répondre en citant

Pascal Hambourg

Le 14/12/2019 à 23:57 #26533121

Le 14/12/2019 à 18:50, a écrit :

Ce qui m'intéresserais de savoir, c'est ce qui se cache derrière
«Détecter les disques» et «partitionner les disques» de
l'installeur. J'ai cherché sur Internet comment peupler manuellement
/dev/mapper/, mais sans résultat. Il y a bien dmsetup, il n'est pas d'un
maniement facile.

Pour quoi faire ? Il est plus pratique de piloter le device mapper avec
les commandes de plus haut niveau de LVM et cryptsetup.

-1 Répondre en citant

moondump

Le 15/12/2019 à 18:21 #26533146

Pascal Hambourg

Le 14/12/2019 à 18:50, a écrit :

Ce qui m'intéresserais de savoir, c'est ce qui se cache derriè re
«Détecter les disques» et «partitionner les disques » de
l'installeur. J'ai cherché sur Internet comment peupler manuellement
/dev/mapper/, mais sans résultat. Il y a bien dmsetup, il n'est pas d'un
maniement facile.

Pour quoi faire ? Il est plus pratique de piloter le device mapper
avec les commandes de plus haut niveau de LVM et cryptsetup.

Oui, sans aucun doute, mais dans ce cas précis, lesquelles ? C'est bi en
pour cela que j'ai écris : «Ce qui m'intéresserais de savoir , c'est ce
qui se cache derrière «Détecter les disques» et «p artitionner les
disques» de l'installeur.»
Concrétement, comment faire pour obtenir le même résultat, m ais cette
fois manuellement ? Ou dit autrement, avec des lignes de commandes ?

-1 Répondre en citant

Pascal Hambourg

Le 15/12/2019 à 21:02 #26533150

Le 15/12/2019 à 18:21, a écrit :

Pascal Hambourg
Le 14/12/2019 à 18:50, a écrit :

Ce qui m'intéresserais de savoir, c'est ce qui se cache derrière
«Détecter les disques» et «partitionner les disques» de
l'installeur. J'ai cherché sur Internet comment peupler manuellement
/dev/mapper/, mais sans résultat. Il y a bien dmsetup, il n'est pas d'un
maniement facile.

Pour quoi faire ? Il est plus pratique de piloter le device mapper
avec les commandes de plus haut niveau de LVM et cryptsetup.

Oui, sans aucun doute, mais dans ce cas précis, lesquelles ?

Tu les connais déjà : cryptsetup, pvcreate, vgcreate, lvcreate, vgchange...

C'est bien
pour cela que j'ai écris : «Ce qui m'intéresserais de savoir, c'est ce
qui se cache derrière «Détecter les disques» et «partitionner les
disques» de l'installeur.»
Concrétement, comment faire pour obtenir le même résultat, mais cette
fois manuellement ? Ou dit autrement, avec des lignes de commandes ?

Le même résultat que quoi ?
Je ne vois pas où tu veux en venir.

-1 Répondre en citant

moondump

Le 16/12/2019 à 00:17 #26533153

Tiens ! Je viens de faire une trouvaille… :-)
C'est vgmknodes --refresh
:/# lvdisplay
:/# vgmknodes --refresh
The link /dev/s02_crypt/Deb-Stretch_v9-Racine should have been created by udev but it was not found. Falling back to direct link c
reation.
The link /dev/s02_crypt/Deb-Stretch_v9-usr should have been created by ud ev but it was not found. Falling back to direct link crea
tion.
The link /dev/s02_crypt/Deb-Stretch_v9-var should have been created by ud ev but it was not found. Falling back to direct link crea
tion.
The link /dev/s02_crypt/root should have been created by udev but it was not found. Falling back to direct link creation.
The link /dev/s02_crypt/swap should have been created by udev but it was not found. Falling back to direct link creation.
The link /dev/s02_crypt/tmp should have been created by udev but it was n ot found. Falling back to direct link creation.
The link /dev/s02_crypt/home should have been created by udev but it was not found. Falling back to direct link creation.
The link /dev/s02_crypt/Deb-Buster_v10-Racine should have been created by udev but it was not found. Falling back to direct link c
reation.
The link /dev/s02_crypt/Deb-Buster_v10-usr should have been created by ud ev but it was not found. Falling back to direct link crea
tion.
The link /dev/s02_crypt/Deb-Buster_v10-var should have been created by ud ev but it was not found. Falling back to direct link crea
tion.
:/# cd dev/
:/dev# ls
console fd full mapper null ptmx pts random s02_crypt shm stderr stdin stdout tty urandom zero
:/dev# ls mapper/
control s02_crypt-Deb--Buster_v10--Racine s02_cryp t-Deb--Stretch_v9--Racine s02_crypt-home s02_crypt-tmp
s02_boot-Deb--Buster_10--boot s02_crypt-Deb--Buster_v10--usr s02_cryp t-Deb--Stretch_v9--usr s02_crypt-root sda5_crypt
s02_boot-Deb--Stretch_v9--boot s02_crypt-Deb--Buster_v10--var s02_cryp t-Deb--Stretch_v9--var s02_crypt-swap
:/dev#
Bon, il est tard et on verra ça demain. Bonne nuit à tous.

-1 Répondre en citant

Pascal Hambourg

Le 16/12/2019 à 20:46 #26533251

Le 16/12/2019 à 00:03, a écrit :

Voila, après les chapitres «Détecter les disques» et «partitionner les
disques» de l'installeur, j'avais ça :
:-) ls -1 /dev/mapper/
control
s02_boot-Deb--Buster_10--boot
s02_boot-Deb--Stretch_v9--boot
s02_crypt-Deb--Buster_v10--Racine

(...)

Mais avant, rien n'existait. Je me demande donc, quelles commandes ont
été utilisées par l'installeur pour arriver à ce résultat.

Celles que j'ai mentionnées.

Voire, si je
peux les introduire dans un script afin de l'utiliser en chroot.

Pour quoi faire ?

Je dois préciser que tous les groupes et volumes logiques ont été créés
_avant_ l'utilisation de l'installeur, via ma distro en production.

C'est faux. Un des PV est un volume chiffré, et comme on l'a vu
l'installateur ne sait pas ouvrir les volumes chiffrés préexistants.
Donc il ne peut pas avoir activé les volumes logiques d'un PV chiffré
préexistant.

En résumé, je cherche à «activer manuellement» les volumes logiques pour
peupler /dev/mapper/.

Pour quoi faire puisque l'installateur le fait déjà automatiquement ?

Il doit exister une commande LVM pour ça, mais
laquelle ?

vgchange -ay

-1 Répondre en citant

Poster une réponse