Problème Cryptage Luks disque externe après réinstallation système

Atanasoff · Le 29/08/2011, à 12:56

Bonjour à vous,

Un problème important m'amène à vous consulter avant d'entreprendre quoi que ce soit.
Je me débrouille assez bien en général sous Ubuntu depuis des années. Mais là, je pense qu'il vaut mieux "consulter" avant toute opération.
Le problème:

Suite à des secteurs en attentes de "réalocation" (6 secteurs) sur mon disque dur, J'ai entrepris de sauvegarder illico mes données sur un disque externe. Tout s'est bien passé à qqu fichier système dans le /home, sans grande importance pour une réinstallation.
Seulement voilà... Le disque externe était utilisé avec LUKS.
Pensant bien faire pour ne pas avoir de problème, je l'ai formaté vite-fait en ext4 avant d'y placer mes données en sécurité. (pensant alors qu'il n'était plus crypté).
Après la réinstallation de mon système, à ma grande horreur, la partition est déclarée inconnue sur le disque !
J'ai alors pensé que celle-ci était toujours contenue dans le système de chifrage LUKS, malgré mon formatage... Logique en fait !
Pas de panique donc, car en bon utilisateur de volumes chiffrés divers, j'avais fait un "LUKS Dump" bien AVANT le reformatage (cad quand j'avais créer le volume pour la première fois).
Chose que je préconise de faire avec toute partition chiffrée, vous en conviendrai.
J'ai essayé de remonter le volume prétendument chiffré avec:

sudo cryptsetup luksOpen /dev/sdd1 crypto

Réponse du système:

Device /dev/sdd1 is not a valid LUKS device.

Je ne sais pas trop quoi faire, tant je ne connais pas trop Luks dans les détails (utilisant plutôt Truecrypt).
Le montage du disque était transparent au login, conformément au tuto suivant: http://doc.ubuntu-fr.org/cryptsetup .

Alors, LA question à 5 cents: Ce volume est-il chiffré ou non ?
Que préconisez-vous ?

NB: J'ai également booté en live: même problème (version 32 et 64 bits).

A ce stade, la tension commence à monter solidement, car il s'agit d'une grosse partie de mes données personnelles, documents, photos, bref, 20 ans de vie au moins ! ("Heureusement", grâce à UbuntuOne, mes documents administratifs sont au moins récupérés - Merci Canonical !).

Je vous remercie vivement pour votre collaboration, le problème étant TRÈS critique pour moi.

Dernière modification par Atanasoff (Le 29/08/2011, à 13:21)

Atanasoff · Le 29/08/2011, à 13:04

A titre d'info, le Dump du volume Luks AVANT le reformatage:

LUKS header information for /dev/sdb2

Version:           1
Cipher name:       aes
Cipher mode:       lrw-benbi
Hash spec:         sha1
Payload offset:    3016
MK bits:           384
MK digest:         13 bf a9 69 9a 08 31 fc 0f 59 d2 3f 91 f6 12 b2 4b 22 b2 0c 
MK salt:           5b 5a 28 b8 2e 14 de 5b 90 64 ab 34 27 0c 5f 8e 
                   49 c2 2b 28 50 0b 06 b8 e6 55 87 9d 25 04 16 0d 
MK iterations:     33000
UUID:              84dc0e1c-c812-4afd-8895-c760f91f6c13

Key Slot 0: ENABLED
    Iterations:             132272
    Salt:                   ef ab c3 c7 f1 68 f5 a4 72 2c 63 ec d7 ed 2a ca 
                              54 7d 73 5d cf ab be 8a 95 2c 80 45 2e f7 de 2e 
    Key material offset:    8
    AF stripes:                4000

Hoper · Le 29/08/2011, à 13:45

J'ai entrepris de sauvegarder illico mes données sur un disque externe. Tout s'est bien passé à qqu fichier système dans le /home, sans grande importance pour une réinstallation.
Seulement voilà... Le disque externe était utilisé avec LUKS.
Pensant bien faire pour ne pas avoir de problème, je l'ai formaté vite-fait en ext4 avant d'y placer mes données en sécurité. (pensant alors qu'il n'était plus crypté).

