Problème de l'installeur Debian qui ne reconnaît pas les disques cryptés.
7 réponses
moondump
Bonjour =C3=A0 tous,
j'ai pris l'habitude de faire coexister, gr=C3=A2ce =C3=A0 LVM, plusieurs v=
ersions de cette distribution sur une m=C3=AAme station afin de passer sere=
inement d'une version =C3=A0 sa sup=C3=A9rieure. Cela me donne du temps pou=
r configurer la nouvelle.
Il y quelques temps, j'ai d=C3=A9cid=C3=A9 de chiffrer les disques de mes s=
tations. J'ai donc rinc=C3=A9 ceux-ci et j'y ai r=C3=A9install=C3=A9 la der=
ni=C3=A8re version en production (V9, dite Stretch). Tout c'est bien pass=
=C3=A9 et voici ce que cela donne une fois le tout mont=C3=A9 :
=20=20=20
:-) mount | awk '/^\/dev\//' | sort=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20
/dev/mapper/s02_boot-Deb--Stretch_v9--boot on /boot type ext4 (rw,relatime,=
data=3Dordered)
/dev/mapper/s02_crypt-Deb--Stretch_v9--Racine on / type ext4 (rw,relatime,e=
rrors=3Dremount-ro,data=3Dordered)
/dev/mapper/s02_crypt-Deb--Stretch_v9--usr on /usr type ext4 (rw,relatime,d=
ata=3Dordered)
/dev/mapper/s02_crypt-Deb--Stretch_v9--var on /var type ext4 (rw,relatime,d=
ata=3Dordered)
/dev/mapper/s02_crypt-home on /home type ext4 (rw,relatime,data=3Dordered)
/dev/mapper/s02_crypt-root on /root type ext4 (rw,relatime,stripe=3D4,data=
=3Dordered)
/dev/mapper/s02_crypt-tmp on /tmp type ext4 (rw,relatime,data=3Dordered)
:-)
J'esp=C3=A8re que mes r=C3=A8gles de nommage sont assez explicites, =C2=ABs=
02_boot=C2=BB et =C2=ABs02_crypt=C2=BB =C3=A9tant des groupes de volumes. L=
e reste est constitu=C3=A9s des volumes logiques.
Mais, lorsque j'ai voulu installer la version 10, dite =C2=ABBuster=C2=BB, =
quelle ne fut pas ma surprise de constater que l'installeur ne =C2=ABvoyait=
=C2=BB mon disque chiffr=C3=A9 ! Ou plus exactement, le groupe de volumes =
=C2=ABs02_crypt=C2=BB =C3=A0 l'int=C3=A9rieur du disque chiffr=C3=A9.
J'ai donc essay=C3=A9 de contourner la difficult=C3=A9 en passant par le mo=
de expert de l'installeur. Avant le partitionnement, j'ouvre un shell (Dash=
) et j'utilise =C2=ABcryptsetup=C2=BB pour d=C3=A9chiffrer le sda5, qui est=
le volume physique supportant =C2=ABs02_crypt=C2=BB. Je peux alors cr=C3=
=A9er tous les volumes logiques et finir l'installation sans probl=C3=A8me.=
J'ai donc en d=C3=A9finitive :
:-) 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
:-)=20
avec deux magnifiques OS install=C3=A9s aux bons endroits.
Oui mais voila, lors du boot, je tombe sur un os=E2=80=A6 Le noyau se plain=
t de ne pas trouver la partition Racine (s02_crypt-Deb--Buster_v10--Racine).
J'ai compar=C3=A9 les deux initrd.img, et j'ai d'une part pour la premi=C3=
=A8re version :
Je n'ai pas, en autres, de =C2=ABsbin/cryptsetup=C2=BB dans le initrd.img d=
e la version Buster et je pense que le probl=C3=A8me vient de l=C3=A0.
J'ai essay=C3=A9 plusieurs approches techniques, dont un =C2=ABdracut chroo=
t=C3=A9=C2=BB ou avec la possibilit=C3=A9 qu'a Grub de d=C3=A9chiffrer Luks=
1, mais sans succ=C3=A8s pour l'instant. Pas de r=C3=A9sultat non plus en f=
ouillant de l'installeur Debian.
Au d=C3=A9but, j'ai m=C3=AAme tent=C3=A9 l'installation fa=C3=A7on =C2=ABGe=
ntoo=C2=BB, voir https://www.debian.org/releases/stable/amd64/apds03.en.htm=
l, mais sans modification du initrd.img.
Je suis pass=C3=A9 peut =C3=AAtre =C3=A0 cot=C3=A9 d'une solution toute sim=
ple, mais pour l'instant, je tourne en rond.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
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.
Le 10/12/2019 à 18:34, moondump@free.fr 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.
/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.
Pascal Hambourg
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.
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.
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.
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.
Le 14/12/2019 à 18:50, moondump@free.fr 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.
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.
moondump
Pascal Hambourg writes:
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 ?
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
Le 14/12/2019 à 18:50, moondump@free.fr 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 ?
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 ?
Pascal Hambourg
Le 15/12/2019 à 18:21, a écrit :
Pascal Hambourg writes:
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.
Le 15/12/2019 à 18:21, moondump@free.fr a écrit :
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
Le 14/12/2019 à 18:50, moondump@free.fr 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.
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.
moondump
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.
Tiens ! Je viens de faire une trouvaille… :-)
C'est vgmknodes --refresh
root@s02:/# lvdisplay
root@s02:/# 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.
root@s02:/# cd dev/
root@s02:/dev# ls
console fd full mapper null ptmx pts random s02_crypt shm stderr stdin stdout tty urandom zero
root@s02:/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
root@s02:/dev#
Bon, il est tard et on verra ça demain. Bonne nuit à tous.
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.
Pascal Hambourg
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
Le 16/12/2019 à 00:03, moondump@free.fr 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 ?
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 ?
