Accès partition LVM LUKS mode rescue

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 :confused:

Merci d’avance si quelqu’un a une piste

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:

swappoff all
swapon <mon device lvm de swap>

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é)

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.

Un extrait n’est pas suffisant. Merci de poster la sortie complète.

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

Ç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.

Merci pour ton intérêt à mon problème

faute de copier/coller :smirk:
j’aurai dû mieux relire

mount: /mnt/mainRoot: special device /dev/mapper/mainRoot does not exist.

c’est le bon message d’erreur

lsblk complet

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

/dev/sdc: open failed: No medium found

retour de vgs

/dev/sdc: open failed: No medium found

retour de lvs

/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

Merci pour l’info

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

Ç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.

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.

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.

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 :yum:

lsblk
lsblk

lsusb
lsusb

cryptsetup
mount

Merci quand même

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.

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

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 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.

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

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é :pensive:
merci de ta patience

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/

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/ implique pouvoir accéder à un seconde console ce que IPMI ne permet apparement pas.

Lors de l’installation ? L’installateur dispose de 2 consoles virtuelles tty2 et tty3 accessibles avec Ctrl+Alt+F2 et F3.

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

edit: je viens d réessayer c’est passé
Merci je continue

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.

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 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

blkid donne
image

lsblk n’est pas dispo et pas installable on dirait

Les partition préparées avec Gparted avant installation
image

nvme0n1p2 est une grappe RAID1 soft, nvme0n1p3 en est une autre

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 ]

Non. Ou alors il faut vraiment le faire exprès. En tout cas l’installateur ne le fait pas.

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 ?

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/

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