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

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

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

Si en effet. puisque les commandes lvm te répondent normalement, c'est que c'est bon. La commande pvs notamment doit bien t'indiquer l'existence de /dev/mapper/cryptroot (même si ce pv n'est plus utilisé donc).

rmy · Le 23/09/2010, à 16:20

sudo pvs
  Found duplicate PV TJdpFDiTRrjQxgjqqk5gPUtHwLT28IUV: using /dev/mapper/cryptoroot not /dev/mapper/monluks
  PV                     VG     Fmt  Attr PSize   PFree
  /dev/mapper/cryptoroot debian lvm2 a-   595,93G    0

je vais juste par sécurité le retirer et le rouvrir avec le bon "nom". Et tester la commande avec -t pour tester.

rmy · Le 23/09/2010, à 19:33

Désolé, j'avais zappé rdv chez l'ophtalmo avec les petits.

Me voici de retour.

En fait dans le retour du message précédent cette phrase m'a alerté :
" Found duplicate PV" et "using /dev/mapper/cryptoroot not /dev/mapper/monluks"

donc du coup il utilisait l'image que j'avais monté avec un loop device (normal)

Pour éviter de corrompre cette image, j'ai préféré redémarrer (parce que pour une raison inconnue je n'arrivais pas à libérer l'image en question), virer mon disque externe avec l'image et ouvrir le luks de /dev/sda2 avec le bon mapping.

J'ai donc :

sudo pvs
  PV                    VG   Fmt  Attr PSize   PFree  
  /dev/mapper/cryptroot      lvm2 --   595,93G 595,93G

et vgcfgrestore :

sudo vgcfgrestore -tv -f Bureau/debian debian
  Test mode: Metadata will NOT be updated.
  Restored volume group debian
    Test mode: Wiping internal cache
    Wiping internal VG cache

Comme ça a l'air de marcher, je vais toucher du bois, croiser les doigts, et enlever l'option -t.

rmy · Le 23/09/2010, à 19:34

sudo vgcfgrestore -v -f Bureau/debian debian
  Restored volume group debian

rmy · Le 23/09/2010, à 19:43

sudo pvdisplay
  --- Physical volume ---
  PV Name               /dev/mapper/cryptroot
  VG Name               debian
  PV Size               595,93 GB / not usable 1,67 MB
  Allocatable           yes (but full)
  PE Size (KByte)       4096
  Total PE              152558
  Free PE               0
  Allocated PE          152558
  PV UUID               TJdpFD-iTRr-jQxg-jqqk-5gPU-tHwL-T28IUV

sudo vgdisplay
  --- Volume group ---
  VG Name               debian
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  12
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               595,93 GB
  PE Size               4,00 MB
  Total PE              152558
  Alloc PE / Size       152558 / 595,93 GB
  Free  PE / Size       0 / 0   
  VG UUID               CryiJf-tvAL-2yZK-rj1I-R5Im-HrTM-OwCgUe

sudo lvdisplay
  --- Logical volume ---
  LV Name                /dev/debian/swap_1
  VG Name                debian
  LV UUID                LxEGT1-fmgR-XGGX-byOt-j2p6-bXrs-SasLSs
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                2,53 GB
  Current LE             648
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1
   
  --- Logical volume ---
  LV Name                /dev/debian/rootbuntu
  VG Name                debian
  LV UUID                qjJsVW-8iWp-CT0H-YqoS-hsl1-yFTL-MlzMub
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                15,00 GB
  Current LE             3840
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:2
   
  --- Logical volume ---
  LV Name                /dev/debian/homebuntu
  VG Name                debian
  LV UUID                fo3HBW-BL0n-ctuO-Rgg7-U03h-Vorb-bjq8cP
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                578,40 GB
  Current LE             148070
  Segments               3
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:3

et
………………

le mount se passe bien, merci
tu peux donc ajouter ça a tes connaissances et compétences, et moi aussi.

[goutte de sueur]J'aime bien résoudre des cas pointus comme ça, mais surtout chez les autres [/goutte de sueur]

Bon, j'ai un peu mal au crâne, tu t'en doutes…
Je vais rebooter sans le raid pour voir ce que ça dit, et … faire une image à jour ^^

T'es encore dispo ces prochains jours pour reprendre pas à pas, avec le maximum de retours pour voir où ça a pu merdouiller ?

(facultatif : tu viens à Paris pour l'UP ? Je te dois une bière, au moins)

EDIT : en direct après reboot sans FUR et sans Raid, je confirme que la manip a fonctionné à 100%.

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

Hoper · Le 23/09/2010, à 20:47

Cool J'avais bon espoir que cette commande fonctionne, mais je n'avais jamais eu l'occasion de la tester... Surtout, il y avait tout de même un risque, même faible, que le pvmove ai réellement effacé quelque chose d'important. Mais bon, maintenant je saurai

Pour la suite, je pense que refaire les même manipulations conduiront au même résultat.
(il faut que je prenne le temps de relire tranquillement ton hypothèse sur ce qui s'est passé, pour l'instant, c'est très brumeux en ce qui me concerne)

Par contre, si tu veux tout reconstruire en modifiant l'architecture, et donc en plaçant bien le chiffrement au dessus de LVM et pas en dessous, la pas de soucis je pourrai continuer à passer de temps en temps. Cela dit tu as maintenant autant de connaissances que moi sur le sujet, il s'agit juste de construire la configuration et de faire des copies entre les deux vg, l'actuel et le futur.

Pour l'ubuntu party, je n'y suis allé qu'une seule fois. Et encore pas longtemps.... Juste le temps d'ecouter monsieur Shuttleworth lorsqu'il était venu à Paris (Résumé de ce que j'en ai vu ici : http://hoper.dnsalias.net/tdc/index.php?post/2009/11/30/Mark-Shuttleworth )
J'y retournerai peut etre... mais c'est pas forcément très pratique pour moi qui n'habite pas dans Paris. Mais merci quand même

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

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

^^ sympa le blog

On y voit des têtes connues (dans les membres U-fr).

Je viendrai de strasbourg à cette UP car :
- Je prépare activement les RMLL 2011 à domicile
- J'envisage une mini-conf à la prochaine UP sur la récupération de données et l'importance des sauvegardes. SI tu veux te joindre à moi sur ce point, je recrute !

Pour ce qui est de la solution à mon souci de LVM/Raid/Luks, je vais quand même retenter parce que je suis obtu et que j'aime comprendre ce qui cloche. Et si ça ne vient pas de mon fait, je ferai avancer le schmilblick dans la bonne direction.

Encore un petit détail : toutes mes modifs depuis la migration des PE vers le raid n'existent plus. C'est pas dramatique, mais ça confirme que la migration du LVM a bien eu lieu correctement et que j'ai "tourné" un moment sur le Raid. C'est uniquement donc au reboot que se pose le souci. Reste à comprendre pourquoi.

Tiens d'ailleurs, premier truc que j'essaierai après avoir fait ma sauvegarde cette nuit, c'est de voir si en reconstruisant le raid avec mon lvm correctement fonctionnel j'arrive à quelque chose. Pis je vais essayer d'optimiser mon anglais et d'aller faire un tour sur IRC de [lvm, raid, luks]

rmy · Le 23/09/2010, à 22:47

En fait, j'ai réfléchi (encore !!!). Je crois que le problème vient bien du fait que mon luks est si bas (sans mauvais jeux de mot).

Tu avais déjà tiqué sur le fait que mon PV soit /dev/mapper/cryptsetup et non le périphérique de type bloc lui-même. Mon LVM est donc une couche "supérieure" à mon luks. En déplaçant les PE vers le raid, je les ai donc "sorti" du luks, qui lui reste attaché à /dev/sda2 avec comme conteneur /dev/mapper/cryptsetup.

Je pense que je vais reprendre donc la même manip mais :
-en sortant le /boot du lvm, je vais donc partitionner les disques comme prévu au départ (raid 10 ? pour le boot)
-ensuite je vais créer de la même manière mon raid5,
-puis je vais le chiffrer intégralement, comme sda2 l'est
-enfin je vais faire le déplacement des PE mais en ajoutant le /dev/mapper/cryptraid et non pas le raid lui même comme PV.

Et là, je pense que ça va marcher…

mais pas aujourd'hui, j'ai une sauvegarde à faire (dit-il en se reprenant de justesse avant d'ouvrir un terminal)

Hoper · Le 24/09/2010, à 09:47

Tu avais déjà tiqué sur le fait que mon PV soit /dev/mapper/cryptsetup et non le périphérique de type bloc lui-même. Mon LVM est donc une couche "supérieure" à mon luks. En déplaçant les PE vers le raid, je les ai donc "sorti" du luks, qui lui reste attaché à /dev/sda2 avec comme conteneur /dev/mapper/cryptsetup.

Mais oui ! C'est juste évident ! Ce sont en effet les PE non chiffrés que tu as déplacé vers le raid... Du coup, il n'y avais pas besoin du fichier /etc/crypttab, en fait, tes données devaient etre accessibles directement sur le raid, à l'aide d'un simple vgscan ou équivalent !
Zut, je regrette de ne pas avoir compris ça plus tot... Je suis malade depuis trois jours donc je réfléchis mal, mais quand même... en tout cas merci de m'avoir ouvert les yeux la dessus

Du coup la manipulation que tu propose a toute les chance de fonctionner.

J'envisage une mini-conf à la prochaine UP sur la récupération de données et l'importance des sauvegardes. SI tu veux te joindre à moi sur ce point, je recrute

Ah ? .... c'est vrai que... Quand je pense au nombre de fois ou je l'ai répété ici... Pouvoir le répéter haut et fort devant quelques centaines de gens... c'est tentant... Je pourrai aussi en profiter pour expliquer la différence entre une copie et un véritable mécanisme de sauvegarde, il y a tellement de gens qui visiblement ne font pas la différence...

Ce serait quand ? Qu'a tu déjà planifié exactement ? Dnvoi moi ces informations par mail (je suis chez free), et il se pourrait que je réfléchisse sérieusement à ta proposition...

rmy · Le 24/09/2010, à 10:58

Il doit y avoir autre chose, parce que le ni vgs, ni lvs, ni pvs ne me donnaient de résultats avec le raid. Je vais essayer de nouveau, puisque j'ai quelques mails égarés à récupérer, mais je pense qu'au contraire les PE ont été copiés "tels quels", sans passer par un déchiffrement/chiffrement, et sont donc transférés dans l'état où ils sont enregistrés sur le disque (donc chiffrés). Sauf que comme il n'y a pas de conteneur luks associé, pas de déchiffrage possible, et donc pas d'accès aux données (heureusement en fait !).

Je vais vérifier cette hypothèse en comparant quelques dd | hexdump avant l'ouverture avec luks pour voir si les données enregistrées sur le raid sont bien "binairement" identiques à celles de sda2. Par contre, je ne sais toujours pas si les PE sont tranfsférés linéairement ou pas (est-ce que les données correspondent physiquement sur les disques, en dehors de la considération du stripping raid qui est transparente puisque je ferai le dd directement sur le raid synchronisé). Voilà, encore quelques tests à suivre donc que je résume ici pour comprendre plus précisemment ce qui a pu se passer :

1/ Reboot sur liveusb et synchro du raid, comparaison des retours de dd.

2/ Si les données sur le raid ne semblent pas chiffrées, tentative d'acès au lvm

3/ Si 2/ ne marche pas, tentative d'accès au lvm après avoir booté normalement sur l'autre disque réstauré (je ne sais pas ce qui peut se passer ici, j'ai cru voir que les "duplicates" étaient détectés et que l'un était utilsé préférentiellement, j'imagine que l'on doit pouvoir spécifier lequel prendre.

4/ On recommence la démarche en créant le partitionnement pour /boot, puis le raid, puis le conteneur chiffré, puis déplacement du lvm, puis les modifs de crypttab et réinstall de grub. ET sans mélanger les opérations (afin d'éliminer tout de même une cause -improbable- de problèmes)

5/ Si ça fonctionne toujours pas, je me rabattrai sur une solution avec montage manuel de la nouvelle situation et chiffrage uniquement au niveau des LVs souhaités.

Dernière modification par rmy (Le 24/09/2010, à 10:59)

Hoper · Le 24/09/2010, à 11:06

je ne sais toujours pas si les PE sont tranfsférés linéairement ou pas

Je suis quasiment près à parier que c'est le cas. Les PE doivent simplement être copiés les uns à la suite des autres, dans leur ordre de numérotation. (et non en fonction de leur position physique, ce qui doit aussi permettre lors d'un move de "défragmenter" les volumes logiques dont la taille aurait été plusieurs fois modifiée...

rmy · Le 24/09/2010, à 16:00

Un peu de delay… le temps de transférer les données d'un client avant de continuer.

Je viens de rebooter sur une FUR, sans le disque /dev/sda, avec le raid synchronisé :

cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md0 : active raid5 sdb1[1] sdc1[0] sda1[2]
1953519872 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
sudo vgscan -v
Wiping cache of LVM-capable devices
Wiping internal VG cache
Reading all physical volumes. This may take a while...
Finding all volume groups
ubuntu@ubuntu:~$ sudo vgdisplay
ubuntu@ubuntu:~$ sudo pvdisplay
ubuntu@ubuntu:~$ sudo lvdisplay

Voilà. Rien quoi…

Je retente un peu plus tard la comparaison raid / sda pour les dd

rmy · Le 25/09/2010, à 10:49

Bon bah encore un autre souci ,c'est plus drôle quand ça se cumule :

Depuis le liveUSB j'arrive à syncro le raid sans soiuci (c'est même automatique ^^)

[raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md0 : active raid5 sdd1[0] sdc1[1] sdb1[2]
1953519872 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

Alors que depuis le système lancé classiquement sur /dev/sda2, j'ai un retour disant que /dev/sdc1 ne semble pas disponible et ne contient pas de superblock… une idée de la cause ?
(message exact à suivre après reboot)

sudo mdadm -A /dev/md0 -v /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: looking for devices for /dev/md0
mdadm: no recogniseable superblock on /dev/sdb1
mdadm: /dev/sdb1 has no superblock - assembly aborted

Dernière modification par rmy (Le 25/09/2010, à 13:37)

rmy · Le 26/09/2010, à 10:30

Suite, une piste ici :
./viewtopic.php?id=311652

Je vais en profiter pour tester et comparer, essayer de déterminer ce qui cloche et pourquoi.

Donc, mon raid ne veut pas se synchroniser :

sudo sfdisk -l

Disque /dev/sda : 77825 cylindres, 255 têtes, 63 secteurs/piste
Unités= cylindres de 8225280 octets, blocs de 1024 octets, décompte à partir de 0

   Périph Amor Début     Fin   #cyls    #blocs    Id  Système
/dev/sda1   *      0+     30      31-    248976   83  Linux
/dev/sda2         31   77824   77794  624880305   83  Linux
/dev/sda3          0       -       0          0    0  Vide
/dev/sda4          0       -       0          0    0  Vide

Disque /dev/sdb : 121601 cylindres, 255 têtes, 63 secteurs/piste
Unités= cylindres de 8225280 octets, blocs de 1024 octets, décompte à partir de 0

   Périph Amor Début     Fin   #cyls    #blocs    Id  Système
/dev/sdb1          0+ 121600  121601- 976760001   fd  Linux raid autodetect
/dev/sdb2          0       -       0          0    0  Vide
/dev/sdb3          0       -       0          0    0  Vide
/dev/sdb4          0       -       0          0    0  Vide

Disque /dev/sdd : 121601 cylindres, 255 têtes, 63 secteurs/piste
Unités= cylindres de 8225280 octets, blocs de 1024 octets, décompte à partir de 0

   Périph Amor Début     Fin   #cyls    #blocs    Id  Système
/dev/sdd1          0+ 121600  121601- 976760001   fd  Linux raid autodetect
/dev/sdd2          0       -       0          0    0  Vide
/dev/sdd3          0       -       0          0    0  Vide
/dev/sdd4          0       -       0          0    0  Vide

Disque /dev/sdc : 121601 cylindres, 255 têtes, 63 secteurs/piste
Unités= cylindres de 8225280 octets, blocs de 1024 octets, décompte à partir de 0

   Périph Amor Début     Fin   #cyls    #blocs    Id  Système
/dev/sdc1          0+ 121600  121601- 976760001   fd  Linux raid autodetect
/dev/sdc2          0       -       0          0    0  Vide
/dev/sdc3          0       -       0          0    0  Vide
/dev/sdc4          0       -       0          0    0  Vide

pourtant :

sudo mdadm --examine --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=d9126e19:7dd8a0b1:38068b2c:eb3ab5c6

mais :

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md_d0 : inactive sdb1[0](S)
      976759936 blocks
       
unused devices: <none>

Curieusement, il semble que sdb1 soit pourtant déjà dans un statut de "raid synchronisé", qu'il possède bien des SB corrects, mais qu'en fait ce soit /dev/md0 qui ne soit pas (déclar?|visible?|créé?) car :

mdadm --examine /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : d9126e19:7dd8a0b1:38068b2c:eb3ab5c6 (local to host rmyprod)
  Creation Time : Tue Sep 21 10:15:40 2010
     Raid Level : raid5
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
     Array Size : 1953519872 (1863.02 GiB 2000.40 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 0

    Update Time : Wed Sep 22 17:46:54 2010
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0
       Checksum : f6c36991 - correct
         Events : 1870

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     0       8       17        0      active sync   /dev/sdb1

   0     0       8       17        0      active sync   /dev/sdb1
   1     1       8       33        1      active sync   /dev/sdc1
   2     2       8       49        2      active sync   /dev/sdd1

et curieusement, mon mdadm.conf semble "vierge" comme dans le post cité ci-dessus :

cat /etc/mdadm/mdadm.conf 
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays

# This file was auto-generated on Wed, 30 Jun 2010 13:03:17 +0200
# by mkconf $Id$

Je vais donc y ajouter la ligne qui va bien comme préconisé en fin de ce post, mais en corrigeant l'erreur  :

sudo bash -c "mdadm --examine --scan >> /etc/mdadm/mdadm.conf"

rmy · Le 26/09/2010, à 10:47

Bon bah au reboot, ça marche plus, il semble que le raid fonctionnant à nouveau, et n'ayant pas changé mon /etc/crypttab, le problème précédent se pose à nouveau, mais avec un détail supplémentaire :
lorsque je reboote ensuite sur live USB, mon /dev/sda2 a été sorti du vg, probablement à cause de la présence du raid…

bref, je refais un coup de vgcfgrestore, et je constate que mon crypttab est désormais vide.

Je le restore et je reboot, puis je reviens

rmy · Le 26/09/2010, à 10:52

Ce qui est bien avec ce post, c'est que je vais devenir expêêêrt raid, luks, cryptsetup et que les femmes du monde entier se pââââmeront devant moi !

Bon, le reboot c'est bon, et cette fois-ci :

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid5 sdd1[2] sdb1[3] sdc1[1]
      1953519872 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU]
      [>....................]  recovery =  0.3% (3848320/976759936) finish=142.3min speed=113885K/sec
      
unused devices: <none>

mais ça tient peut-être au fait que dans le doute au premier plantage du raid j'avais permuté deux disques, n'étant plus tout à fait sur de l'ordre (oui, je sais, j'ai numéroté les câbles et les disques, mais une fois dans la tour, je ne vois plus les numéros des disques )

rmy · Le 26/09/2010, à 10:57

Bon, par contre il y a encore un truc tout bizarre :

sudo pvscan
  PV /dev/md0p1              VG debian          lvm2 [1,82 TiB / 1,24 TiB free]
  PV /dev/mapper/cryptroot                      lvm2 [595,93 GiB]
  Total: 2 [2,40 TiB] / in use: 1 [1,82 TiB] / in no VG: 1 [595,93 GiB]

Il semble que ce soit le raid qui soit utilisé dans le vg, alors que les données sont celles de sda2 (les mails reçus entre temps, les derniers onglets de firefox etc…

Je vais m'occuper de préparer le repas en réfléchissant comment faire pour repasser vraiment sur le raid.

rmy · Le 26/09/2010, à 13:14

Bon, je continue dans les observations et recherches que je m'étais fixé.

La comparaison /dev/md0p1 et /dev/sda2 me parraît vite évidente :

sudo dd if=/dev/sda2 bs=512 count=1  | hexdump -C

00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  63 62 63 2d 65 73 73 69  |........cbc-essi|
00000030  76 3a 73 68 61 32 35 36  00 00 00 00 00 00 00 00  |v:sha256........|
00000040  00 00 00 00 00 00 00 00  73 68 61 31 00 00 00 00  |........sha1....|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 08 08 00 00 00 20  |............... |
00000070  c4 d0 08 e9 f1 da 54 21  78 bc 2e d2 90 e4 d4 34  |......T!x......4|
00000080  ce 6e e7 94 53 f9 76 d7  a7 f1 53 51 d0 cb 28 c6  |.n..S.v...SQ..(.|
00000090  44 78 6e 98 1a ce 96 5c  f6 02 1d 0d d4 4a 48 9b  |Dxn....\.....JH.|
000000a0  3a 6d 3e 5c 00 00 00 0a  37 64 63 61 37 39 34 38  |:m>\....7dca7948|
000000b0  2d 64 37 38 65 2d 34 63  66 36 2d 62 39 31 64 2d  |-d78e-4cf6-b91d-|
000000c0  62 31 33 30 64 64 63 31  33 35 30 65 00 00 00 00  |b130ddc1350e....|
000000d0  00 ac 71 f3 00 04 4e 23  b7 05 cc 1f 07 5f 98 36  |..q...N#....._.6|
000000e0  1a 30 96 0a 52 6a 3e e0  37 78 b9 04 53 df 6b 2c  |.0..Rj>.7x..S.k,|
000000f0  d3 a8 66 52 77 d1 bb 84  00 00 00 08 00 00 0f a0  |..fRw...........|
00000100  00 ac 71 f3 00 04 6b 9e  68 a0 ce 2e 16 0a 16 6d  |..q...k.h......m|
00000110  1a ab ca 4a e5 64 ec 63  cc f3 0e cb b4 7a 5f 56  |...J.d.c.....z_V|
00000120  9b 5a 89 7c 36 1a d6 fb  00 00 01 08 00 00 0f a0  |.Z.|6...........|
00000130  00 ac 71 f3 00 04 68 f4  4c a7 62 2f b9 f7 c1 7f  |..q...h.L.b/....|
00000140  ab 2d b6 17 8a 11 e3 f8  c0 ca ad ce 7f 75 09 ff  |.-...........u..|
00000150  40 9f 2b 84 d8 aa 15 95  00 00 02 08 00 00 0f a0  |@.+.............|
00000160  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 03 08 00 00 0f a0  |................|
00000190  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  00 00 04 08 00 00 0f a0  |................|
000001c0  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 05 08 00 00 0f a0  |................|
000001f0  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000200

Où l'identité est claire :
-Offset 0x00000000 "LUKS....aes....."
-Offset 0x00000028 et suivant : "cbc-essiv:sha256"
-Offset 0x00000048 "sha1...."

Je remarque au passage une valeur qui pourraitt être un uuid, ou une clé chiffrée ? (Offset 0x000000a8) : "7dca7948-d78e-4cf6-b91d-b130ddc1350e"

Par contre, /dev/md0p1 n'est clairement pas chiffré :

sudo dd if=/dev/md0p1 bs=512 count=13  | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  4c 41 42 45 4c 4f 4e 45  01 00 00 00 00 00 00 00  |LABELONE........|
00000210  a8 dd 1e cf 20 00 00 00  4c 56 4d 32 20 30 30 31  |.... ...LVM2 001|
00000220  4e 54 32 6d 55 4a 37 31  5a 71 69 48 32 56 77 58  |NT2mUJ71ZqiH2VwX|
00000230  32 31 33 43 6b 47 6c 76  4c 4e 36 67 76 6d 51 67  |213CkGlvLN6gvmQg|
00000240  00 04 e9 c0 d1 01 00 00  00 82 04 00 00 00 00 00  |................|
00000250  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000260  00 00 00 00 00 00 00 00  00 10 00 00 00 00 00 00  |................|
00000270  00 72 04 00 00 00 00 00  00 00 00 00 00 00 00 00  |.r..............|
00000280  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  e1 d9 ea b9 20 4c 56 4d  32 20 78 5b 35 41 25 72  |.... LVM2 x[5A%r|
00001010  30 4e 2a 3e 01 00 00 00  00 10 00 00 00 00 00 00  |0N*>............|
00001020  00 72 04 00 00 00 00 00  00 62 00 00 00 00 00 00  |.r.......b......|
00001030  96 05 00 00 00 00 00 00  f0 70 16 59 00 00 00 00  |.........p.Y....|
00001040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001200  64 65 62 69 61 6e 20 7b  0a 69 64 20 3d 20 22 43  |debian {.id = "C|
00001210  72 79 69 4a 66 2d 74 76  41 4c 2d 32 79 5a 4b 2d  |ryiJf-tvAL-2yZK-|
00001220  72 6a 31 49 2d 52 35 49  6d 2d 48 72 54 4d 2d 4f  |rj1I-R5Im-HrTM-O|
00001230  77 43 67 55 65 22 0a 73  65 71 6e 6f 20 3d 20 31  |wCgUe".seqno = 1|
00001240  32 0a 73 74 61 74 75 73  20 3d 20 5b 22 52 45 53  |2.status = ["RES|
00001250  49 5a 45 41 42 4c 45 22  2c 20 22 52 45 41 44 22  |IZEABLE", "READ"|
00001260  2c 20 22 57 52 49 54 45  22 5d 0a 66 6c 61 67 73  |, "WRITE"].flags|
00001270  20 3d 20 5b 5d 0a 65 78  74 65 6e 74 5f 73 69 7a  | = [].extent_siz|
00001280  65 20 3d 20 38 31 39 32  0a 6d 61 78 5f 6c 76 20  |e = 8192.max_lv |
00001290  3d 20 30 0a 6d 61 78 5f  70 76 20 3d 20 30 0a 0a  |= 0.max_pv = 0..|
000012a0  70 68 79 73 69 63 61 6c  5f 76 6f 6c 75 6d 65 73  |physical_volumes|
000012b0  20 7b 0a 0a 70 76 30 20  7b 0a 69 64 20 3d 20 22  | {..pv0 {.id = "|
000012c0  54 4a 64 70 46 44 2d 69  54 52 72 2d 6a 51 78 67  |TJdpFD-iTRr-jQxg|
000012d0  2d 6a 71 71 6b 2d 35 67  50 55 2d 74 48 77 4c 2d  |-jqqk-5gPU-tHwL-|
000012e0  54 32 38 49 55 56 22 0a  64 65 76 69 63 65 20 3d  |T28IUV".device =|
000012f0  20 22 2f 64 65 76 2f 6d  61 70 70 65 72 2f 63 72  | "/dev/mapper/cr|
00001300  79 70 74 72 6f 6f 74 22  0a 0a 73 74 61 74 75 73  |yptroot"..status|
00001310  20 3d 20 5b 22 41 4c 4c  4f 43 41 54 41 42 4c 45  | = ["ALLOCATABLE|
00001320  22 5d 0a 66 6c 61 67 73  20 3d 20 5b 5d 0a 64 65  |"].flags = [].de|
00001330  76 5f 73 69 7a 65 20 3d  20 31 32 34 39 37 35 38  |v_size = 1249758|
00001340  35 35 34 0a 70 65 5f 73  74 61 72 74 20 3d 20 33  |554.pe_start = 3|
00001350  38 34 0a 70 65 5f 63 6f  75 6e 74 20 3d 20 31 35  |84.pe_count = 15|
00001360  32 35 35 38 0a 7d 0a 0a  70 76 31 20 7b 0a 69 64  |2558.}..pv1 {.id|
00001370  20 3d 20 22 4e 54 32 6d  55 4a 2d 37 31 5a 71 2d  | = "NT2mUJ-71Zq-|
00001380  69 48 32 56 2d 77 58 32  31 2d 33 43 6b 47 2d 6c  |iH2V-wX21-3CkG-l|
00001390  76 4c 4e 2d 36 67 76 6d  51 67 22 0a 64 65 76 69  |vLN-6gvmQg".devi|
000013a0  63 65 20 3d 20 22 2f 64  65 76 2f 6d 64 30 70 31  |ce = "/dev/md0p1|
000013b0  22 0a 0a 73 74 61 74 75  73 20 3d 20 5b 22 41 4c  |"..status = ["AL|
000013c0  4c 4f 43 41 54 41 42 4c  45 22 5d 0a 66 6c 61 67  |LOCATABLE"].flag|
000013d0  73 20 3d 20 5b 5d 0a 64  65 76 5f 73 69 7a 65 20  |s = [].dev_size |
000013e0  3d 20 33 39 30 37 30 32  34 30 30 32 0a 70 65 5f  |= 3907024002.pe_|
000013f0  73 74 61 72 74 20 3d 20  35 37 37 0a 70 65 5f 63  |start = 577.pe_c|
00001400  6f 75 6e 74 20 3d 20 34  37 36 39 33 31 0a 7d 0a  |ount = 476931.}.|
00001410  7d 0a 0a 6c 6f 67 69 63  61 6c 5f 76 6f 6c 75 6d  |}..logical_volum|
00001420  65 73 20 7b 0a 0a 73 77  61 70 5f 31 20 7b 0a 69  |es {..swap_1 {.i|
00001430  64 20 3d 20 22 4c 78 45  47 54 31 2d 66 6d 67 52  |d = "LxEGT1-fmgR|
00001440  2d 58 47 47 58 2d 62 79  4f 74 2d 6a 32 70 36 2d  |-XGGX-byOt-j2p6-|
00001450  62 58 72 73 2d 53 61 73  4c 53 73 22 0a 73 74 61  |bXrs-SasLSs".sta|
00001460  74 75 73 20 3d 20 5b 22  52 45 41 44 22 2c 20 22  |tus = ["READ", "|
00001470  57 52 49 54 45 22 2c 20  22 56 49 53 49 42 4c 45  |WRITE", "VISIBLE|
00001480  22 5d 0a 66 6c 61 67 73  20 3d 20 5b 5d 0a 73 65  |"].flags = [].se|
00001490  67 6d 65 6e 74 5f 63 6f  75 6e 74 20 3d 20 31 0a  |gment_count = 1.|
000014a0  0a 73 65 67 6d 65 6e 74  31 20 7b 0a 73 74 61 72  |.segment1 {.star|
000014b0  74 5f 65 78 74 65 6e 74  20 3d 20 30 0a 65 78 74  |t_extent = 0.ext|
000014c0  65 6e 74 5f 63 6f 75 6e  74 20 3d 20 36 34 38 0a  |ent_count = 648.|
000014d0  0a 74 79 70 65 20 3d 20  22 73 74 72 69 70 65 64  |.type = "striped|
000014e0  22 0a 73 74 72 69 70 65  5f 63 6f 75 6e 74 20 3d  |".stripe_count =|
000014f0  20 31 09 23 20 6c 69 6e  65 61 72 0a 0a 73 74 72  | 1.# linear..str|
00001500  69 70 65 73 20 3d 20 5b  0a 22 70 76 30 22 2c 20  |ipes = [."pv0", |
00001510  31 36 36 38 0a 5d 0a 7d  0a 7d 0a 0a 72 6f 6f 74  |1668.].}.}..root|
00001520  62 75 6e 74 75 20 7b 0a  69 64 20 3d 20 22 71 6a  |buntu {.id = "qj|
00001530  4a 73 56 57 2d 38 69 57  70 2d 43 54 30 48 2d 59  |JsVW-8iWp-CT0H-Y|
00001540  71 6f 53 2d 68 73 6c 31  2d 79 46 54 4c 2d 4d 6c  |qoS-hsl1-yFTL-Ml|
00001550  7a 4d 75 62 22 0a 73 74  61 74 75 73 20 3d 20 5b  |zMub".status = [|
00001560  22 52 45 41 44 22 2c 20  22 57 52 49 54 45 22 2c  |"READ", "WRITE",|
00001570  20 22 56 49 53 49 42 4c  45 22 5d 0a 66 6c 61 67  | "VISIBLE"].flag|
00001580  73 20 3d 20 5b 5d 0a 73  65 67 6d 65 6e 74 5f 63  |s = [].segment_c|
00001590  6f 75 6e 74 20 3d 20 31  0a 0a 73 65 67 6d 65 6e  |ount = 1..segmen|
000015a0  74 31 20 7b 0a 73 74 61  72 74 5f 65 78 74 65 6e  |t1 {.start_exten|
000015b0  74 20 3d 20 30 0a 65 78  74 65 6e 74 5f 63 6f 75  |t = 0.extent_cou|
000015c0  6e 74 20 3d 20 33 38 34  30 0a 0a 74 79 70 65 20  |nt = 3840..type |
000015d0  3d 20 22 73 74 72 69 70  65 64 22 0a 73 74 72 69  |= "striped".stri|
000015e0  70 65 5f 63 6f 75 6e 74  20 3d 20 31 09 23 20 6c  |pe_count = 1.# l|
000015f0  69 6e 65 61 72 0a 0a 73  74 72 69 70 65 73 20 3d  |inear..stripes =|
00001600  20 5b 0a 22 70 76 30 22  2c 20 35 33 37 37 32 0a  | [."pv0", 53772.|
00001610  5d 0a 7d 0a 7d 0a 0a 68  6f 6d 65 62 75 6e 74 75  |].}.}..homebuntu|
00001620  20 7b 0a 69 64 20 3d 20  22 66 6f 33 48 42 57 2d  | {.id = "fo3HBW-|
00001630  42 4c 30 6e 2d 63 74 75  4f 2d 52 67 67 37 2d 55  |BL0n-ctuO-Rgg7-U|
00001640  30 33 68 2d 56 6f 72 62  2d 62 6a 71 38 63 50 22  |03h-Vorb-bjq8cP"|
00001650  0a 73 74 61 74 75 73 20  3d 20 5b 22 52 45 41 44  |.status = ["READ|
00001660  22 2c 20 22 57 52 49 54  45 22 2c 20 22 56 49 53  |", "WRITE", "VIS|
00001670  49 42 4c 45 22 5d 0a 66  6c 61 67 73 20 3d 20 5b  |IBLE"].flags = [|
00001680  5d 0a 73 65 67 6d 65 6e  74 5f 63 6f 75 6e 74 20  |].segment_count |
00001690  3d 20 33 0a 0a 73 65 67  6d 65 6e 74 31 20 7b 0a  |= 3..segment1 {.|
000016a0  73 74 61 72 74 5f 65 78  74 65 6e 74 20 3d 20 30  |start_extent = 0|
000016b0  0a 65 78 74 65 6e 74 5f  63 6f 75 6e 74 20 3d 20  |.extent_count = |
000016c0  39 34 39 34 36 0a 0a 74  79 70 65 20 3d 20 22 73  |94946..type = "s|
000016d0  74 72 69 70 65 64 22 0a  73 74 72 69 70 65 5f 63  |triped".stripe_c|
000016e0  6f 75 6e 74 20 3d 20 31  09 23 20 6c 69 6e 65 61  |ount = 1.# linea|
000016f0  72 0a 0a 73 74 72 69 70  65 73 20 3d 20 5b 0a 22  |r..stripes = [."|
00001700  70 76 30 22 2c 20 35 37  36 31 32 0a 5d 0a 7d 0a  |pv0", 57612.].}.|
00001710  73 65 67 6d 65 6e 74 32  20 7b 0a 73 74 61 72 74  |segment2 {.start|
00001720  5f 65 78 74 65 6e 74 20  3d 20 39 34 39 34 36 0a  |_extent = 94946.|
00001730  65 78 74 65 6e 74 5f 63  6f 75 6e 74 20 3d 20 35  |extent_count = 5|
00001740  31 34 35 36 0a 0a 74 79  70 65 20 3d 20 22 73 74  |1456..type = "st|
00001750  72 69 70 65 64 22 0a 73  74 72 69 70 65 5f 63 6f  |riped".stripe_co|
00001760  75 6e 74 20 3d 20 31 09  23 20 6c 69 6e 65 61 72  |unt = 1.# linear|
00001770  0a 0a 73 74 72 69 70 65  73 20 3d 20 5b 0a 22 70  |..stripes = [."p|
00001780  76 30 22 2c 20 32 33 31  36 0a 5d 0a 7d 0a 73 65  |v0", 2316.].}.se|
00001790  67 6d 65 6e 74 33 20 7b  0a 73 74 61 72 74 5f 65  |gment3 {.start_e|
000017a0  78 74 65 6e 74 20 3d 20  31 34 36 34 30 32 0a 65  |xtent = 146402.e|
000017b0  78 74 65 6e 74 5f 63 6f  75 6e 74 20 3d 20 31 36  |xtent_count = 16|
000017c0  36 38 0a 0a 74 79 70 65  20 3d 20 22 73 74 72 69  |68..type = "stri|
000017d0  70 65 64 22 0a 73 74 72  69 70 65 5f 63 6f 75 6e  |ped".stripe_coun|
000017e0  74 20 3d 20 31 09 23 20  6c 69 6e 65 61 72 0a 0a  |t = 1.# linear..|
000017f0  73 74 72 69 70 65 73 20  3d 20 5b 0a 22 70 76 30  |stripes = [."pv0|
00001800  22 2c 20 30 0a 5d 0a 7d  0a 7d 0a 7d 0a 7d 0a 23  |", 0.].}.}.}.}.#|
00001810  20 47 65 6e 65 72 61 74  65 64 20 62 79 20 4c 56  | Generated by LV|
00001820  4d 32 20 76 65 72 73 69  6f 6e 20 32 2e 30 32 2e  |M2 version 2.02.|
00001830  35 34 28 31 29 20 28 32  30 30 39 2d 31 30 2d 32  |54(1) (2009-10-2|
00001840  36 29 3a 20 54 75 65 20  53 65 70 20 32 31 20 31  |6): Tue Sep 21 1|
00001850  30 3a 33 38 3a 34 35 20  32 30 31 30 0a 0a 63 6f  |0:38:45 2010..co|
00001860  6e 74 65 6e 74 73 20 3d  20 22 54 65 78 74 20 46  |ntents = "Text F|
00001870  6f 72 6d 61 74 20 56 6f  6c 75 6d 65 20 47 72 6f  |ormat Volume Gro|
00001880  75 70 22 0a 76 65 72 73  69 6f 6e 20 3d 20 31 0a  |up".version = 1.|
00001890  0a 64 65 73 63 72 69 70  74 69 6f 6e 20 3d 20 22  |.description = "|
000018a0  22 0a 0a 63 72 65 61 74  69 6f 6e 5f 68 6f 73 74  |"..creation_host|
000018b0  20 3d 20 22 72 6d 79 70  72 6f 64 22 09 23 20 4c  | = "rmyprod".# L|
000018c0  69 6e 75 78 20 72 6d 79  70 72 6f 64 20 32 2e 36  |inux rmyprod 2.6|
000018d0  2e 33 32 2d 32 35 2d 67  65 6e 65 72 69 63 20 23  |.32-25-generic #|
000018e0  34 34 2d 55 62 75 6e 74  75 20 53 4d 50 20 46 72  |44-Ubuntu SMP Fr|
000018f0  69 20 53 65 70 20 31 37  20 32 30 3a 32 36 3a 30  |i Sep 17 20:26:0|
00001900  38 20 55 54 43 20 32 30  31 30 20 69 36 38 36 0a  |8 UTC 2010 i686.|
00001910  63 72 65 61 74 69 6f 6e  5f 74 69 6d 65 20 3d 20  |creation_time = |
00001920  31 32 38 35 30 35 38 33  32 35 09 23 20 54 75 65  |1285058325.# Tue|
00001930  20 53 65 70 20 32 31 20  31 30 3a 33 38 3a 34 35  | Sep 21 10:38:45|
00001940  20 32 30 31 30 0a 0a 00  00 00 00 00 00 00 00 00  | 2010...........|
00001950  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001a00

Où l'on voit bien le LVM sous toutes ses coutures.

Diagnostic du problème initial : Les PE ont bien été transférés sans chiffrage, et hors d'un conteneur luks. Cryptsetup au démarrage cherchant sont conteneur ne le trouvepas, et donc ensuite pas de montage du lvm, et pas les LV recherchés.

J'en reviens donc à mon second souci : pourquoi donc, maintenant que j'ai accès à nouveau à mon raid, tout se passe comme si j'étais sur l'ancien VG restauré alors que j'ai ce message (post précédent) qui me dit l'inverse…

Hoper · Le 27/09/2010, à 18:17

Yop.

Je vais pas etre constructif aujourd'hui. Je ne sais plus si je te l'ai dit mais je suis en arret maladie, et pour de bonnes raisons (rien de grave, mais le cerveau est clairement pas en état de tourner).

Juste que ton dernier post ne me surprend pas et confirme ton hypothèse, le pvmove a transféré la couche lvm sans le chiffrement qui était en dessous, c'est très logique.
Pour le reste... Il faut que je relise tout ça tranquillement, et la je suis pas en état...
J'y jèterai un œil demain... ou après demain...

rmy · Le 28/09/2010, à 02:20

récupère bien, et gaffe au surmenage.

Sérieusement, il y a 2 ans, j'ai fait une grippe un peu sévère. Suite à ça, pendant 6 jours je ne pouvais plus parler sans bégayer, impossible de trouver mes mots, un véritable zombie. L'impression d'avoir des "flashs" dans le cerveau toutes les deux ou trois secondes. J'ai eu peur que cet état soit définitif, et mon toubib' aussi. Tous mes examens étaient normaux, il commençait à penser à un syndrome de fatigue… et puis c'est parti comme c'était venu.

Hoper · Le 29/09/2010, à 13:43

Content que tu t'en sois remis... Moi ca va aller, pas de soucis... un peu de repos encore et ca je serai en pleine forme.
En attendant... si on résumé, quand tu fais la même opération (le pvmove d'avant donc) tu ne retrouve pas le vg c'est ça ? (alors qu'un hexdump te montre le vg, présent et non chiffré sur le disque) ?

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

je n'ai pas refait le pvmove, et je complèterai ma réponse demain, ou vendredi. Là, c'est moi qui suis cuit, et la tête dans le guidon.

rmy · Le 02/10/2010, à 01:43

Heu… ça peut encore attendre demain, non ?

Dernière modification par rmy (Le 02/10/2010, à 01:43)

rmy · Le 02/10/2010, à 17:35

Bon, alors, pour résumer :
1/ Je fais un Pvmove de sda vers raid mais pas vers un conteneur luks
2/ Au reboot, busybox.
3/ reboot clé usb -> configuration lvm restaurée sur sda, raid reconnu comme lvm2_member, mais rien au [pv|vg|lv]+[scan|display]
4/ reboot sda seul : OK, mais données postérieures au pvmove sur le système resté allumé perdues (enfin, à priori sur le raid si j'ai bien compris)
5/ reboot sda+raid : busybox (j'avais oublié de modifier mon crypttab)
6/ reboot clé usb -> restaurer config lvm sur sda à nouveau, et modifier crypttab
7/ reboot sda + raid -> OK, et les infos lvm m'annoncent que c'est le PV du raid qui est utilisé oO curieux curieux, car les données sont bien celles de sda (sachant qu'entre temps j'ai continué à bosser sur sda avec raid débranché)
8/ Chaque fois que je reboote, je perds la config lvm sur sda et je suis obligé de faire un cfgrestore.

Je voudrais savoir si, comme ça, spontanément, tu as une idée pour que je puisse récupérer les quelques données perdues dans l'espace temps de mon raid, c'est à dire ce que j'ai fait à chaud pendant le pvmove et la synchro du raid. Pas grand chose, mais un mail d'un futur client potentiel qui ne me recontacte pas et que j'aimerais relancer ^^

Sinon, tant pis, je resterai frustré de ne pas avoir trouvé solution à ce problème, mais c'est vraiment rien de grave (comparé aux 20 jours de retard de sauvegarde… ) et j'enchaînerai en recommençant tout à zéro, avec un gros luks comme il faut, toussa…

Hoper · Le 04/10/2010, à 08:28

Whaou... heu... la ... comme ça.... non... vraiment je vois pas...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 23/09/2010, à 16:13

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

#52 Le 23/09/2010, à 16:20

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

#53 Le 23/09/2010, à 19:33

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

#54 Le 23/09/2010, à 19:34

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

#55 Le 23/09/2010, à 19:43

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

#56 Le 23/09/2010, à 20:47

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

#57 Le 23/09/2010, à 22:26

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

#58 Le 23/09/2010, à 22:47

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

#59 Le 24/09/2010, à 09:47

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

#60 Le 24/09/2010, à 10:58

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

#61 Le 24/09/2010, à 11:06

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

#62 Le 24/09/2010, à 16:00

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

#63 Le 25/09/2010, à 10:49

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

#64 Le 26/09/2010, à 10:30

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

#65 Le 26/09/2010, à 10:47

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

#66 Le 26/09/2010, à 10:52

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

#67 Le 26/09/2010, à 10:57

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

#68 Le 26/09/2010, à 13:14

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

#69 Le 27/09/2010, à 18:17

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

#70 Le 28/09/2010, à 02:20

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

#71 Le 29/09/2010, à 13:43

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

#72 Le 29/09/2010, à 22:14

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

#73 Le 02/10/2010, à 01:43

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

#74 Le 02/10/2010, à 17:35

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

#75 Le 04/10/2010, à 08:28

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

Pied de page des forums