Il faudrait que tu détaille un peu les opérations la, parce que c'est pas très clair. Qu'a tu fais exactement ? Ce que j'ai compris :

tu as formaté un disque externe qui était avant utilisé avec luks en ext4, c'est ça ? Avec une commande du type mkfs.ext4 /dev/sdX ?
Ensuite tu as simplement copié tes fichiers dessu, c'est ça ? (commande cp ou équivalent ?) Si c'est ça, alors effectivement il ne peut plus y avoir de trace de l'ancien chiffrement.

As tu correctement démonté ton disque après la copier ? (umount...)

Atanasoff · Le 29/08/2011, à 14:01

C'est tout à fait cela, tu as bien compris.
Sauf que je n'ai pas formaté en ligne de commande mais avec Gparted (car j'étais dedans pour d'autres opérations alors by the way....).
Le formatage Gparted me semble identique à la ligne de commande mkfs.ext4 /dev/sdX n'est-ce pas ?

Je ne sais plus si j'ai correctement démonté le disque, mais j'ai correctement éteint le système. J'imagine qu'il a fait son travail de démontage correctement.

A noter, j'avais recommencé ces opérations deux fois (avec deux fois le problème identique).
Je ne me suis malheureusement pas inquiété outre mesure, pensant qu'il s'agissait d'une fantaisie du live-CD.

Merci pour l'intervention.

Dernière modification par Atanasoff (Le 29/08/2011, à 14:04)

Atanasoff · Le 29/08/2011, à 18:30

Bon ben..... j'ai l'impression que mon cas ne passionne pas les foules.....
J'ai comme l'impression qu'il est plus intéressant d'expliquer des détails abscons que d'aider une personne qui vient de perdre toute ces données en faisant confiance à Linux. Je dis cela sérieusement, car j'ai toujours utilisé Truecrypt pour mes chiffrages, sans problèmes aucun.
Crypt-setup / Lux m'avait séduit pour le côté intégré à la session utilisateur. Le comble: On dit qu"il a été écrit pour ne plus que des mauvaises expériences arrivent aux utilisateurs (la bonne blague).
Bien mal m'en a pris. Visiblement ma partition est restée cryptée, malgré un formatage (concept de container crypté ?).
Je pense sincèrement, au regard de cette blague et à ce qui arrive à de nombreux utilisateurs, que pas mal de choses ne sont pas au point en tant que SERVICE à l’utilisateur. Dans ce cas, je ne pourrais que suggérer à Canonical de maintenir ces paquets en dehors du cadre de la distribution. Imaginez cela dans un environnement professionnel... "Je pensais que... mais oui mais non...".
Bon... avant de faire quoi que ce soit, je vais tenter ma chance du côté anglo-saxon.

Si je n'ai qu'un conseil à donner aux utilisateurs Ubuntu: Fuyez le cryptage comme la peste. Il n'est pas assez transparent et intégré.
Le mélange cryptsetup/Luks n'est pas là pour arranger les choses, que du contraire, au regard des nombreux blogs mélangeant les deux.

Levi59 · Le 29/08/2011, à 18:57

Je ne peux pas t'aider mais je vais tout de même emettre un commentaire.

Comme 90% (à la louche) des personnes de ce forum qui proposent leur expérience sur ce forum, je ne suis absolument pas un professionnel de l'informatique. Les pro étant rares et travaillant bénévolement, sur leur temps libre, à aider les utilisateurs, je m'insurge de voir quelqu'un manquer autant de patience ( Hoper qui tente actuellement de t'aider à posté un peu avant 14h...) semblant penser que son problème est le seul qui compte et que toute la communauté ne devrait s'occuper que de toi. (C'est en tout cas l'impression que j'ai eu en lisant ton dernier post)

