# Accès partition LVM LUKS mode rescue **URL:** \ **Category:** Support Debian\ **Created:** [Juillet 28, 2022, 11:24 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872 "2022-07-28T11:24:57Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Nackir](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nackir/32/12133_2.png) [@Nackir](https://www.debian-fr.org/u/Nackir)\ **Post date:** [Juillet 28, 2022, 11:24 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/1 "2022-07-28T11:24:57Z")
Bonjour, je me suis lancé dans l’installation d’un serveur dédié avec debian en soft RAID1 sur deux disques nvme, partitionné avec lvm et chiffré avec LUKS. J’ai fait une ânerie un fois l’installation complète qui bootait sans problème en voulant ajouter à fstab une second grappe soft raid 1 chiffrée. Je n’ai pas renseigné crypttab du coup game over ne reboot pas et comme je n’ai pas activer le compte root la console ne se lance pas. Depuis le mode rescue je n’arrive pas à monter mes partitions. Un peu d’infos: un extrait de lsblk ``` nvme0n1 259:0 0 477G 0 disk ├─nvme0n1p1 259:1 0 123M 0 part ├─nvme0n1p2 259:2 0 246M 0 part │ └─md127 9:127 0 245M 0 raid1 └─nvme0n1p3 259:3 0 476.6G 0 part └─md126 9:126 0 476.5G 0 raid1 nvme1n1 259:4 0 477G 0 disk ├─nvme1n1p1 259:5 0 123M 0 part ├─nvme1n1p2 259:6 0 246M 0 part │ └─md127 9:127 0 245M 0 raid1 └─nvme1n1p3 259:7 0 476.6G 0 part └─md126 9:126 0 476.5G 0 raid1 ``` c’est md126 qui m’intéresse pour pouvoir modifier fstab ``` cryptsetup luksOpen /dev/md126 md126_crypt ``` me rend la main sans erreur et j’ai cru comprendre qu’il fallait « activer LVM » pour monter les partitions, j’ai essayé ``` vgchange -ay ``` et ``` vgchange --activate y ``` cela me retourne ``` /dev/sdc: open failed: No medium found ``` alors qu’il n’y a pas de /dev/sdc si je fais ``` mkdir /mnt/mainRoot mount /dev/md126 /mnt/mainRoot ``` cela retourne ``` mount: /mnt/mainRoot: unknown filesystem type 'crypto_LUKS'. ``` et ``` mount /dev/mapper/md126_crypt /mnt/mainRoot ``` retourne ``` mount /dev/mapper/md126_crypt /mnt/mainRoot ``` j’y suis depuis hier matin 😕 Merci d’avance si quelqu’un a une piste ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Juillet 28, 2022, 1:00 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/2 "2022-07-28T13:00:02Z")
Salut, Normalement, dans le rescue, tu donne ton root. Pour monter cette partition, il va te demander ce qu’il faut. Une fois dans le shell rescue, il ne te reste plus qu’à monter toutes les partitions necessaires sans oublier le swap le cas echant avec: ```auto swappoff all swapon ``` ---
**Author:** ![Nackir](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nackir/32/12133_2.png) [@Nackir](https://www.debian-fr.org/u/Nackir)\ **Post date:** [Juillet 28, 2022, 2:53 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/3 "2022-07-28T14:53:15Z")
Salut merci pour ton aide je me suis mal exprimé, je en suis pas dans le mode rescue de mon installation, j’ai booté le serveur en mode rescue depuis l’interface de gestion (donc un OS en RAM en fait) le mode rescue de l’install (recovery mode ) ne me donne pas la main non plus (compte root désactivé) ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Juillet 28, 2022, 3:15 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/4 "2022-07-28T15:15:03Z")
> [@Nackir](#): > > compte root désactivé) Avoir un compte root désactivé, c’est toujours une mauvaise idée. D’ailleurs, dans le monde professionnel personne ou presque ne le fait. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juillet 28, 2022, 5:38 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/5 "2022-07-28T17:38:54Z")
> [@Nackir](#): > > un extrait de lsblk Un extrait n’est pas suffisant. Merci de poster la sortie complète. > [@Nackir](#): > > ```auto > /dev/sdc: open failed: No medium found > > ``` > > alors qu’il n’y a pas de /dev/sdc vgchange n’invente pas des périphériques inexistants. Il y a forcément un /dev/sdc, peut-être un lecteur de carte mémoire vide connecté en USB (bizarre pour un serveur dédié mais pourquoi pas). De toute façon ça n’impacte pas forcément le résultat de la commande. Qu’affichent ``` pvs vgs lvs ``` > [@Nackir](#): > > ```auto > mount /dev/mapper/md126_crypt /mnt/mainRoot > > ``` > > retourne > > ```auto > mount /dev/mapper/md126_crypt /mnt/mainRoot > > ``` Ça m’étonnerait. Si le volume chiffré contient un volume physique LVM, il devrait y avoir une erreur similaire à la précédente mais avec « LVM2\_member » au lieu de « crypto\_LUKS ». PS: si /dev/md127 est censé être monté sur /boot, 250 Mo risquent d’être un peu étroits à l’usage quand il y aura trois noyaux et leur initramfs présents. ---
**Author:** ![Nackir](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nackir/32/12133_2.png) [@Nackir](https://www.debian-fr.org/u/Nackir)\ **Post date:** [Juillet 28, 2022, 8:53 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/6 "2022-07-28T20:53:57Z")
Merci pour ton intérêt à mon problème > [@Nackir](#): > > ```plaintext > mount /dev/mapper/md126_crypt /mnt/mainRoot > > ``` > > retourne > > ```plaintext > mount /dev/mapper/md126_crypt /mnt/mainRoot > > ``` faute de copier/coller 😏 j’aurai dû mieux relire ```plaintext mount: /mnt/mainRoot: special device /dev/mapper/mainRoot does not exist. ``` c’est le bon message d’erreur `lsblk` complet ```plaintext NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 3.7T 0 disk └─sda1 8:1 0 3.7T 0 part └─md125 9:125 0 3.7T 0 raid1 sdb 8:16 0 3.7T 0 disk └─sdb1 8:17 0 3.7T 0 part └─md125 9:125 0 3.7T 0 raid1 nvme0n1 259:0 0 477G 0 disk ├─nvme0n1p1 259:1 0 123M 0 part ├─nvme0n1p2 259:2 0 246M 0 part │ └─md127 9:127 0 245M 0 raid1 └─nvme0n1p3 259:3 0 476.6G 0 part └─md126 9:126 0 476.5G 0 raid1 nvme1n1 259:4 0 477G 0 disk ├─nvme1n1p1 259:5 0 123M 0 part ├─nvme1n1p2 259:6 0 246M 0 part │ └─md127 9:127 0 245M 0 raid1 └─nvme1n1p3 259:7 0 476.6G 0 part └─md126 9:126 0 476.5G 0 raid1 ``` retour de `pvs` ```plaintext /dev/sdc: open failed: No medium found ``` retour de `vgs` ```plaintext /dev/sdc: open failed: No medium found ``` retour de `lvs` ```plaintext /dev/sdc: open failed: No medium found ``` bien évidemment je suis connecté en root sur la rescue Pour /boot que conseilles-tu comme taille je me suis inspiré d’un exemple vu sur stackoverflow Dans mes recherches à résoudre mon problème j’ai lu que grub lisait maintenant /boot chiffrée je voulais tester mais j’ai besoin de comprendre ce qui ne va pas pour améliorer mes connaissances en cas de souci ---
**Author:** ![Nackir](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nackir/32/12133_2.png) [@Nackir](https://www.debian-fr.org/u/Nackir)\ **Post date:** [Juillet 28, 2022, 8:57 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/7 "2022-07-28T20:57:43Z")
Merci pour l’info > [@Zargos](#): > > Avoir un compte root désactivé, c’est toujours une mauvaise idée. > D’ailleurs, dans le monde professionnel personne ou presque ne le fait. C’est noté je croyais que c’était bon en terme de surface d’attaque Bon c’est perso ce serveur mais c’est bon à savoir dans les boulots que j’ai fait, sont rarement orientés linux je pense me refaire l’install mais comprendre comment me dépanner dans ce genre de galère est important pour moi ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juillet 28, 2022, 9:46 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/8 "2022-07-28T21:46:49Z")
> [@Nackir](#): > > c’est le bon message d’erreur Ça m’étionnerait. Je ne vois pas comment une commande de montage du périphérique /dev/mapper/md126\_crypt pourrait retourner un message concernant un périphérique /dev/mapper/mainRoot. Ça sent la confusion entre le périphérique et le point de montage dans la commande saisie qui n’est pas celle que tu as montrée. > [@Nackir](#): > > lsblk complet En format code pour la lisibilité stp. Le volume chiffré n’est pas ouvert, dans ces conditions pas étonnant que les commandes LVM ne retournent rien. ---
**Author:** ![Nackir](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nackir/32/12133_2.png) [@Nackir](https://www.debian-fr.org/u/Nackir)\ **Post date:** [Juillet 29, 2022, 5:24 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/9 "2022-07-29T05:24:52Z")
> [@PascalHambourg](#): > > Ça m’étionnerait. Je ne vois pas comment une commande de montage du périphérique /dev/mapper/md126\_crypt pourrait retourner un message concernant un périphérique /dev/mapper/mainRoot. Ça sent la confusion entre le périphérique et le point de montage dans la commande saisie qui n’est pas celle que tu as montrée. Navré mais c’est le cas, c’est la commande tapée et c’est le retour obtenu, une erreur de copier/coller d’accord pour retranscrire ce qui se passe m’a amener quand même à revérifier le reste de ce qui a été écrit et comme je l’ai indiqué dans message d’origine ``` cryptsetup luksOpen /dev/md126 md126_crypt ``` me rend la main sans erreur donc pour moi cela veut dire que le volume a été ouvert. S’il existe un autre moyen pour vérifier je ne le connais pas. > [@PascalHambourg](#): > > En format code pour la lisibilité stp. Je ne comprends pas en format code le retour de commande apparait bien sur fond grisé? je le remets ``` NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 3.7T 0 disk └─sda1 8:1 0 3.7T 0 part └─md125 9:125 0 3.7T 0 raid1 sdb 8:16 0 3.7T 0 disk └─sdb1 8:17 0 3.7T 0 part └─md125 9:125 0 3.7T 0 raid1 nvme0n1 259:0 0 477G 0 disk ├─nvme0n1p1 259:1 0 123M 0 part ├─nvme0n1p2 259:2 0 246M 0 part │ └─md127 9:127 0 245M 0 raid1 └─nvme0n1p3 259:3 0 476.6G 0 part └─md126 9:126 0 476.5G 0 raid1 nvme1n1 259:4 0 477G 0 disk ├─nvme1n1p1 259:5 0 123M 0 part ├─nvme1n1p2 259:6 0 246M 0 part │ └─md127 9:127 0 245M 0 raid1 └─nvme1n1p3 259:7 0 476.6G 0 part └─md126 9:126 0 476.5G 0 raid1 ``` Je mets des captures d’écran pour lever ton scepticisme 😋 lsblk ![lsblk](https://www.debian-fr.org/uploads/default/original/2X/4/4948cc560c5ff80d8acc9f0555f5f0af25e735e7.png) lsusb ![lsusb](https://www.debian-fr.org/uploads/default/original/2X/2/2c7fa89c3612ef533e402e1b3fa02872d71a2182.png) cryptsetup ![mount](https://www.debian-fr.org/uploads/default/original/2X/6/6098b6d957ab1abb4fc176b9deb6f214a89ffeb7.png) Merci quand même > [@Nackir](#): > > Pour /boot que conseilles-tu comme taille je me suis inspiré d’un exemple vu sur stackoverflow > Dans mes recherches à résoudre mon problème j’ai lu que grub lisait maintenant /boot chiffrée je voulais tester mais j’ai besoin de comprendre ce qui ne va pas pour améliorer mes connaissances en cas de souci Sinon pas de suggestion pour cette remarque, je me dis que ça serait intéressant si c’est possible de chiffrer /boot et forcément avec une taille adaptée qui m’éviterait des galères chronophages plus tard. ---
**Author:** ![Nackir](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nackir/32/12133_2.png) [@Nackir](https://www.debian-fr.org/u/Nackir)\ **Post date:** [Juillet 29, 2022, 5:36 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/10 "2022-07-29T05:36:48Z")
Désolé pour la réponse longue comme deux bras mais dans la foulée j’ai repassé fdisk pour voir s’il existe un /dev/sdc ``` # fdisk -l Disk /dev/ram0: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram1: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram2: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram3: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram4: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram5: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram6: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram7: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram8: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram9: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram10: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram11: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram12: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram13: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram14: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram15: 50 MiB, 52428800 bytes, 102400 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors Disk model: WDC CL SN720 SDAQNTW-512G-2000 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 73EE3B76-683D-4DEC-B5BF-CE096764A346 Device Start End Sectors Size Type /dev/nvme0n1p1 2048 253951 251904 123M EFI System /dev/nvme0n1p2 253952 757759 503808 246M Linux RAID /dev/nvme0n1p3 757760 1000214527 999456768 476.6G Linux RAID Disk /dev/nvme1n1: 477 GiB, 512110190592 bytes, 1000215216 sectors Disk model: WDC CL SN720 SDAQNTW-512G-2000 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 6D043A9E-DC76-4D82-B564-E4E2C72C0815 Device Start End Sectors Size Type /dev/nvme1n1p1 2048 253951 251904 123M BIOS boot /dev/nvme1n1p2 253952 757759 503808 246M Linux RAID /dev/nvme1n1p3 757760 1000214527 999456768 476.6G Linux RAID Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: HGST HUS726T4TAL Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 5234FF9D-839C-4F83-BA84-E23046E447D9 Device Start End Sectors Size Type /dev/sdb1 2048 7814035455 7814033408 3.7T Linux filesystem Disk /dev/sda: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: HGST HUS726T4TAL Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 3BFA4856-282F-46CB-86AC-24FE430214F0 Device Start End Sectors Size Type /dev/sda1 2048 7814035455 7814033408 3.7T Linux filesystem Disk /dev/md127: 245 MiB, 256901120 bytes, 501760 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/md126: 476.5 GiB, 511586598912 bytes, 999192576 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/md125: 3.7 TiB, 4000649838592 bytes, 7813769216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ``` ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juillet 29, 2022, 8:45 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/11 "2022-07-29T08:45:40Z")
> [@Nackir](#): > > Je mets des captures d’écran pour lever ton scepticisme La dernière copie d’écran montre bien que le retour de la commande mount n’est pas celui qui tu as retranscrit et ne contient pas « /dev/mapper/mainRoot ». De toute façon il n’y a pas lieu d’essayer de monter le volume chiffré s’il ne contient pas un système de fichiers mais un volume physique LVM. > [@Nackir](#): > > ```auto > cryptsetup luksOpen /dev/md126 md126_crypt > > ``` > > me rend la main sans erreur donc pour moi cela veut dire que le volume a été ouvert. En principe oui, mais lsblk ne l’affiche pas donc il y a un souci. L’ouverture devrait entraîner la création par le device-mapper d’un périphérique /dev/dm-\* et d’un lien symbolique /dev/mapper/md126\_crypt qui pointe dessus. Tu peux vérifier la liste des périphériques créés par le device-mapper avec ``` dmsetup ls ``` La présence de dm-\* dans le pseudo-fichier /proc/partitions. La présence de dm-\* dans /sys/block/. Concernant /dev/sdc, vérifier sa présence dans les logs du noyau avec dmesg. S’il n’existe vraiment pas (mais ça m’étonnerait, l’erreur ne serait pas « no medium found »), je répète que LVM ne l’invente pas donc ça vient peut-être de sa configuration, voir dans /etc/lvm/lvm.conf, mais ça m’étonnerait aussi. > [@Nackir](#): > > Sinon pas de suggestion pour cette remarque, je me dis que ça serait intéressant si c’est possible de chiffrer /boot et forcément avec une taille adaptée Pour la taille, 500 Mo devraient être suffisant pour un moment. Chffrer /boot est une galère difficile à faire lors de l’installation. Voir [Full disk encryption, including /boot: Unlocking LUKS devices from GRUB](https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html) ---
**Author:** ![Nackir](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nackir/32/12133_2.png) [@Nackir](https://www.debian-fr.org/u/Nackir)\ **Post date:** [Juillet 29, 2022, 9:06 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/12 "2022-07-29T09:06:17Z")
> [@PascalHambourg](#): > > La dernière copie d’écran montre bien que le retour de la commande mount n’est pas celui qui tu as retranscrit et ne contient pas « /dev/mapper/mainRoot ». De toute façon il n’y a pas lieu d’essayer de monter le volume chiffré s’il ne contient pas un système de fichiers mais un volume physique LVM. En effet au multiples essais je suis passé du mainRoot à md126\_crypt et pas mis la bonne « capture » Mon oeil non aguerri n’y voyant aucune gêne désolé 😔 merci de ta patience > [@PascalHambourg](#): > > Pour la taille, 500 Mo devraient être suffisant pour un moment. > Chffrer /boot est une galère difficile à faire lors de l’installation. Voir [Full disk encryption, including /boot: Unlocking LUKS devices from GRUB](https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html) Dans l’intervalle et la précipitation j’ai relancé l’installation avec /boot chiffré et coller 1Go d’espace, heureusement que ton conseil ne tendait pas au 2Go… J’étais tombé sur la page que tu mets en référence qui m’a effrayée j’ai aussi lu rapidement [https://www.blakehartshorn.com/installing-debian-on-existing-encrypted-lvm/](https://www.blakehartshorn.com/installing-debian-on-existing-encrypted-lvm/) Qui si j’ai bien compris permet de chiffrer /boot post install Je n’ai pas le choix car j’ai tenté la réinstall full chiffrée et me retrouve devant la console grub et ne sait pas encore comment on boot dans ce cas de figure. Pour le reste des commandes que tu me suggères quand j’aurais abouti à une installation fonctionnelle, je regarderai car j’ai besoin de pouvoir être sûr de pouvoir accéder à mes partitions depuis une rescue avant d’y coller touts les données de ma vie Encore merci edit: [https://www.blakehartshorn.com/installing-debian-on-existing-encrypted-lvm/](https://www.blakehartshorn.com/installing-debian-on-existing-encrypted-lvm/) implique pouvoir accéder à un seconde console ce que IPMI ne permet apparement pas. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juillet 29, 2022, 9:29 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/13 "2022-07-29T09:29:28Z")
Lors de l’installation ? L’installateur dispose de 2 consoles virtuelles tty2 et tty3 accessibles avec Ctrl+Alt+F2 et F3. ---
**Author:** ![Nackir](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nackir/32/12133_2.png) [@Nackir](https://www.debian-fr.org/u/Nackir)\ **Post date:** [Juillet 29, 2022, 9:34 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/14 "2022-07-29T09:34:41Z")
Oui mais sur un serveur dédié avec kvm IPMI je n’arrive à ouvrir aucun console soit directement en pressant les touches du clavier soit en utilisant les « boutons » de l’interface IPMI qui propose de maintenir Ctrl et ALT enfoncée petite capture pour être plus clair ![image](https://www.debian-fr.org/uploads/default/original/2X/d/d317c076da0e5a0892f9809dc9b745e71a925115.png) edit: je viens d réessayer c’est passé Merci je continue ---
**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\ **Post date:** [Juillet 29, 2022, 10:00 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/15 "2022-07-29T10:00:14Z")
Bonjour En voyant ta capture d’écran, je constate que tu utilises le mode texte pour l’installation. Quand on est déjà en mode texte, la touche Ctrl n’est pas nécessaire, c’est juste quand le programme d’installation s’affiche en mode graphique que la touche Ctrl est nécessaire. Pour passer d’une console à l’autre quand on est en mode texte, il suffit de maintenir la touche Alt appuyée tout en pressant sur une touche de F2 à F4, Alt+F1 permet d’accéder à la console texte utilisée pour l’affichage des fenêtres de dialogue du programme d’installation, et la console 4, qui est accessible par Alt+F4 depuis le mode texte, affiche d’autres informations intéressantes. ---
**Author:** ![Nackir](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nackir/32/12133_2.png) [@Nackir](https://www.debian-fr.org/u/Nackir)\ **Post date:** [Juillet 29, 2022, 10:22 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/16 "2022-07-29T10:22:24Z")
Oui je ne l’avais jamais fait comme ça auparavant, toujours eu un accès physique à la machine avec écran clavier branché directement dessus Soit j’ai mal pressé le clavier soit je ne sais pas mais devant l’étonnement de # [PascalHambourg](https://www.debian-fr.org/u/PascalHambourg) j’ai ressayé et c’est passé avec le bouton ALT de l’interface + F2 Bon cela dit vu mon expérience avec LVM et LUKS, je me retrouve au même point qu’au début de mon post. je dois déverouiller ma partition qui est /boot « LUKSée » et avec un LV il s’agit de /dev/nvme0n1p2 Dans la seconde console ouverte si je saisis ``` cryptsetup luksOpen /dev/md4 boot-crypt ``` il répond ``` Device /dev/md4 does not exist or access denied ``` alors qu’il censé être celui de /boot ``` cat /proc/mdstat ``` répond ``` cat: can't open '/proc/mdstat': No such fil or directory ``` et ``` cryptsetup luksOpen /dev/nvme0n1p3 crypt-boot ``` répond ``` Device /dev/nvme0n1p3 is not a valid LUKS device ``` j’ai bien fait attention à bien retranscrire fidèlement saisies et retours ![image](https://www.debian-fr.org/uploads/default/original/2X/5/5d4a7dd49927d107eb898217d1c86dfd8cc55b7c.png) blkid donne ![image](https://www.debian-fr.org/uploads/default/original/2X/f/f78e6b597f985f0a97e6f20cf73e960369ecb71d.png) lsblk n’est pas dispo et pas installable on dirait Les partition préparées avec Gparted avant installation ![image](https://www.debian-fr.org/uploads/default/original/2X/d/d509101ac8a3a9e6a398b2dbd5dca10fb893f502.png) nvme0n1p2 est une grappe RAID1 soft, nvme0n1p3 en est une autre ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Juillet 29, 2022, 10:49 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/17 "2022-07-29T10:49:46Z")
> [@PascalHambourg](#): > > > [@Nackir](#): > > > > > ```auto > > > cryptsetup luksOpen /dev/md126 md126_crypt > > > > > > ``` > > > > > > me rend la main sans erreur donc pour moi cela veut dire que le volume a été ouvert. > > En principe oui, mais lsblk ne l’affiche pas donc il y a un souci. L’ouverture devrait entraîner la création par le device-mapper d’un périphérique /dev/dm-\* et d’un lien symbolique /dev/mapper/md126\_crypt qui pointe dessus. Tu peux vérifier la liste des périphériques créés par le device-mapper avec Ca ne peut peut pas marcher car dans la commande c’est le montage raid qui est prix en compte. Normalement sur ce RAID (qui n’est pas une partition) il y a une partition qui est mise en place. C’est cette partition qui est chiffrée, et c’est donc celle ci dont il faut faire l’ouverture luksOpen. En fait le tout est constituée comme ci-après (le niveau le plus bas sur la dernière ligne): [Partitions LVM] [Partition Luks] [RAID md0 | RAID md1] Et qui plus est, avec le fait que le /boot ne peux pas être chiffré, il faut deux raids. [Partitions LVM] [Partition Luks] [RAID md2 | RAID md3] [Partition boot] [RAID md0 | RAID md1] ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juillet 29, 2022, 11:25 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/18 "2022-07-29T11:25:46Z")
> [@Zargos](#): > > Normalement sur ce RAID (qui n’est pas une partition) il y a une partition qui est mise en place. Non. Ou alors il faut vraiment le faire exprès. En tout cas l’installateur ne le fait pas. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juillet 29, 2022, 11:36 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/19 "2022-07-29T11:36:06Z")
> [@Nackir](#): > > `/proc/mdstat': No such fil or directory` Le pilote RAID n’est pas chargé et les ensembles RAID ne sont pas actifs. Dans quel environnement es-tu ? L’installateur ? Dans quel mode ? A quel stade ? ---
**Author:** ![Nackir](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nackir/32/12133_2.png) [@Nackir](https://www.debian-fr.org/u/Nackir)\ **Post date:** [Juillet 29, 2022, 11:50 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/20 "2022-07-29T11:50:01Z")
Je suis bien dans l’installeur j’essaie de suivre ce qui est indiqué dans cet article pour obtenir mon /boot chiffré [https://www.blakehartshorn.com/installing-debian-on-existing-encrypted-lvm/](https://www.blakehartshorn.com/installing-debian-on-existing-encrypted-lvm/) avant la détection de disque je passe sur une autre console et les commandes passées et les résultats de mon dernier post sont dans cette console (avec l’installeur lancé en mode expert lol ) il y a bien deux RAID1 soft je prépare les partitions avec Gparted comme dans la capture que j’ai mise pour avoir la partition de boot EFI je chiffre chaque grappe et ensuite configure LVM, création des vg de chaque RAID et LV ensuite peut-être est-ce incorecte mais avant de vouloir monter une autre grappe RAID1 constituée de deux HDD de 4to sans avoir renseigné crypttab mais fstab oui et laisser /boot sur un RAID1 non chiffré cela bootait et j’avais accès au système Avec /boot chiffré c’est la console grub qui se lance au boot et comme je disais je ne sais pas booter depuis là ou je suis perdu c’est que même si je lui indique une partition à monter après ouverture avec cryptsetup luksOpen cela ne donne rien après j’ai fait des essais qui doivent vous paraitre dingue pour essayer et peut être comprendre ce qui m’échappe sans RAID1 je n’ai jamais connu ce genre de soucis depuis longtemps (travail sur station de travail) apt et apt-get ne sont pas dispo sur la console de l’installeur ce que je ne savais pas il me répond ``` /bin:sh: apt-get (ou apt) : not found ``` vgscan, vgchange -ay, lvs ou lvdisplay me rendent la main sans réponse Merci à vous [Page suivante](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872.md?page=2)