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
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?
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:
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
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).
Merci. J’arrive a ouvrir les disques mais un PV du système LVM est inconnu
Donnes nous un lsblk -f pour voir les disque et les mappers.
J’ai utilisé pvcreate --uuid
Maintenant j’ai
Merci pour ton aide en tout cas
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:
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 ?
Oui un script ca aide bien
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
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
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.
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