Étendre système de disques LVM chiffré

Anonymous23 · Juin 16, 2026, 3:34

Bonjour

Il y a quelques temps j’ai configuré un ordi portable sous Debian pour mon activité professionnelle.

De mémoire, j’ai fait sur un disque de 450 Go une partition pour le boot, puis une partition LVM cryptée que j’ouvre après le boot.

Elle contient les partition root, home, swap, data.

Maintenant manquant de place, je rajoute un disque de 1To.

Je voudrais étendre la partition lvm et augmenter chacune des partitions root, home, data.

C’est faisable sans tout casser?

Merci d’avance

Anonymous23 · Juin 16, 2026, 3:45

Si j’en crois

C’est très galère

Peut être mettre mes données sur le deuxième disque chiffré a part? Et étendre root et home?

Zargos · Juin 16, 2026, 4:40

Non pas spécialement, il faut juste être méticuleux. Mais c’est un aspect qui est plutot général en fait.

Pour ce qui est d’ajouter ton disque, c’est simple. Les actions sont:

Tu créées une partition sur ton disque (mais ce n’est pas obligatoire si tu utilises tout le disque)
Tu formates le chiffrement de tout le disque avec cryptsetup luksFormat (attention je te conseille d’utiliser les mêmes paramètres de chiffrement que ton premier disque)
Tu ouvres ta partition chiffrée avec cryptsetup luksOpen attention au nom du device chiffré
Tu créées un nouveau pv sur le device chiffré précédemment ouvert
Tu ajoutes le pv ainsi créé à ton vg
tu étends tes partitions comme tu en as besoin.
Tu ajoutes ce deuxième disque à ton /etc/crypttab
Tu régénères ton initramfs avec update-initramfs -k all -u
Pas besoin de refaire ton grub, mais si ça te rassure tu peux faire un update-grub

Anonymous23 · Juin 16, 2026, 10:42

Bonsoir

Après avoir sauvegardé je me suis lancé.
J’ai suivi tes étapes.
Mais j’ai eu des difficultés : j’ouvre mes deux disques au boot et je tombe dur initramfs

Zargos · Juin 17, 2026, 7:39

Il semble que tu aies un problème de clef sur ton deuxième disque. Celui ne s’est pas ouvert d’où l’échec ensuite du lancement du système.

Avec une debian live essaye de voir si tu peux ouvrir les deux disques chiffrés. Pour être sur des clefs.
Il est possible que le systeme lors de l’ajouet du deuxioème disque ait change le nom d’une partition (le nom du disque en fait) et qu’il y ait un problème de reconnaissance entre le mapper du disque chiffré et le véritable nom du disque lui même. Quand ça arrive, les noms ne correspondent potentiellement plus à ce qu’il y a dans le /etc/crypttab.

C’est un défaut du système. Pour passer outre, j’utilise des noms de mapper qui n’utilisent pas le nom des disques (i.e.: au lieu de /dev/mapper/nvme0n1p2-crypt j’utilise /dev/mapper/toto_crypt).

Anonymous23 · Juin 17, 2026, 8:39

Merci. J’arrive a ouvrir les disques mais un PV du système LVM est inconnu

Zargos · Juin 17, 2026, 8:42

Donnes nous un lsblk -f pour voir les disque et les mappers.

Anonymous23 · Juin 17, 2026, 8:52

J’ai utilisé pvcreate --uuid

Maintenant j’ai

Anonymous23 · Juin 17, 2026, 8:54

Merci pour ton aide en tout cas

Zargos · Juin 17, 2026, 8:57

C’est déjà mieux en effet.

De rien

J’ai fait un script pour faire le taf automatiquement, pour ajouter un second disque chiffré à une configuration d’un seul disque. Mais c’est u npeu chaud, car la moindre erreur plante le système.
De fait, j’utilise des Label pour être de pouvoir identifier le disque si le système le modifie (cryptsetup ne peux pas utiliser les uuid pour toutes les commandes), et j’utilise des noms de mapper non liés aux disque car initramfs y est sensible.

Mais le script n’est pas complètement au point il y a des cas où il ne marche pas comme attendu (quand il y a plus de deux disques par exemple).

En gros, il réalise les actions suivantes:

identification du disque d’installation, et du second disque à ajouter
changement du label du disque 1
changement du label du swap
création de la partition chiffrée sur le disque 2
ouverture de la partition chiffrée du disque 2
mise à jour du fichier /etc/crypttab
extension du LVM avec le mapper de la partition chiffrée du disque 2
update-initramfs

Anonymous23 · Juin 17, 2026, 9:10

Du coup j’ai rebooté, et j’ai eu la même erreur
Puis j’ai fait un

vgchange -ay --partial