Je ne dis pas que ton problème n'est pas gênant mais rappel toi que ce forum est gratuit, en grande partie maintenu par le bénévola et qu'il est rare de régler un problème en 2-3 heures. (si c'était le cas alors ce ne serait pas un problème grave)
Arme toi d'un peu de patience et tu trouveras certainement une bonne âme pour t'aider!

Tu peux par exemple t'adresser à rmy qui pourra (peut etre) t'aider à récupérer tes données... ./profile.php?id=20551

Dernière modification par Levi59 (Le 29/08/2011, à 18:57)

Atanasoff · Le 29/08/2011, à 19:29

C'est justement la question que je me pose....
Ayant quitté Windows après des années de bons et loyaux services (y compris dans le monde pro), je me suis lancé sur Linux avec Ubuntu...
Je pense avoir toujours tout su régler tout seul n cherchant mais là, étant donné la GRAVITÉ de la chose (on parle tout de même de données personnelle de toute une vie), je me pose la question suivante:
Est-ce parce-que le libre est gratuit que l'on peut accepter de telles réponses (celle de Levi et non celle de Hoper), car je conçoit que tout le monde n'est pas expert de ce truc abscons appelé Luks et compagnie.
Je ne pense pas au hasard car je vois qu'il semble plus intéressant pour certains de régler des bidouilles en terminal que ce problème de fond qui ne me concerne pas MOI seul.
C'est le contre-coup du logiciel libre. Il est impossible de demander des dommages et intérêts en cas de problème.
Pendant toute cette journée, j'ai lus ça et là..... C'est incroyable le nombre de personne qui perdent leur données avec cette chose innommable !!
Et je ne parle pas de newbies, je suis professionnel, merci (pas Linux sys-admin certes). La seule erreur que j'ai fait dans cette histoire est de ne pas avoir évalué cette techno à fond avant de lui faire confiance. Je risque de le payer très cher.
Le problème est qu'à force d'écrire des couches de couches de code, on en arrive à un truc inexploitable dans la pratique (avec changement de systèmes, de kernel etc).
Je n'ai JAMAIS eu la moindre blague avec Truecrypt. Le bidule est monolithique et vraiment multiplateforme bref, pas de question à ce poser quoiqu'il arrive. Pour preuve: mes partitions TC sont opérationnelles après réinstallation.
Je ne suis pas d'accord avec le postulat qui consiste à dire que si ce n'est pas grave, c'est vite résolu.
Je vois souvent ici et ailleurs, des discussions interminables pour des futilités sans nom.
La perte de données est la chose la plus grave en informatique, elle constitue une faute grave dans un cadre professionnel.
Je ne presse personne et je n'estime pas que je suis le seul sur terre (il suffit d'un googeling pour se rendre compte du contraire sur cette problématique!).
Je ne vais certainement pas m'armer de patience et attendre sur un seul forum. Je vais les éplucher un à un jusqu'à ce que je trouve une raison à cette histoire car il n'y a pas eu d'erreur de manipulation. Bref, pas le mec qui débarque parce qu'il a crypté ses disques sans faire un dump ou au moins noter ses clés et qui eng.. tout le monde en menaçant de prendre Windows ou Apple. (mais Luks - no way ! ).

Dernière modification par Atanasoff (Le 29/08/2011, à 19:34)

duffy76 · Le 30/08/2011, à 16:04

D'après ce que j'ai compris :
tu avais un disque interne I que tu voulais sauvegarder
tu as copié les données sur un disque externe E
tu t'es aperçu que E était chiffré avec luks (avec une structure du genre : disque - luks - extn - fichiers)
tu as formaté E en ext4 (avec ext-4 directement au dessus du disque : disque - ext4 - fichiers)
tu as a nouveau copié les données sur E
tu as réinstallé ton OS sur I
tu t'es aperçu qu'aucun système de fichier n'était détecté sur E
Si toutes les étapes mentionnées sont les bonnes (en tout point) le problème vient sans doute du système de fichier ext4 que tu as mis sur E (sauf panne matériel), tu peux tenter photorec pour récupérer tes données (je ne sais pas ce que ça donne avec ext4) en faisant attention de ne pas réécrire sur le même disque.
Sinon, précise *exactement* ce que tu as fais à chaque étape.
Enfin avant toute manipulation qui aurait pour conséquence une éventuelle écriture, je te conseille une copie brute du disque supposé contenir des données utiles (par exemple avec dd if=/dev/disque of=/home/image bs=1M)

