# 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:** 2
**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, 12:08 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/21 "2022-07-29T12:08:38Z")
> [@Nackir](#): > > 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 Je pense que c’est trop tôt pour que le RAID soit activé. Il faut au moins attendre la détection des disques, sinon le partitionneur. > [@Nackir](#): > > apt et apt-get ne sont pas dispo sur la console de l’installeur Pourquoi as-tu besoin d’apt-get ? Mon avis : ne cherche pas à chiffrer /boot lors de l’installation. Tu vas t’embêter pour rien, il vaut mieux le faire après. ---
**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, 12:23 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/22 "2022-07-29T12:23:09Z")
apt et apt-get c’était pour avoir les commandes mdadm et lsblk par exemple mais je dois être à coté de la plaque du coup en effet je me disais que j’allais recommencer et chiffrer /boot après mais je me dis que ce qui complique c’est la présence du RAID1 car dans l’article que je suis pour chiffrer /boot après install, l’auteur n’utilise pas de RAID1 soft en tous cas Quoiqu’il en soit merci pour votre intérêt et je ne pense pas en rajouter aujourd’hui 🤞 le temps de digérer [https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html](https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html) pour le mettre en application je pense que cela me prendra plus que l’apm 😅 Mon partitionnement sachant que sda et sdb sont des disques SATA qui ne contiendront pas le système le départ du problème… ![partitions1](https://www.debian-fr.org/uploads/default/original/2X/7/714d16654753d592a1a191e35ceb7bde7f19aa38.png) ![partitions2](https://www.debian-fr.org/uploads/default/original/2X/5/51440f8520b1d4db31fd63687bf0588e563f5af0.png) dans main (/dev/md126) je crée 3 LV pour / , /home et une swap ---
**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, 12:44 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/23 "2022-07-29T12:44:50Z")
> [@Nackir](#): > > apt et apt-get c’était pour avoir les commandes mdadm et lsblk lsblk n’est pas disponible dans l’installateur. Pour mdadm, si tu ne peux pas attendre les étapes suivantes pour qu’il soit disponible tu peux exécuter ``` anna-install mdadm-udeb ``` Tu auras peut-être besoin d’installer le paquet md-modules-5.10.0-16-amd64-di (ajuster à la version du noyau de l’installateur) s’il ne l’est pas déjà. Et peut-être exécuter `depmod` ensuite pour que les modules soient utilisables avec modprobe. > [@Nackir](#): > > je me dis que ce qui complique c’est la présence du RAID1 Et cela complique d’autant plus lors de l’installation. Après l’installation, je ne vois pas trop pourquoi ça compliquerait, il devrait suffire d’adapter la procédure aux noms de périphériques utilisés. Mais je ne l’ai pas lue. Et la touche finale, ce sera la mise en place de la redondance pour l’amorçage EFI. Je te souhaite bien du plaisir. ---
**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, 3:12 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/24 "2022-07-29T15:12:12Z")
> [@Nackir](#): > > Je suis bien dans l’installeur > j’essaie de suivre ce qui est indiqué dans cet article pour obtenir mon /boot chiffré > [Installing Debian on Existing Encrypted LVM - Blake Carpenter](https://www.blakehartshorn.com/installing-debian-on-existing-encrypted-lvm/) mauvaise idée, ce type d’installation c’est bien quand tu es un expert sinon tu t’engages dans un chemin dont tu ne verras pas la fin. En fait, tu t’embêtes pour rien. perso je fais une installation normale chifrée avec tous qui va bien sur un disque. ensuite sur l’autre disque je créée le premier node du raid en lui specifiant que l’autre noeud est inactif. Puis je déplace ce qui est sur le premier disque sur le deuxième disque (noeud 1 du raid) Ensuite je definie le second noeud du raid, et je laisse faire le Raid pour synchroniser les deux noeud. ne reste plus qu’a s’assurer que le bootloader pointe corectement Certes c’est une méthode qui est à l’origine utilisée pour passer d’une machine sans raid à une machine en raid 1 Pour le EFI ca marche sns soucis, mais il te faut une grappe raid pour l’efi et une autre pour le reste ---
**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, 3:32 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/25 "2022-07-29T15:32:11Z")
> [@Zargos](#): > > En fait, tu t’embêtes pour rien. Là, nous sommes d’accord. > [@Zargos](#): > > perso je fais une installation normale chifrée avec tous qui va bien sur un disque. > ensuite sur l’autre disque je créée le premier node du raid en lui specifiant que l’autre noeud est inactif. > Puis je déplace ce qui est sur le premier disque sur le deuxième disque (noeud 1 du raid) > Ensuite je definie le second noeud du raid, et je laisse faire le Raid pour synchroniser les deux noeud. Là par contre, je trouve que ça complique inutilement. Je ne vois aucune raison de ne pas faire l’installation initiale directement en RAID. > [@Zargos](#): > > Pour le EFI ca marche sns soucis, mais il te faut une grappe raid pour l’efi Là non plus je ne suis pas d’accord. Une partition EFI en RAID c’est loin d’être sans souci pour une raison simple : l’EFI ne reconnaît pas le format RAID logiciel de Linux. ---
**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, 3:43 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/26 "2022-07-29T15:43:04Z")
> [@PascalHambourg](#): > > Là par contre, je trouve que ça complique inutilement. Je ne vois aucune raison de ne pas faire l’installation initiale directement en RAID. Oui aussi je viens de le faire vite fait sur une VM Virtualbox entre mon message precedent et celui-ci (VM non EFI par contre). > [@PascalHambourg](#): > > Là non plus je ne suis pas d’accord. Une partition EFI en RAID c’est loin d’être sans souci pour une raison simple : l’EFI ne reconnaît pas le format RAID logiciel de Linux. j’ai une machine EFI avec un disque 1To NVME et 1 To SSD qui est en raid et qui tourne très bien depuis au moins un an. ```auto root@dsrvbull01:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931,5G 0 disk ├─sda1 8:1 0 285M 0 part │ └─md0 9:0 0 284,9M 0 raid1 /boot/efi └─sda2 8:2 0 931,2G 0 part └─md1 9:1 0 931,1G 0 raid1 ├─BULL01VG01-swap 253:0 0 7,4G 0 lvm [SWAP] ├─BULL01VG01-root 253:1 0 23,3G 0 lvm / ├─BULL01VG01-home 253:2 0 4,7G 0 lvm /home ├─BULL01VG01-var 253:3 0 43,3G 0 lvm /var ├─BULL01VG01-tmp 253:4 0 1,9G 0 lvm /tmp ├─BULL01VG01-varlog 253:5 0 14,3G 0 lvm /var/log ├─BULL01VG01-varlogaudit 253:6 0 4,7G 0 lvm /var/log/audit └─BULL01VG01-vartmp 253:7 0 1,9G 0 lvm /var/tmp nvme0n1 259:0 0 931,5G 0 disk ├─nvme0n1p1 259:1 0 285M 0 part │ └─md0 9:0 0 284,9M 0 raid1 /boot/efi └─nvme0n1p2 259:2 0 931,2G 0 part └─md1 9:1 0 931,1G 0 raid1 ├─BULL01VG01-swap 253:0 0 7,4G 0 lvm [SWAP] ├─BULL01VG01-root 253:1 0 23,3G 0 lvm / ├─BULL01VG01-home 253:2 0 4,7G 0 lvm /home ├─BULL01VG01-var 253:3 0 43,3G 0 lvm /var ├─BULL01VG01-tmp 253:4 0 1,9G 0 lvm /tmp ├─BULL01VG01-varlog 253:5 0 14,3G 0 lvm /var/log ├─BULL01VG01-varlogaudit 253:6 0 4,7G 0 lvm /var/log/audit └─BULL01VG01-vartmp 253:7 0 1,9G 0 lvm /var/tmp ``` ---
**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, 4:04 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/27 "2022-07-29T16:04:13Z")
> [@Zargos](#): > > En fait, tu t’embêtes pour rien. 😅 Ben je ne sais pas comment au faire au plus simple, enfin je ne savais pas merci pour les partages d’infos Je veux absolument pouvoir chiffrer /boot car un admin d’un ancien boulot le seul où 80% du parc était sous GNU/Linux (postes de travail et serveurs) et je l’ai lu dans un post sur debian-fr , disaient que c’est le seul moyen de rendre la machine totalement secure face à un accès physique. Je ne parle pas d’un « piratage » par le réseau machine allumée comme on n’a pas pu me « vanter le manque d’intérêt » de chiffrer un serveur. > [@Zargos](#): > > Oui aussi je viens de le faire vite fait sur une VM Virtualbox entre mon message precedent et celui-ci (VM non EFI par contre). double 😅 moi qui me disait je devrais tester sur une VM… mais je ne suis pas sûr de pouvoir le faire en 30min > [@Zargos](#): > > j’ai une machine EFI avec un disque 1To NVME et 1 To SSD qui est en raid et qui tourne très bien depuis au moins un an. donc sur ta machine /boot est chiffrée dans le RAID principal et avec une autre grappe RAID pour /boot/efi ? non chiffrée? > [@Zargos](#): > > mauvaise idée, ce type d’installation c’est bien quand tu es un expert sinon tu t’engages dans un chemin dont tu ne verras pas la fin. le fait de vouloir chiffrer /boot? ou la méthode pour y arriver? ---
**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, 4:07 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/28 "2022-07-29T16:07:56Z")
> [@Nackir](#): > > donc sur ta machine /boot est chiffrée dans le RAID principal et avec une autre grappe RAID pour /boot/efi ? non chiffrée? Non tu ne peux pas avoir un /boot chiffré sur une machine EFI à cause de l’EFI > [@Nackir](#): > > le fait de vouloir chiffrer /boot? ou la méthode pour y arriver? Le tuto que tu as pris 🙂 ---
**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, 6:39 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/29 "2022-07-29T18:39:47Z")
> [@Zargos](#): > > j’ai une machine EFI avec un disque 1To NVME et 1 To SSD qui est en raid et qui tourne très bien Je ne conteste pas que ça peut marcher (je l’ai fait aussi) mais seulement que c’est « sans souci ». Tu as mis /boot/efi dans un ensemble RAID. Cela pose deux problèmes : 1. L’amorçage UEFI ne supporte pas le format du RAID logiciel de Linux. Il ne supporte qu’une partition FAT normale. Pour faire passer une partition membre RAID pour une partition EFI normale, il faut : - que ce soit du RAID 1 « miroir ». Tout autre type de RAID est incompatible. - que l’ensemble RAID soit en version 0.90 (obsolète) ou 1.0 afin que les métadonnées RAID soit placées à la fin des membres RAID et ne gênent pas. Or par défaut un ensemble RAID est créé en version 1.2 avec les métadonnées au début, ce qui empêche d’utiliser les partitions comme des partitions normales non RAID, et ça ne peut pas se changer sans détruire l’ensmble RAID et son contenu. Il faut donc créer l’ensemble RAID manuellement avec mdadm et l’option --metadata=1.0. - Que les partition aient le type « EFI » et non le type « RAID ». 1. grub-install ne peut pas enregistrer GRUB dans les variables de boot EFI si /boot/efi n’est pas une partition normale. Il faut donc soit créer les variables de boot EFI (une pour chaque partition) à la main avec efibootmgr, soit ne pas utiliser de variable de boot EFI et installer GRUB dans le « chemin de support amovible » de la « partition » EFI. Je privilégie la seconde approche, plus sûre à mon avis car ne reposant pas sur les variables de boot EFI que je considère comme peu fiables. > [@Nackir](#): > > Je veux absolument pouvoir chiffrer /boot car un admin d’un ancien boulot le seul où 80% du parc était sous GNU/Linux (postes de travail et serveurs) et je l’ai lu dans un post sur debian-fr , disaient que c’est le seul moyen de rendre la machine totalement secure face à un accès physique. Je vais te décevoir : ce n’est ni nécessaire ni suffisant. N’oublie pas que GRUB lui-même qui se trouve dans la partition EFI ne peut pas être chiffré. On peut donc lui faire charger un autre noyau (qui doit être signé si le secure boot est activé) ou initramfs (non vérifié par même avec le secure boot). ---
**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, 6:59 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/30 "2022-07-29T18:59:09Z")
Je m’apprêtais à écrire quand une notif m’a signalé ta réponse 😢 Je me disais que j’allais me lancer dans l’install avec boot legacy mais finalement au niveau que je recherche, /boot chiffré ou non c’est la même car sans /boot chiffré j’y étais arrivé là où je me suis mis dans le pétrin c’est lorsque j’ai voulu ajouter au démarrage le montage du 3e RAID qui ne sert que de stockage sans OS qui lui aussi est chiffré je veux être sûr qu’à ma mort on ne retrouvera pas mes sex-tape sur mon serveur 😋 Plaisanterie mise à part Mon objectif est de transférer mon actuel nextcloud qui est sur une autre machine qui n’a pas la même config que celle-ci et sur laquelle je me suis contenté d’installer proxmox et chiffrer les VM mais c’est la croix et la bannière à chaque nécessité de reboot d’une VM (pb de clavier US-FR notamment) je voulais monter d’un cran la sécurité ou la protection de mes données et me faciliter la vie sur le long terme… > [@PascalHambourg](#): > > Je vais te décevoir : ce n’est ni nécessaire ni suffisant. N’oublie pas que GRUB lui-même qui se trouve dans la partition EFI ne peut pas être chiffré. On peut donc lui faire charger un autre noyau (qui doit être signé si le secure boot est activé) ou initramfs (non vérifié par même avec le secure boot). en fin de compte retour à la case départ mais cette fois sans oublier crypttab au moment de l’ ajout de mon espace de « datas » pour le montage au boot. Merci à vous 😀 ---
**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, 8:07 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/31 "2022-07-29T20:07:51Z")
> [@Nackir](#): > > je voulais monter d’un cran la sécurité ou la protection de mes données et me faciliter la vie sur le long terme… La sécurité implique de se compliquer la vie, on ne peut pas la simplifier avec. Le chiffrage d’un disque c’est uniquement pour le cas où quelqu’un récupère le disque. Çà n’a pas d’impact sur l’accès distant. Personnellement les seules machines chiffrées sont des VM qui ne sont jamais online. Je les allume quand j’en ai besoin je les éteint ensuite. Donc quelqu’un ayant accès à celle-ci devra d’abord avoir accès au Host, ensuite il devra pouvoir dechiffrer et c’est là que son problème commence, il n’aura pas le mot de passe qui fait plus de 20 caractères. De plus la machine n’etant pas fonctionnellement necessaire d’etre accessible à distance, il ne pourra pas y acceder à distance non plus. J’ajouterais que pour sécuriser vraiment cela necessite du matériel, comme des équivalent des puces titan sur les smartphone. ---
**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:19 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/32 "2022-07-29T23:19:14Z")
> [@Nackir](#): > > Je me disais que j’allais me lancer dans l’install avec boot legacy mais finalement au niveau que je recherche, /boot chiffré ou non c’est la même En effet ça ne fait pas de différence vis-à-vis du chiffrement. Par contre ça simplifie grandement la redondance de l’amorçage puisqu’il est possible de configurer grub-pc pour installer le chargeur dans le MBR de chaque disque alors que grub-efi-amd64 n’a pas d’option équivalente pour installer le chargeur dans plusieurs partitions EFI. ---
**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 30, 2022, 6:08 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/33 "2022-07-30T06:08:27Z")
> [@Zargos](#): > > La sécurité implique de se compliquer la vie, on ne peut pas la simplifier avec. c’est vrai, là je pensais au fait de devoir déchiffrer chaque VM face à déchiffrer le disque du serveur une bonne fois pour toute > [@Zargos](#): > > Le chiffrage d’un disque c’est uniquement pour le cas où quelqu’un récupère le disque. Çà n’a pas d’impact sur l’accès distant. Oui j’en ai tout à fait conscience et comme il s’agit d’un serveur quelque part en France, je trouvais pertinent de chiffrer les disques (mode paranoïd) > [@PascalHambourg](#): > > Par contre ça simplifie grandement la redondance de l’amorçage puisqu’il est possible de configurer grub-pc pour installer le chargeur dans le MBR de chaque disque alors que grub-efi-amd64 n’a pas d’option équivalente pour installer le chargeur dans plusieurs partitions EFI. Merci pour l’info car je ne le savais pas c’est une option que j’envisageais, cela va m’éviter encore de reprendre à zéro quand je m’en serai rendu compte plus tard… Heureusement j’ai fait un break hier soir et rien réinstallé ---
**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:** [Août 9, 2022, 2:54 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/34 "2022-08-09T14:54:24Z")
Bonjour Je reviens d’abord remercier pour l’aide qui m’a été apportée pour arriver à mes fins et continuer l’histoire 🙂 après un petit break de qq jours, j’ai repris là où j’en étais (à savoir au point de départ)… J’ai refait l’installation en legacy boot, grappe soft RAID1 pour `/boot` et une autre grappe soft RAID1 chiffrée qui contient les volumes LVM qui m’intéressent. J’ai dû créer une partition bios-grub de 1Mo, la table de partition des disques étant GPT et je me demandais s’il y avait une utilité à avoir une partition EFI? Car elle ne devrait servir que si le serveur boot en EFI!? Je m’attaque au montage lors du boot d’une autre partition chiffrée et en soft RAID1 mais j’ai l’impression qu’il faut passer par un fichier si on utilise la passphrase. Il n’est pas possible de saisir cette passphrase au boot comme pour la partition système, sachant que les deux passphrases sont différentes? Une dernière question, sur les KVM ip c’est la galère pour le clavier lorsque notre config est en français sur le pc « qui prend la main ». Comment faites-vous à part prendre un clavier US? Merci d’avance. ---
**Author:** ![Archinformatique](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/e19b73/32.png) [@Archinformatique](https://www.debian-fr.org/u/Archinformatique)\ **Post date:** [Août 9, 2022, 4:48 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/35 "2022-08-09T16:48:28Z")
> [@Nackir](#): > > Une dernière question, sur les KVM ip c’est la galère pour le clavier lorsque notre config est en français sur le pc « qui prend la main ». > Comment faites-vous à part prendre un clavier US? As-tu essayé de changer la configuration du clavier ``` apt update & apt install keyboard-configuration ``` Puis exécuter la commande suivante ``` dpkg-reconfigure keyboard-configuration ``` ---
**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:** [Août 9, 2022, 5:59 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/36 "2022-08-09T17:59:35Z")
> [@Nackir](#): > > J’ai dû créer une partition bios-grub de 1Mo, la table de partition des disques étant GPT Une sur chaque disque, avec installation de GRUB dans le MBR des deux disques pour assurer la redondance de l’amorçage ? > [@Nackir](#): > > je me demandais s’il y avait une utilité à avoir une partition EFI? Car elle ne devrait servir que si le serveur boot en EFI!? Une partition EFI (une par disque pour un amorçage redondant, mais c’est une autre histoire) ne sert que pour l’amorçage EFI, mais l’avoir en réserve peut être utile dans l’éventualité où il faudrait passer l’amorçage en mode EFI, par exemple pour bénéficier du secure boot ou je ne sais quelle autre fonctionnalité, ou s’il fallait remplacer la carte mère par un modèle qui ne supporte pas l’amorçage legacy. > [@Nackir](#): > > Je m’attaque au montage lors du boot d’une autre partition chiffrée et en soft RAID1 mais j’ai l’impression qu’il faut passer par un fichier si on utilise la passphrase. Il n’est pas possible de saisir cette passphrase au boot comme pour la partition système, sachant que les deux passphrases sont différentes? Ça dépend de ce qu’on met dans le 3e champ (key file) de /etc/crypttab. Avec `none`, la passphrase est demandée interactivement lors de l’activation du volume chiffré. Si plymouth est installé et si les deux volumes chiffrés ont la même passphrase, alors elle ne sera demandée qu’une fois. ---
**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:** [Août 10, 2022, 10:38 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/37 "2022-08-10T10:38:19Z")
> [@Archinformatique](#): > > As-tu essayé de changer la configuration du clavier > > ```auto > apt update & apt install keyboard-configuration > > ``` > > Puis exécuter la commande suivante > > ```auto > dpkg-reconfigure keyboard-configuration > > ``` Quitte à paraître idiot, tu parles de la config du clavier du serveur? > [@PascalHambourg](#): > > Une sur chaque disque, avec installation de GRUB dans le MBR des deux disques pour assurer la redondance de l’amorçage ? Seule la redondance de grub n’est pas encore faite, c’est sur la todo… 😅 > [@PascalHambourg](#): > > Une partition EFI (une par disque pour un amorçage redondant, mais c’est une autre histoire) ne sert que pour l’amorçage EFI, mais l’avoir en réserve peut être utile dans l’éventualité où il faudrait passer l’amorçage en mode EFI, par exemple pour bénéficier du secure boot ou je ne sais quelle autre fonctionnalité, ou s’il fallait remplacer la carte mère par un modèle qui ne supporte pas l’amorçage legacy. Merci pour cette source de connaissance 😀 > [@PascalHambourg](#): > > Ça dépend de ce qu’on met dans le 3e champ (key file) de /etc/crypttab. Avec `none` , la passphrase est demandée interactivement lors de l’activation du volume chiffré. > Si plymouth est installé et si les deux volumes chiffrés ont la même passphrase, alors elle ne sera demandée qu’une fois. J’ai testé avec `none`, la passphrase est demandée mais je passe systématiquement sur le mode de secours du coup je l’ai mis en place avec fichier. Je pense que la config clavier IPMI y est pour qqchose, j’y reviendrai ---
**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:** [Août 11, 2022, 6:29 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/38 "2022-08-11T06:29:07Z")
> [@Nackir](#): > > Je pense que la config clavier IPMI y est pour qqchose Comment fais-tu pour taper la passphrase du volume principal ? ---
**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:** [Août 11, 2022, 8:07 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/39 "2022-08-11T08:07:56Z")
> [@PascalHambourg](#): > > Comment fais-tu pour taper la passphrase du volume principal ? Là je dois mon salut au dieu du coup de bol, j’ai activé une deuxième config clavier sur un PC sous windows à la maison que je passe en anglais US et en testant la saisie dans le champs login au démarrage du serveur, je me suis rendu compte que la 1ère passphrase ne comporte que des caractères qui passe et en français et en anglais. J’ai pensé à changer la passphrase mais ce n’est pas vraiment une solution… ---
**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:** [Août 11, 2022, 8:14 UTC](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872/40 "2022-08-11T08:14:21Z")
Si, ça peut être une solution. Il faut seulement rallonger la passphrase pour qu’elle soit aussi robuste. Ça n’a guère de sens de mettre une passphrase « faible » pour le volume principal et une passphrase « forte » pour le volume secondaire si cette dernière est stockée dans un fichier du volume principal. [Page précédente](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872.md?page=1) [Page suivante](https://www.debian-fr.org/t/acces-partition-lvm-luks-mode-rescue/86872.md?page=3)