[reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

rmy · Le 22/09/2010, à 14:10

J'y touche pas alors. Par contre, je crois que je vais être bon pour recommencer quand même. J'ai zappé un truc. Important je crois…

En fait j'ai pas mis de FS sur la partition md0p1, je pensais qu'en "pvmovant" ça déplaçait tout, extends, données et FS. Bon, c'est un peu utopique, mais pourquoi pas, hein ^^.

Bref, je me retrouve dans une situation qui ne m'inspire guère, et c'est pour cela que je n'ai pas retiré l'autre disque du LVM pour l'instant :

df -h /dev/md0p1
Sys. de fichiers            Tail. Occ. Disp. %Occ. Monté sur
none                  1,6G  372K  1,6G   1% /dev

par contre le vg a l'air correct :
sudo vgdisplay

 --- Volume group ---
  VG Name               debian
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  19
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               2,40 TiB
  PE Size               4,00 MiB
  Total PE              629489
  Alloc PE / Size       152558 / 595,93 GiB
  Free  PE / Size       476931 / 1,82 TiB
  VG UUID               CryiJf-tvAL-2yZK-rj1I-R5Im-HrTM-OwCgUe

Enfin, gparted affiche ma partition /dev/sda2 (le précedent LVM) reconnue comme de type "cryptsetup" alors que sur md0p1 garted affiche "lvm2" comme type. Quid du chiffrage ?

Dernière modification par rmy (Le 22/09/2010, à 14:15)

Hoper · Le 22/09/2010, à 16:22

En fait j'ai pas mis de FS sur la partition md0p1, je pensais qu'en "pvmovant" ça déplaçait tout, extends, données et FS. Bon, c'est un peu utopique, mais pourquoi pas, hein ^^.

C'est exactement ce qui s'est passé oui. Les lvs qui étaient avant sur l'autre disque sont maintenant sur celui la. Et tout à été totalement transparent pour toi.
Bref, le vg se trouve sur md0p1, et c'est bien le vg qui contient les lvs, qui contiennent les fs...
concernant le chiffrement, il y est toujours, car il a été mis non pas sur les lvs, mais directement sur le disque physique. Tout est chiffré, y compris le vg lui même. Si tu veux avoir une chance de le retrouver a ton prochain boot, modifie vite le fichier crypttab et remplace /dev/sda2 par /dev/md0p1.

Normalement... je crois... que tout devrait bien se passer... il va déchiffrer md0p1, reconstruire un /dev/mapper/cryptroot, dans lequel il retrouvera le vg, et tout le reste par la même occasion.

Concernant les type de partition, cela n'a absolument aucune importance. C'est une information que tu positionne toi même pour te souvenir de ta configuration. Bref, tu avais du, à l'époque, mettre le flag "cryptsetup" sur /dev/sda2, alors que tu as mis "lvm2" sur le nouveau device. Mais encore une fois, cela n'a d'importance que pour toi...

rmy · Le 22/09/2010, à 16:30

OK, alors je vais tester de la manière suivante :
0/ sortir /dev/sda2 du vg (vgreduce)
1/ modification du crypttab
2/ Copie des fichiers de /boot (/dev/sda1) vers /boot dans le vg après démontage de /boot
3/ modification de fstab car sinon il va me chercher /dev/sda1
4/ réinstallation de grub
5/ extinction, débranchement de mon /dev/sda
6/ reboot…

ça te parait bon ?

J'ai l'impression que ça risque de ne pas marcher pour l'instant car le mot de passe pour cryptsetup m'est demandé pendant la phase de boot, avec un fond d'écran ubuntu. Je vois mal comment, si les fichier de /boot sont dans le vg chiffré, cela pourrait passer, mais j'ai envie de tenter… (j'attends ta réponse avant de me lancer)

Hoper · Le 22/09/2010, à 16:46

J'ai l'impression que ça risque de ne pas marcher pour l'instant car le mot de passe pour cryptsetup m'est demandé pendant la phase de boot, avec un fond d'écran ubuntu. Je vois mal comment, si les fichier de /boot sont dans le vg chiffré, cela pourrait passer, mais j'ai envie de tenter… (j'attends ta réponse avant de me lancer)

C'est exactement ce que j'ai ressentit aussi... tu te souviens, quand je te disais que je voyais pas comment on pouvait chiffrer /boot à cause de ça...

A mon avis, fait déjà les opération 0 et 1, ensuite fait une première pause : tu reboot, tu vérifie que tout est ok.

A partir de la, je pense vraiment que tu n'aura pas le choix au final, et que tu devra avoir au moins un /boot non chiffré, et donc en dehors du raid. Maintenant libre à toi de faire des experiences hein

Globalement, au lieu de chiffrer le device du raid, il aurait fallu :
- faire le raid
- mettre un vg dessu
- créer des lvs
- Chiffrer certains lvs (home etc), mais pas les lv systèmes.

Bref, le chiffrement aurait du être la dernière couche de l'empilage, et pas la seconde juste après le raid...

rmy · Le 22/09/2010, à 17:16

Ok, je verrai après si je réduis légèrement le VG pour créer une autre partition sur le raid et y mettre le /boot ou si je recommence tout à zéro (de toutes façons c'est instructif et ça laisse une trace intéressante pour d'autres. Je vais donc faire les tests.

à tout de suite (ou pas).

rmy · Le 22/09/2010, à 17:24

Oups, en fait, encore une chose :
/dev/debian/sda2 n'existe pas…

spontanément j'aurais sorti /dev/sda2 complètement puisque c'est ce que j'ai spécifié quand j'ai créé le vg. Par contre pour une fois je pense avant d'agir, et je me dis qu'il faut peut-être sortir les uns après les autres /dev/debian/homebuntu, /dev/debian/rootbuntu, /dev/debian/swap_1…

bon, je vais tenter /dev/sda2 directement, et je verrai si il y a des messages d'erreur ou pas…

rmy · Le 22/09/2010, à 17:27

Message d'erreur :

Please enter physical volume paths or option -a
Run `vgreduce --help' for more information.

mais du coup autre questionnement :
sudo pvdisplay

  --- Physical volume ---
  PV Name               /dev/mapper/cryptroot
  VG Name               debian
  PV Size               595,93 GiB / not usable 1,67 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              152558
  Free PE               152558
  Allocated PE          0
  PV UUID               TJdpFD-iTRr-jQxg-jqqk-5gPU-tHwL-T28IUV
   
  --- Physical volume ---
  PV Name               /dev/md0p1
  VG Name               debian
  PV Size               1,82 TiB / not usable 2,56 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              476931
  Free PE               324373
  Allocated PE          152558
  PV UUID               NT2mUJ-71Zq-iH2V-wX21-3CkG-lvLN-6gvmQg

donc ce serait :

sudo vgreduce /dev/mapper/cryptroot

?
(idem, je teste et je repasse)

rmy · Le 22/09/2010, à 17:29

(même message d'erreur), allons y alors pour /dev/debian/homebuntu…

àa peine plus tard : (je n'ai pas encore fait la commande ci-dessus, car peut-être serait-ce plutôt
/dev/mapper/debian-homebuntu
/dev/mapper/debian-rootbuntu
/dev/mapper/debian-swap_1
mais il me semble que c'est équivalent…

hop, je teste cette fois-ci.

edit : aucun ne fonctionne. Je vais au "man".

Dernière modification par rmy (Le 22/09/2010, à 17:35)

rmy · Le 22/09/2010, à 17:38

man vgreduce a écrit :

SYNOPSIS
vgreduce [-a|--all] [-A|--autobackup y|n] [-d|--debug] [-h|-?|--help]
[--removemissing] [-t|--test] [-v|--verbose] VolumeGroupName [Physi‐
calVolumePath...]

Il manque quelque chose on dirait ^^

donc je vais voir ce que donne

sudo vgreduce debian /dev/mapper/cryptroot -t

edit :

Test mode: Metadata will NOT be updated.
Removed "/dev/mapper/cryptroot" from volume group "debian"

ça à l'air mieux. EN testant avec tous les autres (/dev/sda2, /dev/debian/*, dev/mapper/debian*) j'ai toujours un retour du type :

Test mode: Metadata will NOT be updated.
Physical Volume "/dev/debian/homebuntu" not found in Volume Group "debian"

donc j'enlève l'option -t.
Go!

Removed "/dev/mapper/cryptroot" from volume group "debian"

Dernière modification par rmy (Le 22/09/2010, à 17:41)

rmy · Le 22/09/2010, à 17:44

crypttab actuel :

cat /etc/crypttab
# <target name>	<source device>		<key file>	<options>
cryptroot		/dev/sda2	none	luks,retry=1,lvm=debian

Que je modifie en :

cat /etc/crypttab
# <target name>	<source device>		<key file>	<options>
cryptroot		/dev/md0p1	none	luks,retry=1,lvm=debian

et je reboot…

Dernière modification par rmy (Le 22/09/2010, à 17:46)

rmy · Le 22/09/2010, à 18:25

loupé

Grub est OK, il me propose le menu de boot, normal jusque là, il va le chercher sur /dev/sda1

Cryptsetup me demande bien le mot de passe, et m'annonce "lvm fs found but no lvm configured", j'avais déjà ce message d'erreur auparavant, je ne m'en suis pas soucié… puis une belle "busybox" avec comme message :

busybox a écrit :

ALERT ! /dev/mapper/debian-rootbuntu does not exist. Dropping to a shell

Je pense qu'il doit y avoir encore une trace à modifier dans une config de cryptsetup. Je vais doucher les enfants et je repasse plus tard.

rmy · Le 22/09/2010, à 18:57

Suite (et fin en attendant ton aide)

J'ai booté sur une FUR, mais du coup mon Raid n'est pas monté. Ce qui fait que je ne peut pas monter le volume luks qui est dessus, donc pas modifier le fstab et autres fichiers qui pourraient conserver la trace de /dev/mabber/debian*

mdadm --assemble ?

Dernière modification par rmy (Le 22/09/2010, à 19:01)

rmy · Le 22/09/2010, à 20:20

Bon, je suis incorrigible, mais je l'ai fait sans attendre :

sudo mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1

mdadm: /dev/md0 has been started with 3 drives.

rmy · Le 22/09/2010, à 20:30

Bon, ben ça y est, là je suis perdu

sudo cryptsetup luksOpen /dev/md0p1 monluks2
Enter LUKS passphrase: 
Commande échouée: /dev/md0p1 is not a LUKS partition

sudo mount /dev/md0p1 /mnt
mount: type inconnu de système de fichiers 'LVM2_member'

par contre :

sudo cryptsetup luksOpen /dev/sda2 monluks
Enter LUKS passphrase: 
key slot 2 unlocked.

Je ne sais plus trop quoi faire du coup…

Hoper · Le 22/09/2010, à 20:55

Heu... je viens de tout lire... mais la ce soir je peux pas... laisse moi jusqu'a demain pour tout relire et te répondre. A mon avis le chiffrement fait que le pvmove ne passe pas... peut etre au moment de la mise à jour des metadata... probablement... bref, je dois y réfléchir. A mon avis tu n'aura pas d'autre choix que de laisser tomber les outils lvm (pvmove etc) et, pour cette fois, re-créer complétement une nouvelle architecture lvm plus chiffrement, et faire tout simplement des cp entre les deux vgs, l'ancien et le nouveau.

rmy · Le 22/09/2010, à 20:58

Ça ne me dérange absolument pas de tout refaire avec cette option, c'est d'ailleurs ce que je comptais faire à un moment où à un autre...

Ponctuellement, quel est le moyen le plus simple de retrouver une situation fonctionnelle ?

Hoper · Le 23/09/2010, à 10:10

Quand tu déchiffre /dev/sda2, tu as accès à tes données ?

rmy · Le 23/09/2010, à 11:26

non, puisque je l'ai sorti du VG…

sudo cryptsetup luksOpen /dev/sda2 monluks
Enter LUKS passphrase: 
key slot 2 unlocked.
Commande réussie.

sudo pvscan
  PV /dev/mapper/monluks                      lvm2 [595,93 GB]
  Total: 1 [595,93 GB] / in use: 0 [0   ] / in no VG: 1 [595,93 GB]

Hoper · Le 23/09/2010, à 13:45

Bon... il faut se rassurer en se disant qu'un pvmove ne peut rien détruire. il déplace certes, mais il ne peut rien détruire. Avec un peu de chance tes données doivent toujours être sur sda2.

Sincèrement je ne sais pas du tout pourquoi tu ne peux pas déchiffrer /dev/md0p1. Pour aller plus loin dans cette direction, il te faut quelqu'un qui maitrise bien luks. Or, je ne l'ai jamais utilisé. Mes partitions sont chiffrés directement, avec cryptsetup, mais sans luks. C'est directement la phrase que je tape qui sert à chiffrer et à déchiffrer. Mais avec luks.. je ne sais pas du tout comment ca fonctionne, ou il trouve la clef au final etc...

Donc, pour le moment, la seule chose que je peux t'aider à faire c'est de voir si les données ne sont pas toujours sur sda2. Certes, le vg à été migré, mais je doute que la commande pvmove ai réellement effacé les donnés. Elle n'a du modifier que les méta data de lvm afin de faire croire qu'il n'y avait plus rien sur le disque, mais elle n'a clairement pas écrit des zéro partout

Normalement, ton système à du faire une copie de toute la configuration lvm juste avant le pvmove. Ce backup doit etre dans /etc/lvm/archive, et porter le nom du vg, et l'extension .vg (ce n'est qu'un fichier texte en réalité). As tu accès a ces fichiers ?

Si la réponse est non parce que même le / était chiffré... la j'avoue que je sais pas trop quoi te dire... (a part répéter que ca me semble une mauvaise idée de chiffrer le / mais bon...)

rmy · Le 23/09/2010, à 14:31

La seule chose que je puisse monter actuellement, c'est /dev/sda1, mon boot.

/dev/sda2 et /dev/md0p1 sont tous lesdeux signalés comme "LVM2 member" mais pas mountable.

J'ai fait une image de /dev/sda, mais elle date d'il y a quelques jours, puisque j'ai continué à utiliser le système même pendant la manip de création du raid et de migration... Est-ce qu'y récupérer la configuration du lvm pourrait être utile à la résolution de la situation ?

Bien sûr, je pourrais envisager simplement de reprendre cette image et de m'asseoir sur les dernières modifs, mais j'ai quelques heures de boulot qui traînent que je préfèrerais récupérer ^^ (oui, c'est le cordonnier qui est toujours le plus mal chaussé).

Je suis preneur de toute idée et tentative. Le sujet m'intéresse par ailleurs.

rmy · Le 23/09/2010, à 14:35

Autre possibilité : puisque cryptsetup me permet "d'ouvrir" /dev/sda2 et qu'en l'état actuel le contenu de /dev/sda2 est sensé être le même que celui de /dev/md0p1, je me dit que peut-être il serait possible de rebasculer les PE de /dev/md0p1 vers /dev/sda2 et de se retrouver -en débranchant le raid- dans une situation initiale. Est-ce que lors du déplacement des PE les données sont copiées linéairement ?

En attendant ta réponse je tente le montage de l'image et je te dis si je trouve un quelconque fichier de conf.

rmy · Le 23/09/2010, à 14:48

# Generated by LVM2 version 2.02.54(1) (2009-10-26): Fri Apr 30 07:01:38 2010

contents = "Text Format Volume Group"
version = 1

description = "Created *after* executing 'vgcfgbackup'"

creation_host = "rmyprod"	# Linux rmyprod 2.6.31-21-generic #59-Ubuntu SMP Wed Mar 24 07:28:56 UTC 2010 i686
creation_time = 1272603698	# Fri Apr 30 07:01:38 2010

debian {
	id = "CryiJf-tvAL-2yZK-rj1I-R5Im-HrTM-OwCgUe"
	seqno = 11
	status = ["RESIZEABLE", "READ", "WRITE"]
	flags = []
	extent_size = 8192		# 4 Megabytes
	max_lv = 0
	max_pv = 0

	physical_volumes {

		pv0 {
			id = "TJdpFD-iTRr-jQxg-jqqk-5gPU-tHwL-T28IUV"
			device = "/dev/mapper/cryptroot"	# Hint only

			status = ["ALLOCATABLE"]
			flags = []
			dev_size = 1249758554	# 595,931 Gigabytes
			pe_start = 384
			pe_count = 152558	# 595,93 Gigabytes
		}
	}

	logical_volumes {

		swap_1 {
			id = "LxEGT1-fmgR-XGGX-byOt-j2p6-bXrs-SasLSs"
			status = ["READ", "WRITE", "VISIBLE"]
			flags = []
			segment_count = 1

			segment1 {
				start_extent = 0
				extent_count = 648	# 2,53125 Gigabytes

				type = "striped"
				stripe_count = 1	# linear

				stripes = [
					"pv0", 1668
				]
			}
		}

		rootbuntu {
			id = "qjJsVW-8iWp-CT0H-YqoS-hsl1-yFTL-MlzMub"
			status = ["READ", "WRITE", "VISIBLE"]
			flags = []
			segment_count = 1

			segment1 {
				start_extent = 0
				extent_count = 3840	# 15 Gigabytes

				type = "striped"
				stripe_count = 1	# linear

				stripes = [
					"pv0", 53772
				]
			}
		}

		homebuntu {
			id = "fo3HBW-BL0n-ctuO-Rgg7-U03h-Vorb-bjq8cP"
			status = ["READ", "WRITE", "VISIBLE"]
			flags = []
			segment_count = 3

			segment1 {
				start_extent = 0
				extent_count = 94946	# 370,883 Gigabytes

				type = "striped"
				stripe_count = 1	# linear

				stripes = [
					"pv0", 57612
				]
			}
			segment2 {
				start_extent = 94946
				extent_count = 51456	# 201 Gigabytes

				type = "striped"
				stripe_count = 1	# linear

				stripes = [
					"pv0", 2316
				]
			}
			segment3 {
				start_extent = 146402
				extent_count = 1668	# 6,51562 Gigabytes

				type = "striped"
				stripe_count = 1	# linear

				stripes = [
					"pv0", 0
				]
			}
		}
	}
}

Hoper · Le 23/09/2010, à 15:38

Bonne idée le coup de l'image préalable

Tu as bien compris je suppose qu'on est arrivé aux limites de mes compétences hein... Je n'ai aucune pratique réelle de restauration de configuration lvm.

Personnellement, je testerai la commande vgcfgrestore, qui, en lui fournissant ce fichier décrivant donc la structure lvm2 qui se trouvait sur /dev/sda2, devrait pouvoir te remettre cette partition comme elle était...

Sauf que... Avant le lancement de vgcfgrestore, tu dois absolument recréer le device "/dev/mapper/cryptroot" bien sur avec exactement le même chiffrement etc. Ensuite seulement tu restaure la configuration lvm, et la, avec un peu de chance...

Ce qui m'ennuie vraiment, c'est que pour le moment je ne comprend toujours pas ce qui n'a pas fonctionné dans ta manipulation

Dernière modification par Hoper (Le 23/09/2010, à 15:40)

rmy · Le 23/09/2010, à 15:41

je regarde le man et je reviens au questions. Bon, en fait de quelques jours, c'est une image du 30/08

Que le temps passe vite…

ET je ne comprends pas bien

tu dois absolument recréer le device "/dev/mapper/cryptroot" bien sur avec exactement le même chiffrement etc.

cela ne se fait-il pas dès que j'ouvre /dev/sda2 avec luksOpen ?

rmy · Le 23/09/2010, à 15:48

Hoper a écrit :

Ce qui m'ennuie vraiment, c'est que pour le moment je ne comprend toujours pas ce qui n'a pas fonctionné dans ta manipulation

Mon hypothèse, c'est que mon chiffrement est au niveau de la partition elle-même (/dev/sda2) or lorsque j'ai fait le déplacement des PE j'utilisais le système, j'avais donc déjà "ouvert" /dev/sda2. Je n'ai donc transféré que le contenu de LVM. Cryptsetup ouvre donc toujours /dev/sda2, et ne va en rien chercher ce qui se trouve sur le raid (?).

Un peu comme si actuellement j'avais /boot sur /dev/sda1 (et dans celui-ci nécessairement des infos pour cryptsetup, mais que je ne trouve pas) et qu'au lancement tout ce qui concerne cryptsetup se trouvait orienté vers sda2 alors que tout le contenu du LVM est sur le raid.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 22/09/2010, à 14:10

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#27 Le 22/09/2010, à 16:22

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#28 Le 22/09/2010, à 16:30

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#29 Le 22/09/2010, à 16:46

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#30 Le 22/09/2010, à 17:16

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#31 Le 22/09/2010, à 17:24

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#32 Le 22/09/2010, à 17:27

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#33 Le 22/09/2010, à 17:29

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#34 Le 22/09/2010, à 17:38

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#35 Le 22/09/2010, à 17:44

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#36 Le 22/09/2010, à 18:25

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#37 Le 22/09/2010, à 18:57

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#38 Le 22/09/2010, à 20:20

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#39 Le 22/09/2010, à 20:30

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#40 Le 22/09/2010, à 20:55

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#41 Le 22/09/2010, à 20:58

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#42 Le 23/09/2010, à 10:10

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#43 Le 23/09/2010, à 11:26

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#44 Le 23/09/2010, à 13:45

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#45 Le 23/09/2010, à 14:31

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#46 Le 23/09/2010, à 14:35

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#47 Le 23/09/2010, à 14:48

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#48 Le 23/09/2010, à 15:38

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#49 Le 23/09/2010, à 15:41

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#50 Le 23/09/2010, à 15:48

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

Pied de page des forums