Sur un plan moins technique, la seule erreur que tu as fait est de ne pas avoir vérifié que ta sauvegarde était fonctionnelle, et ceci n'a rien à voir avec la techno utilisée. De plus, si les données sont aussi importantes que ça pour toi, un peu de redondance eu été bienvenue. Pour le problème du service à l'utilisateur, Canonical n'a jamais dis qu'il était gratuit et fourni avec le CD…

Bon courage et n'hésite pas à poser d'autres questions si tu as plus de détails

PS : je n'ai pas non plus une politique de sauvegarde irréprochable et j'ai aussi perdu des données.

Dernière modification par duffy76 (Le 30/08/2011, à 16:08)

Atanasoff · Le 30/08/2011, à 17:37

Bonjour,

Et bien merci à toi de relancer le sujet (car il faut bien admettre qu'il était mal parti sur des considérations philosophiques certes intéressantes, mais pas vraiment de quoi faire un beau fil avec un "résolu" à la fin - j’admets en être responsable de part le stress que cela produit et je préciserai ma pensée brièvement après avoir répondu à tes questions).

DONC:
tu avais un disque interne I que tu voulais sauvegarder OUI (car potentiellement défaillant).
tu as copié les données sur un disque externe E OUI (ce disque était le disque de backup usuel).
tu t'es aperçu que E était chiffré avec luks (avec une structure du genre : disque - luks - extn - fichiers) OUI (je ne suis pas certain de la structure que tu indiques là car "extn" ne me dit rien, mais je peux dire que la partition = tout le disque).
tu as formaté E en ext4 (avec ext-4 directement au dessus du disque : disque - ext4 - fichiers) OUI (à l'aide de GParted, car je voulais éviter des ennuis du au chiffrement - j'en ai peut-être créer plus à cause de cela).
tu as a nouveau copié les données sur E OUI
tu as réinstallé ton OS sur I OUI (avec formatage bas niveau de tout le disque (pour les secteurs en attentes de réaloc), puis formatage classique pour ext4 dans mon cas).
tu t'es aperçu qu'aucun système de fichier n'était détecté sur E OUI (sauf le nouveau / et le nouveau /home bien entendu, ainsi que les partitions EXT4 d'autres disques externes ET celles cryptées avec Truecrypt).

Il est vrai que je devrais faire une copie bas niveau de ce disque avant toute tentative d'écriture afin de pouvoir continuer en cas de gourde. Il me faut juste trouver 500 Gb sous le coude (je crois que j'ai ça ;-) ).