exit

J’ai pu démarer sur le système
Une idée de ce que je peux faire pour que l’erreur disparaisse ?

Anonymous23 · Juin 17, 2026, 9:15

Oui un script ca aide bien

Anonymous23 · Juin 17, 2026, 2:38

J’ai bataillé tout l’après-midi, failli bousiller mon système plusieurs fois.

J’ai toujours l’erreur avec le prompt initramfs au démarrage

Je la démarre avec un
vgchange -ya --partial

Je vais essayer de vivre avec en attendant mieux

Anonymous23 · Juin 18, 2026, 3:43

Encore plus étonnant:

Je veux faire un split pour que mon OS soit sur une VG sur un disque et mes data sur une VG sur un autre. Je fais

 sudo blkid
/dev/mapper/essai2: UUID="5RwpwV-o1TI-MIa7-CsP3-gZK7-Oq12-pc8mdW" TYPE="LVM2_member"
/dev/nvme0n1: UUID="0cd5a2ec-c526-4dcc-bdec-35f99a5652e1" TYPE="crypto_LUKS"
/dev/mapper/OS-HOME: UUID="2fcbec43-409f-45b0-a054-e2cf25e25dbd" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/OS-SWAP: UUID="bd0fc753-ba3f-43e9-aeb6-6396a353b79d" TYPE="swap"
/dev/mapper/sda3_crypt: UUID="h9I3yI-KEAt-KOHe-YYLQ-UKnQ-FLdt-SgQGYS" TYPE="LVM2_member"
/dev/nvme1n1p2: UUID="d239d621-7fb9-40ee-8aac-39a0d2e2a367" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="f3e6e308-380b-4a51-80dc-a80ed099e497"
/dev/nvme1n1p3: UUID="58a5317a-4257-44b7-901a-34530f7c6d10" TYPE="crypto_LUKS" PARTUUID="c0c8bf03-d55b-4d7e-88fc-5c300cfe838b"
/dev/nvme1n1p1: UUID="D69C-32AF" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="2945f591-b01b-40ea-a253-3a49bd9b5b05"
/dev/mapper/OS-DATA: UUID="0a1f3e71-fcaa-4024-a611-34d30b67e911" BLOCK_SIZE="4096" TYPE="ext4

je fais
sudo pvscan
WARNING: VG OS was previously updated while PV /dev/mapper/essai2 was missing.
WARNING: VG OS was missing PV /dev/mapper/essai2 5RwpwV-o1TI-MIa7-CsP3-gZK7-Oq12-pc8mdW.
PV /dev/mapper/sda3_crypt VG OS lvm2 [475.51 GiB / 0 free]
PV /dev/mapper/essai2 VG OS lvm2 [953.85 GiB / 0 free]
Total: 2 [<1.40 TiB] / in use: 2 [<1.40 TiB] / in no VG: 0 [0 ]

ensuite je lui demande de retirer les données de essai2 et de les rapartier sur sda3_crypt

  sudo pvmove /dev/mapper/essai2 /dev/mapper/sda3_crypt 
      WARNING: VG OS was previously updated while PV /dev/mapper/essai2 was missing.
      WARNING: VG OS was missing PV /dev/mapper/essai2 5RwpwV-o1TI-MIa7-CsP3-gZK7-Oq12-pc8mdW.
      Cannot change VG OS while PVs are missing.
      See vgreduce --removemissing and vgextend --restoremissing.
      Cannot process volume group OS
      Failed to find physical volume "/dev/mapper/essai2".
      Run `pvmove --help' for more information.

Il doit y avoir un truc qui m’échappe

Zargos · Juin 18, 2026, 6:23

Oui c’est normal tu n,'a pas compris comment ça marche. Tu ne fait pas la différence entre les partitions, les filesystem et les points de montage.

Un PV n’est un support physique. Donc tu ne peux rien en faire en termes de données. C’ets juste un moyen de déclarer les supports physiques/partitions de base qui peuvent faire partie d’un ensemble LVM.

Les VG ne sont que le moyen de regrouper des PV dans un groupe cohérent.

Les LV sont des partitions créés au sein d’un VG.

Ces LV servent de partitions pour un filesystem (ext4 par exemple) que tu dois formater.

Ensuite tu vas monter ces LV pour pouvoir les utiliser.

Anonymous23 · Juin 18, 2026, 7:59

Oui effectivement, je viens de potasser un peu et je comprends mieux.

ET j’ai trouvé ma solution https://support.hpe.com/hpesc/public/docDisplay?docId=kc0119236en_us&docLocale=en_US

j’ai fait un vgextend --restoremissing et cela a réparé mon système LVM.

Je n’ai plus le bug au démarrage

Bonne soirée