Pendant que j'attendais une réponse ça et là, j'ai potassé et fait des tests sur mes disques (en faisant TRÈS attention de ne pas ouvrir la partition litigieuse en lecture/écriture ! ).
Je vais poster le résultat des mes tests, afin que cela puisse servir à d'autres, et à nous !
J'ai en l’occurrence simuleé ce que j'ai fait sur une autre partition cryptée nouvellement créée, et refait le formatage censé écraser le cryptage. Je confirme donc ce qui a été dit: Cela écrase bien la partition cryptée et ne produit donc pas un système de fichier crypté et encapsulé.
Il se serait donc passé qqch lors du démontage (à moins d'un autre problème matériel, mais un diagnostic SMART ne signale rien sur ce disque externe).
Suite au prochain post pour le résultat de mes petits tests sur la partition...

Pour l'aspect "moins technique": Je suis en général prudent comme un sioux avec tout ceci. J'effectue des backup des données, des dumps des headers des fichiers crypté, je teste des scenari de restauration (le plus important à mon sens).
Et là ou je suis d'accord avec toi, c'est qu'après ma copie, j'ai testé en live-CD une série de choses (dont mon disque 'I' corrompu et curieusement, je n'ai pas prêté attention au fait que cette partition n'était plus visible à ce moment (le disque E donc).
Par contre, il y a une information importante à donner: Lorsque j'ai rebooter sur mon disque 'I', cette partition 'E' était à nouveau visible !
(c'est à cause de cela que je ne me suis pas trop inquiété - à tort) et je ne m'explique toujours pas pourquoi...
Sachant cela, je suis parti du principe que cette partition était encore cryptée. Nous savons à présent que ce n'est normalement pas le cas.
Pour ton affirmation, sans vouloir rentrer dans une polémique, ben le backup était la redondance. Mais j'aurais du produire une redondance de la redondance étant donné la racine appelée à disparaître... A ce titre, je trouve le Cloud intéressant car en cas de vol ou d'incendie, tout disparaît de toute façon. A méditer !
Pour le problème du service enfin: Il est évident que je n'exige rien venant d'un forum bénévole (étant habitué à contribuer sur d'autres forum pour une autre passion).
Mais je voulais simplement dire qu’étend donné une certaine difficulté qu'éprouve un utilisateur lambda avec LUKS, celui-ci ne devrait plus être dans les dépôts Canonical. Car comme je l'ai dit, tout ce qui touche aux données est ce qu'il y a de plus crutial.
A ce titre (en aparté), j'ai un projet (au stade de l'idée) de blog pour personnes désirant migrer du monde Windows ou MacOS, vers Ubuntu, avec des tuto quasi full graphique (pas de commande en ligne donc). Dans bien des cas, cela devient possible, mais nous gardons nos vieilles habitudes... (sous MacOs ont sait aussi faire du terminal en BSD, mais ils ont tout fait pour que cela n'arrive pas).

Un grand merci à toi d'avoir relancé ce sujet, mais je pense que nous devrons le renommer "récupération de partition ext4" ;-)
suite de mes tests au post suivant.

Pere Collateur · Le 30/08/2011, à 17:47

Bon je vais peut etre enfoncer des portes ouvertes, mais avez vous fait par exemple un

fdisk /dev/sdd

Puis tappé 'p' pour voir exactement la liste des partitions qui se trouve sur ce fameux disque dure externe?

Dernière modification par Pere Collateur (Le 30/08/2011, à 17:48)

Atanasoff · Le 30/08/2011, à 17:54

J'ai donc fait des petits test en lecture sur cette partition:

dumpe2fs /dev/sdc1 |grep 'superbloc Secours' |awk  '{ print $1,$2,$3,$4 }'

Cette commande permet de "voir" l'état des superblocs de secours d'une partiton EXT*

donne :

dumpe2fs 1.41.14 (22-Dec-2010) 
dumpe2fs: Bad magic number in super-block lors de la tentative d'ouverture de /dev/sdc1

A ce stade je me suis dit "est-ce parce-que c'est crypté ou tout simplement bousillé ?"
Alors j'ai fait ceci:

sudo mkfs.ext4 -n /dev/sdc1

Attention: sans "-n", vous écrivez sur la partition !
Cette commande est relativement semblable à la précédente sur le plan sémantique.

donne:

mke2fs 1.41.14 (22-Dec-2010) 
Étiquette de système de fichiers= 
Type de système d'exploitation : Linux 
Taille de bloc=4096 (log=2) 
Taille de fragment=4096 (log=2) 
« Stride » = 0 blocs, « Stripe width » = 0 blocs 
30531584 i-noeuds, 122096384 blocs 
6104819 blocs (5.00%) réservés pour le super utilisateur 
Premier bloc de données=0 
Nombre maximum de blocs du système de fichiers=4294967296 
3727 groupes de blocs 
32768 blocs par groupe, 32768 fragments par groupe 
8192 i-noeuds par groupe 
Superblocs de secours stockés sur les blocs : 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000

Là, je pense que l'on peut dire que ce n'est pas une partition cryptée. Mais peut-être que non, car nous sommes au niveau système de fichier...

Puis je me suis intéressé à la table des partitions (aurait p-e du commencer par là...).

sudo fdisk -lu /dev/sdc1 

Disque /dev/sdc1: 500.1 Go, 500106788864 octets 
255 têtes, 63 secteurs/piste, 60801 cylindres, total 976771072 secteurs 
Unités = secteurs de 1 * 512 = 512 octets 
Taille de secteur (logique / physique) : 512 octets / 512 octets 
taille d'E/S (minimale / optimale) : 512 octets / 512 octets 
Identifiant de disque : 0x00000000 

Le disque /dev/sdc1 ne contient pas une table de partition valide

J'en conclus donc que la partition ne serait même pas touchée mais le problème viendrait plutôt de la table visiblement corrompue.
Il n'en reste pas moins curieux que la première commande de ce post renvoie néanmoins une erreur.
Mes investigations se sont arrêtées là pour le moment et je vais effectuer une image bas-niveau de la partition avant toute tentative d'écriture.

Levi59 · Le 30/08/2011, à 18:10

J'ai déjà eu un problème de table de partition foireuse sur un disque... Le disque semblais vide mais contenait toujours les donnée. Comme ce n'était pas tout à fait ton cas je n'y avait pas pensé mais sais on jamais...

Tu devrais tenter une réparation de la table via "testdisk" si cela n'as pas encore été tenté.

Atanasoff · Le 31/08/2011, à 14:02

Bonjour,
J'ai repris le problème à bras le corps et je cherche actuellement à faire une copie bas-niveau du disque entier (et non de la partition - même si elle fait tout le disque en capacité).
Après examen de la commande 'dd', je trouve la copie en image ISO intéressante car je n'ai alors pas à devoir faire de la place sur le dernier disque qui me reste afin d’accueillir une partition de 500 Gb (déplacement de partitions etc.).
Mais voilà, le tuto http://doc.ubuntu-fr.org/dd explique que lors de la création d'une image ISO, la structure est modifiée....
Savez-vous si cela pose un problème à comparer à une copie parfaite bit-à-bit ?

Atanasoff · Le 31/08/2011, à 22:20

En attendant une confirmation sur l'oportunité d'utiliser une copie "image" au format iso, j'ai lancé la chose:

sudo dd if=/dev/sdc1 of=/media/97738d0f-87f3-427f-b328-4139b13ca7ec/Backup/imagehd.iso
dd: écriture vers «/media/97738d0f-87f3-427f-b328-4139b13ca7ec/Backup/imagehd.iso»: Système de fichiers accessible en lecture seulement
2297765+0 enregistrements lus
2297764+0 enregistrements écrits
1176455168 octets (1,2 GB) copiés, 88,8078 s, 13,2 MB/s

Ce qui m'inquiète un peu, c'est le "(1,2 GB) copiés" .... Cela devrait-être bien plus.
L'image résultant (fichier .iso) fait pourant: 664,0 Mio (696254464 octets).
Qui croire...

Pere Collateur · Le 01/09/2011, à 11:40

A ce stade, difficile de se prononcer. Montez l'image iso et regardez ce qu'elle contient.

Dernière modification par Pere Collateur (Le 01/09/2011, à 11:40)

Atanasoff · Le 01/09/2011, à 14:07

Pere Collateur a écrit :

A ce stade, difficile de se prononcer. Montez l'image iso et regardez ce qu'elle contient.

Elle contiendra en la même chose que le disque physique non ? cad un vrai bordel... Vais tout de même tenter....

J'ai avancé et donc créé une image iso ,une sauvegarde du MBR, ET des 63 premiers secteurs, étant entendu que pour un disque avec une seule partition primaire, la table de partition devrait se trouver là.

Là je travaille avec le programme 'Testdisk', comme proposé ci-dessus.
Il m'a renvoyé un résultat suivant:

Results
   * Linux                    0   1  1     0 254 63      16002
     LUKS 1 (Data size unknown), 8193 KB / 8001 KiB

N'étant un un connaisseur de ce programme, j'ai tenté de changer le type de partition en * à P (boot à primaire) et à écrire le MBR tel que présenté.
Après avoir quitté le programme, j'ai monté le disque et le système m'a demandé une passphrase Luks ! (il faut le faire, après un formatage de la partition en ext4). Comble du comble, il a accepté ma passphrase mais à déclareé le système de fichier inconnu.
Il reste donc bien des informations sur cette partition cryptée qui avait été écrasée par une EXT4 "classique".

Je ne vais pas aller plus loin sur cette voie (Luks µ-scopique + grand vide) car pour moi, ce disque doit être occupé totalement par une EXT4. Le problème, c'est de savoir ou elle démarre et ou elle se termine. J'ai tenté une recherche approfondie sur le disque, mais rien pour le moment...

Atanasoff · Le 02/09/2011, à 13:38

J'ai donc continué mes recherches sur ce disqueavec Testdisk. Il m'a trouvé une partition au beau milieu du disque. Ce n'est pas normal et je n'en tiens pas compte. Donc pas de tentative d'écriture pour la récupérer.
Le montage de l'image de cette partition et l'examen à l'aide d'un éditeur hexa montre qu'il y a des données (les miennes).
Le montage de l'image du disque au TOTAL montre qu'il y a des données sur l'ensemble du disque.
Comprenant que Tesdisk a échoué dans son examen du disque pour en reconstruire l'unique partition, je me suis lancé à la récupération des données à l'aide de Photorec... Il retrouve bien des données, il est en cours d'examen...

Si quelqu'un à une idée pour reconstruire cette partition qui occupait la totalité du disque, je suis preneur, pensant que Photorec ne retrouvera pas toutes mes données (spécialement les fichiers mails de Thunderbird, les plus importants à mes yeux).

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 29/08/2011, à 12:56

Problème Cryptage Luks disque externe après réinstallation système

#2 Le 29/08/2011, à 13:04

Re : Problème Cryptage Luks disque externe après réinstallation système

#3 Le 29/08/2011, à 13:45

Re : Problème Cryptage Luks disque externe après réinstallation système

#4 Le 29/08/2011, à 14:01

Re : Problème Cryptage Luks disque externe après réinstallation système

#5 Le 29/08/2011, à 18:30

Re : Problème Cryptage Luks disque externe après réinstallation système

#6 Le 29/08/2011, à 18:57

Re : Problème Cryptage Luks disque externe après réinstallation système

#7 Le 29/08/2011, à 19:29

Re : Problème Cryptage Luks disque externe après réinstallation système

#8 Le 30/08/2011, à 16:04

Re : Problème Cryptage Luks disque externe après réinstallation système

#9 Le 30/08/2011, à 17:37

Re : Problème Cryptage Luks disque externe après réinstallation système

#10 Le 30/08/2011, à 17:47

Re : Problème Cryptage Luks disque externe après réinstallation système

#11 Le 30/08/2011, à 17:54

Re : Problème Cryptage Luks disque externe après réinstallation système

#12 Le 30/08/2011, à 18:10

Re : Problème Cryptage Luks disque externe après réinstallation système

#13 Le 31/08/2011, à 14:02

Re : Problème Cryptage Luks disque externe après réinstallation système

#14 Le 31/08/2011, à 22:20

Re : Problème Cryptage Luks disque externe après réinstallation système

#15 Le 01/09/2011, à 11:40

Re : Problème Cryptage Luks disque externe après réinstallation système

#16 Le 01/09/2011, à 14:07

Re : Problème Cryptage Luks disque externe après réinstallation système

#17 Le 02/09/2011, à 13:38

Re : Problème Cryptage Luks disque externe après réinstallation système

Pied de page des forums