[Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

geole · Le 09/11/2020, à 12:47

Bonjour
Extraits du contenu de ton boot-info
1) Le boot avec le MBR du SDA

 => Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of 
    the same hard drive for core.img. core.img is at this location and looks 
    for /grub. It also embeds following components:
        modules
    ---------------------------------------------------------------------------
    fshelp ext2 part_msdos biosdisk search_fs_uuid
    ---------------------------------------------------------------------------
        config script
    ---------------------------------------------------------------------------
    search.fs_uuid 670763df-c912-4d1d-9acc-e6d29e3854fd root hd1,msdos1 
    set prefix=($root)'/grub'

2) qui se poursuit sur la première partition de l'autre disque

sdb1: __________________________________________________________________________
    File system:       ext4
    Boot sector type:  Grub2 (v1.99-2.00)
    Boot sector info:  Grub2 (v2.00) is installed in the boot sector of sdb1 
                       and looks at sector 434464 of the same hard drive for 
                       core.img. core.img is at this location and looks for 
                       (,msdos1)/grub. It also embeds following components:
                       modules
                       -------------------------------------------------------
                       fshelp ext2 part_msdos biosdisk
                       -------------------------------------------------------
    Operating System:  
    Boot files:        /grub/grub.cfg /grub/i386-pc/core.img

3) En lisant ce fichier

======================== sdb1/grub/grub.cfg (filtered) =========================
Ubuntu   b22b9645-5b65-47d8-8ace-39129246214f
Ubuntu, avec Linux 5.3.0-28-generic   b22b9645-5b65-47d8-8ace-39129246214f

4) qui devrait donc mettre en route cette partition

mapper/luks-eff299eb-0f1b-46ee-947d-49fbf40b4c68 426.8G   1% /media/ubuntu/b22b9645-5b65-47d8-8ace-39129246214f 
└─sdb5                                        crypto_LUKS eff299eb-0f1b-46ee-947d-49fbf40b4c68 fa4fb498-05 
sdb5: __________________________________________________________________________
    File system:       crypto_LUKS
    Boot sector type:  Unknown
    Boot sector info:

Mais, comme elle est chiffrée, on n'en saura pas tellement plus

A noter que cette partition ne semble pas contenir grand chose

f (filtered): _________________________________________________________________
                                                  Avail Use% Mounted on
mapper/luks-eff299eb-0f1b-46ee-947d-49fbf40b4c68 426.8G   1% /media/ubuntu/b22b9645-5b65-47d8-8ace-39129246214f

4,26 Go me semble petit pour contenu un ubuntu complet

A noter: clé persistante

====================== sdc1/boot/grub/grub.cfg (filtered) ======================
ubuntu-18.04.4-desktop-amd64.iso
Mode persistent ubuntu-18.04.4-desktop-amd64.iso

je n'ai aucune idée de la cause du grub-rescue.

Si tu n'as pas un petit message soit avant la ligne grub rescue soir après, on est mal barré

Remarque, si ce commentaire "et une étendue chiffrée comme conseillé, " m'est destiné, j'ai probablement très très mal expliqué.

Dernière modification par geole (Le 09/11/2020, à 12:51)

Coeur Noir · Le 09/11/2020, à 18:45

« une installation toute simple sans chichi avec juste une partition / avec tout dedans, pas de /home séparé ou autre cosmétique.
Garde toi de l'espace pour une autre partition, sûrement nécessaire ensuite. »
Je n'ai pas non plus évoqué de chiffrer la nouvelle installation.

Mais ça fait pas avancer le schmilblick : y a-t-il encore quelque chose de récupérable depuis sda ?

( le chiffrement a parfois son utilité mais ça ajoute surtout - par nature - de la complexité à la gestion des données ).

MonsterNunch · Le 09/11/2020, à 22:02

Coeur Noir a écrit :

Je n'ai pas non plus évoqué de chiffrer la nouvelle installation.
Mais ça fait pas avancer le schmilblick : y a-t-il encore quelque chose de récupérable depuis sda ?
( le chiffrement a parfois son utilité mais ça ajoute surtout - par nature - de la complexité à la gestion des données ).

Je voulais vraiment un espace sécurisé et j'espère vraiment que je pourrai récupérer des données : je pense essayer Photorec.

geole a écrit :

Remarque, si ce commentaire "et une étendue chiffrée comme conseillé, " m'est destiné, j'ai probablement très très mal expliqué.

Comme évoqué sur l'autre fil :

MonsterNunch a écrit :

Désolé, je n'ai voulu incriminer personne, j'ai certainement mal compris et surtout mélangé avec ce qui était aussi expliqué là https://doc.ubuntu-fr.org/tutoriel/chif … ssiquement

Du coup, pour simplifier, je vais refaire une installation propre non chiffrée sur sdb, avec beaucoup de place pour l'espace à chiffrer à côté et j'ai commandé un autre disque dur pour tester la récupération des données du sda via Photorec ultérieurement.

geole a écrit :

A noter que cette partition ne semble pas contenir grand chose

Oui, de toute façon, c'est négligeable.

geole a écrit :

A noter: clé persistante

Oui, c'est mon Live USB que j'utilise en persistant pour ne pas avoir à réeinstaller les outils de diagnostique à chaque fois.

Du coup, comme j'attends mon disque tampon, je pense que ce fil sur la récupération peut être mis en pause ...

geole · Le 10/11/2020, à 00:03

Si tu as l'autre ubuntu installé, comme tu aurras 490 go de libre, c'est un bon départ pour voir si photorec sait récupérer les photos sans attendre l'arrivée d'un autre disque.
Tu peux aussi lancer testdisk au cas où il saurait retrouver les vieilles partitions.

Dernière modification par geole (Le 10/11/2020, à 00:06)

MonsterNunch · Le 26/11/2020, à 09:09

Bonjour, revoilà le casse-pied !

Bon, j'ai enfin commencé la récupération de mes données avec Photorec sur le disque crypté sur lequel il y avait la Ubuntu 14.04, mais je rencontre un souci : la récupération boucle !

PhotoRec 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sda - 1000 GB / 931 GiB (RO) - WDC WD10EZEX-00RKKA0
     Partition                  Start        End    Size in sectors
     No partition             0   0  1 121601  80 63 1953525168 [Whole disk]

Pass 1 - Reading sector   30[xxxxxx]/1953525168, 2143 files found 
Elapsed time 5h[xx]m[xx]s - Estimated time to completion 347h[xx]m[xx]s

txt: 1332 recovered
elf: 366 recovered
exe: 306 recovered
png: 66 recovered
tx?: 19 recovered
asf: 12 recovered
jpg: 9 recovered
gz: 7 recovered
a: 5 recovered
zip: 5 recovered
others: 16 recovered

Stop

J'ai mis des [xx] là où les chiffres tournent.

Je suis sur la Live USB 18.04 persistante.
J'ai mon sda de 1To qui est l'Ubuntu 14.04 cryptée et mon sdb qui est un disque de 1To formaté nommé Recup.
Les deux sont bien montés.
J'ai opté pour un balayage complet du disque à récupérer.
Le choix des systèmes de fichiers des disques a été ext2 (compatible avec ext3 et ext4 indiquaient-ils).
Il ne m'a pas demandé ma passphrase.

Au bout d'à peu près 30 minutes, les fichiers récupérés n'augmentent plus et cela commence a boucler : les secteurs lus vont de 30000000 à 38500000 environ.

Est-ce parce que le système de partitionnement a été vérolé par mon "début" d'installation sur l'Ubuntu 14.04 ?
Est-il possible de le réparer ?
Auriez-vous vu des erreurs dans ce que j'ai fait ou des conseils à me donner s'il vous plait ?

Dernière modification par MonsterNunch (Le 26/11/2020, à 09:10)

geole · Le 26/11/2020, à 10:37

Bonjour
Trois remarques.
- Le disque fait 1 To. Tu as choisis de lire tout le disque. A mon avis, il faut environ 15 à 20 heures pour le faire
- Tu dis " : Les secteurs lus vont de 30000000 à 38500000 environ".
Le fait de ne pas récupérer de fichiers peut être normal, le process peut être en train de lire une zone sans fichiers à récupérer.
Pour dire qu'il y a un problème, il faudrait regarder cette zone
Pass 1 - Reading sector 30[xxxxxx]/1953525168, 2143 files found
Si XXXXXX n'évolue plus du tout, il y a effectivement un problème, Mais s'il continue de s'incrémenter Tout va bien, Il finira bien par atteindre La valeur 1953525168
- Normalement l'état smartctl du disque ( https://forum.ubuntu-fr.org/viewtopic.p … #p22366562 ) dit qu'il est en bon état.

MonsterNunch · Le 26/11/2020, à 12:40

J'en suis pour le moment à 9h de "Pass 1 - reading sector", les secteurs vont toujours de 30000000 à 38500000 environ (ça s'incrémente progressivement jusqu'à 38500000 par paliers de 400000, puis retombe à 30000000 arrivé à 38500000 environ) et il m'annonce maintenant un temps entre 459h et 580h (pareil, ça s'incrémente jusqu'au max annoncé puis retombe à la limite basse proportionnellement à la lecture des secteurs).

Le nombre de fichiers récupérés reste identique : 2143.

Il semble indiquer qu'il lit le même endroit en boucle depuis 9h, mais pour l'instant, je laisse tourner.

On verra bien.

Dernière modification par MonsterNunch (Le 26/11/2020, à 12:53)

geole · Le 26/11/2020, à 17:06

Vu ce que tu décris, cela ressemble à quelque chose d'anormal.
Quelle version de photorec? A faire dans une autre session

photorec --help
PhotoRec 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Usage: photorec [/log] [/debug] [/d recup_dir] [file.dd|file.e01|device]
       photorec /version

/log          : create a photorec.log file
/debug        : add debug information

PhotoRec searches for various file formats (JPEG, Office...). It stores files
in the recup_dir directory.

MonsterNunch · Le 26/11/2020, à 19:53

En effet, ça a l'air de faire le travail avec cette version. J'avais pris celle des dépôts et j'étais en 7.0 (de 2015).

J'ai eu deux petites frayeurs parce qu'à 14200000 environ, il s'est mis à boucler pendant 2/3 minutes et peu de temps après, vers 16000000 il a figé, mais c'est reparti comme en 40 !

Là il en est à :

Pass 1 - Reading sector  191465812/1953525168, 6179 files found
Elapsed time 0h21m03s - Estimated time to completion 3h13m43

EDIT : ça fige quelquefois et reprend à un secteur antérieur, mais dans l'ensemble, ça évolue bien.
EDIT 2 : dommage que ce ne soit pas plutôt cette version 7.1 qui soit privilégiée dans les dépôts.

On va voir au final ce que cela dit.

Merci encore geole !

Dernière modification par MonsterNunch (Le 26/11/2020, à 19:59)

geole · Le 26/11/2020, à 20:11

Je ne sais pas ce que tu appelles la version des dépôts.
Je suis convaincu que le chapitre 2 de la documentation est bon https://doc.ubuntu-fr.org/testdisk

Coeur Noir · Le 26/11/2020, à 20:26

Je ne sais pas ce que tu appelles la version des dépôts → https://packages.ubuntu.com/search?keyw … ection=all
Le paquet testdisk tel que fourni par les dépôts officiels d'Ubuntu, selon les versions de la distribution.

Une version bêta 7.2 est disponible sur le site https://www.cgsecurity.org/wiki/T%C3%A9 … r_TestDisk mais comme c'est une bêta elle ne peut être incluse aux dépôts officiels.

MonsterNunch · Le 26/11/2020, à 23:24

Coeur Noir a écrit :

Je ne sais pas ce que tu appelles la version des dépôts → https://packages.ubuntu.com/search?keyw … ection=all
Le paquet testdisk tel que fourni par les dépôts officiels d'Ubuntu, selon les versions de la distribution.

En effet, c'est ce que je voulais dire.

Bon, c'est terminé, mais ce n'est pas super probant.

J'ai récupéré 130Go, mais peu est exploitable.
J'ai beaucoup de fichiers .elf, assez petits et des fichiers .swf très gros qui ne me disent rien et qui ne peuvent pas être lus.
Aucun .pdf, ni .doc. et tous les .jpg sont des vieilles photos que je pense avoir supprimé.
A priori les mp3 que j'ai récupérés sont aussi des choses que j'avais effacé.
A première vue, j'ai l'impression qu'il m'a retrouvé surtout les fichiers supprimés.

Je vais tester type de fichier par type de fichier. Je vais voir ce que ça donne.
C'est surtout les photos, les mp3 d'émissions, les .pdf et les .doc important que je souhaitais retrouver, mais aucune trace de cela.

geole a écrit :

Je suis convaincu que le chapitre 2 de la documentation est bon https://doc.ubuntu-fr.org/testdisk

J'essaierai la beta 7.2 aussi.

Ce qui me parait étrange, c'est qu'à aucun moment il ne m'a demandé ma passphrase et que les répertoires sont accessibles directement dans mon explorateur de fichiers.
C'est peut-être pour ça qu'il n'a pas retrouvé mes précieux, non ?

geole · Le 27/11/2020, à 11:20

Bonjour

1) Puisque tu avais installé la version livrée au même moment que la création du ubuntu, il est normal que depuis 30 mois la version ait évolué avec les mises à jours successives
Peut-être qu'en faisant les commandes

sudo apt update && sudo apt upgrade

cette mise à jour aurait été détectée.

2) Je pense que la version 7.2 beta ne donnera rien de plus.

3) Tu avais choisis de parcourir tout le disque qui n'est pas chiffré. Peut-être que si tu avais choisis la partition en question (actuellement non détectée), il aurait posé la question. Mais j'en doute.
Je vais reporter le message d'avertissemnt du début du chapitre 4 de testdisk dans photorec.
En fait je m'attendais un peu à cette non-récupération. Pourquoi donc chiffrer si photorec trouve automatiquement le contenu. En fait les signatures des fichiers sont aussi chiffrées.
Il faut donc une option pour transformer
Signature officielle .doc ==> Passphrase de chiffrement => signature chiffrée (WXYZ)

4) Sans savoir si cela va réussir, je te propose l'essai suivant

1) Faire la commande

sudo fdsik -l

Cela va donner la liste des partitions actuelles
2) Lancer testdisk, Lui demander d'analyser le disque SDA
Il devrait trouver des partitions.
Dont les partitions actuelles
Probablement d'autres, au besoin après un deep-search.
3) Espérons qu'il retrouvent celles du début.

disque /dev/sda : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Périphérique Amorçage  Début        Fin   Secteurs Taille Id Type
/dev/sda1    *          2048     499711     497664   243M 83 Linux
/dev/sda2             501758 1953523711 1953021954 931,3G  5 Étendue
/dev/sda5             501760 1953523711 1953021952 931,3G 83 Linux

Si tel est le cas.
4a) On force la création des partitions retrouvées., Ce qui veut dire que les nouveautés stockées dans SDA sont éliminées. Je pense qu'il n'y a rien à conserver

5a) On s'attaquera alors au "décryptage" des données. Je n'ai pas mis "déchiffrage" car coeur noir a dit que l'algorithme avait changé. Je pense qu'on pourra retrouver l'ancien en y mettant du temps.

Si tel n'est pas le cas:
Appel à un expert en lui expliquant la situation.

Dernière modification par geole (Le 27/11/2020, à 11:27)

Coeur Noir · Le 27/11/2020, à 19:29

Oh moi tout ce que j'ai dit c'est :
Hypothèse farfelue : en démarrant en live-session 14.10, accéderais-tu de nouveau à ces parties chiffrées ? Y'a p'têt bien eu des changements dans la manière de gérer ce chiffrement entre 14.10 et 18.04 ???

Nulliel semble confirmer ce changement :
Il me semble qu'avant c'était cryptsetup qui était utilisé, il y a eu il me semble un changement dans le chiffrement

Et plus tard j'ai ajouté :
on touche aux limites de mes compétences, là : je crains en espérant me tromper que c'est tout ce qu'il reste de ton install' précédente cf « lors d'un moment d’inattention, j'ai initié une installation sur celui-ci (je l'ai stoppé au quasi début, il n'y avait pas de barre de progression ... j'espère que ce n'est pas trop grave). »

MonsterNunch · Le 28/11/2020, à 06:20

Salut,

geole a écrit :

Je vais reporter le message d'avertissement du début du chapitre 4 de testdisk dans photorec.
En fait je m'attendais un peu à cette non-récupération. Pourquoi donc chiffrer si photorec trouve automatiquement le contenu. En fait les signatures des fichiers sont aussi chiffrées.
Il faut donc une option pour transformer
Signature officielle .doc ==> Passphrase de chiffrement => signature chiffrée (WXYZ)

En effet, j'avais vu cet avertissement, mais je pensais qu'avec tes super-pouvoirs, on aurait pu outrepasser cette limite
Mais c'est vrai que c'est logique.

Testons :

4-1) Résultat du sudo fdisk -l (sans les loop) :

Disque /dev/sda : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x9130b00d

Périphérique Amorçage   Début        Fin   Secteurs Taille Id Type
/dev/sda1    *           2048    1499135    1497088   731M 83 Linux
/dev/sda2             1501182 1953523711 1952022530 930,8G  5 Étendue
/dev/sda5             1501184 1953523711 1952022528 930,8G 83 Linux

La partition 2 ne commence pas sur une frontière de cylindre physique.


Disque /dev/sdb : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets


Disque /dev/sdc : 14,3 GiB, 15376000000 octets, 30031250 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x00018f1b

Périphérique Amorçage Début      Fin Secteurs Taille Id Type
/dev/sdc1    *         2048 30029823 30027776  14,3G  c W95 FAT32 (LBA)

4-2) Lors de l'analyse il trouve cela :

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

 1 * Linux                    0  32 33    93  80 51    1497088
 2 E extended                93 113 19 121601  57 56 1952022530
No ext2, JFS, Reiser, cramfs or XFS marker
 5 L Linux                   93 113 21 121601  57 56 1952022528
 5 L Linux                   93 113 21 121601  57 56 1952022528

et je suis donc à l'étape 5 sans trop savoir que faire, car il semblerait qu'une partition ait disparu :

TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
>* Linux                    0  32 33    31  26 59     497664
 P Linux                   31  59 29    31 124 29       4096

Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
ext4 blocksize=1024 Large_file Sparse_SB, 254 MB / 243 MiB

Coeur Noir a écrit :

Hypothèse farfelue : en démarrant en live-session 14.10, accéderais-tu de nouveau à ces parties chiffrées ? Y'a p'têt bien eu des changements dans la manière de gérer ce chiffrement entre 14.10 et 18.04 ???

Oui, je vais aussi télécharger une 14.04 (ma version pétée) pour tester, ça pourra être utile.

Dernière modification par MonsterNunch (Le 28/11/2020, à 06:23)

moko138 · Le 28/11/2020, à 07:27

En #5, Coeur Noir a écrit :

Hypothèse farfelue : en démarrant en live-session 14.10, accéderais-tu de nouveau à ces parties chiffrées ? Y'a p'têt bien eu des changements dans la manière de gérer ce chiffrement entre 14.10 et 18.04 ???

Cf. ./viewtopic.php?pid=21705187#p21705187
Donc, pour avoir une esquisse de chance, il faudra
- passer les dépôts en "old-release" ;
- puis faire les mises à jour sauf celles du noyau :

sudo apt-get update ; sudo apt-get upgrade

Mais surtout pas sudo apt-get dist-upgrade, sous peine de casser la session live.

geole · Le 28/11/2020, à 11:03

MonsterNunch a écrit :

4-1) Résultat du sudo fdisk -l (sans les loop) :
Périphérique Amorçage Début Fin Secteurs Taille Id Type
.....
/dev/sda5 1953523711 1952022528 930,8G 83 Linux
4-2) Lors de l'analyse il trouve cela :
5 L Linux 93 113 21 121601 57 56 1952022528
5 L Linux 93 113 21 121601 57 56 1952022528
et je suis donc à l'étape 5
Enter: to continue

Sans avoir décodifié le CHS, mais en me fiant à la taille, on voit qu'il a retrouvé la partition actuelle SDA5
Mais il n'a toujours pas retrouvé l'ancienne qui était d'une taille différente
501760 1953523711 1953021952
et, qui plus est, a une autre adresse début. Tu as donc une chance de réussir à la retrouver en continuant la recherche qu'il te propose d'ailleurs de continuer en appuyant sur la touche entrée
Puisque tu as interrompu assez rapidement l'utilisation de la nouvelle partition.
Merci de faire l'action demandée (appui sur la touche entrée) afin de continuer la recherche.
Il est probable que pendant cette recherche, il te propose plusieurs fois enter to continue

Tant que tu ne verras pas une valeur 1953021952, tu pourras continuer.
Si tu vois cette valeur, je ne sais pas trop quoi te dire pour l'instant...
Elle n'est pas obligatoirement la bonne, Je vais faire un effort pour codifier les adresses DEBUT et FIN codées actuellement en LBA pour les coder en CHS
Si tu as la bonne taille et les bons CHS, tu sais que c'est la bonne partition.
Il faudra passer à l'opération de récréation.
Après tu pourras partir sur des bases saines. Je crois qu'on t'a conseillé de fabriquer une live USB en 14.04 . Si la partition n'a pas été retrouvée, ce n'est pas très utile, car je ne suis pas un grand magicien et je ne connais pas la formule des signatures chiffrées.

La structure chs étant indiquée par tesdisk CHS 121601 255 63

http://cars.car.coocan.jp/misc/chs2lba.html A dit que
le LBA de début 501760 correspond à 31 59 29
le LDA de fin 953523711 correspond à 59354 27 1

Dernière modification par geole (Le 28/11/2020, à 11:42)

MonsterNunch · Le 28/11/2020, à 17:47

Alors, en ayant continué, il semble en effet me retrouver la partion de boot en LUKS :

TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
 D Linux                    0  32 31    31  26 57     497664
 D Linux                    0  32 33    31  26 59     497664
>* Linux                   31  59 29    31 124 29       4096

Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
Keys A: add partition, L: load backup, T: change type, 
     Enter: to continue
LUKS 1 (Data size unknown), 2097 KB / 2048 KiB

La deuxieme ligne étant :

ext4 blocksize=1024 Large_file Sparse_SB, 254 MB / 243 MiB

et la première :

ext4 blocksize=1024 Large_file Sparse_SB Backup_SB, 254 MB / 243 MiB

Quand je fais "Continue" sur la 3e, la LUKS1, il me propose de "Quit" "Return" ou "Write" [Write partition structure to disk] (idem pour les deux autres, mais je pense que c'est celle-ci qu'on doit récupérer, non ?)

geole · Le 28/11/2020, à 18:22

Le problème, c'est la taille et le type ne conviennent. Mais il est vrai que j'ai en référence SDA5 qui a été formatée pour devenir chiffrée, A ce niveau je n'ai pas d'expérience, Il donc possible que logiciel fasse le nécessaire pour masquer la vraie taille et ne la montre qu'après le montage

Alors tu dis que c'est la bonne surtout qu'il la voit en Luks. Donc tu y vas avec Write
Il faudra confirmer puis rebooter...

Dernière modification par geole (Le 28/11/2020, à 18:24)

MonsterNunch · Le 29/11/2020, à 00:24

Là, après redémarrage, dans l'explorateur il me propose de la monter mais elle ne fait que 2,1Mo, et le fdisk me renvoie ceci (toujours loops exclues) :

Disque /dev/sda : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x9130b00d

Périphérique Amorçage  Début    Fin Secteurs Taille Id Type
/dev/sda1    *        501760 505855     4096     2M 83 Linux


Disque /dev/sdb : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets


Disque /dev/sdc : 14,3 GiB, 15376000000 octets, 30031250 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x00018f1b

Périphérique Amorçage Début      Fin Secteurs Taille Id Type
/dev/sdc1    *         2048 30029823 30027776  14,3G  c W95 FAT32 (LBA)

Quand je la monte via l'explorateur de fichier, il m'indique :
- Error unlocking /dev/sda1:Failed to activate device: Invalid argument quand c'est le mot de passe d'origine.
- Error unlocking /dev/sda1:Failed to activate device: Operation not permitted quand c'est le mot de passe d'origine.

Il a donc l'air de se souvenir de la passphrase

En revanche, il n'a plus l'air de retrouver les deux partitions sda2 et sda5 :

ubuntu@ubuntu:~$ lsblk -fe7 -o +SIZE
NAME   FSTYPE  LABEL      UUID                                 MOUNTPOINT   SIZE
sda                                                                       931,5G
└─sda1 crypto_            374c9edb-560e-42a6-87ed-3a313689f239                2M
sdb    ext4    Recup      4cdafcbb-9aa3-4497-825d-95864a3d8d9c            931,5G
sdc                                                                        14,3G
└─sdc1 vfat    UBUNTU1804 2686-DBEC                            /isodevice  14,3G

Et avec GParted, j'ai 931,27 Go de non alloué.

Je peux tenter un boot sur ce disque, bien que je sois très sceptique vu la taille, mais je me dit qu'au lieu de "write" on aurait pû faire "add" plutôt, non ?
Une autre passe de testdisk serait salvatrice, à votre avis ?

geole · Le 29/11/2020, à 00:40

Tu peux tenter un autre passage. Cela ne prend que du temps.
Mais je n'avais pas proposé add vu que je pense que les autres endroits contiennent des données sans rapport avec les données chiffrées.
Il est aussi possible de modifier la taille de la partition ou d'en fabriquer une de A à Z, Je ne sais plus très bien la façon de faire. Demain, je relirais tout afin de voir si on ne peut pas récupérer des précisions.

Dernière modification par geole (Le 29/11/2020, à 00:47)

MonsterNunch · Le 13/12/2020, à 20:47

Bonsoir,

J'ai enfin téléchargé la 14.04 sur la clef USB.
Après avoir fait un add d'une partition qu'il avait trouvé via testdisk sur ma 18.04, j'ai cru que j'étais bon, mais non : elle ne fait que 255Mo et semble être vide ou inaccessible.

ubuntu@ubuntu:~$ sudo fdisk -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x9130b00d

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2046      499709      248832   83  Linux
Partition 1 does not start on physical sector boundary.
/dev/sda2   *      501760      505855        2048   83  Linux

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table

Disk /dev/sdc: 15.4 GB, 15376000000 bytes
255 heads, 63 sectors/track, 1869 cylinders, total 30031250 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00018f1b

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *        2048    30029823    15013888    c  W95 FAT32 (LBA)

Lorsque j'essaye de monter ma partition sda1 via le logiciel de gestion des disques, il me retourne ceci :

ubuntu 14.04 LiveUSB a écrit :

Error unlocking /dev/sda2: Command-line `cryptsetup luksOpen "/dev/sda2" "luks-374c9edb-560e-42a6-87ed-3a313689f239" ' exited with non-zero exit status 1: Requested offset is beyond real size of device /dev/sda2.

Moi, ce qui m'interresse surtout, c'est le reste sur sda5 mais elle n'est visible nulle part et le système m'indique que sur ce disque, j'ai 1000Go non alloués.

geole · Le 14/12/2020, à 09:49

Bonjour
Avec cette live USB en version 14.04, essaie d'y installer testdisk..
J pense a la version beta https://doc.ubuntu-fr.org/testdisk#util … rsion_beta
car il est probable que la version normale ne soit disponible en 14.04
et ré-analyse le disque de 1 To a la recherche des partitions et poste ce qu'il va détecter.
au niveau rapide puis au niveau deep search
de mémoire, on cherche SDA5
/dev/sda5 501760 1953523711 1953021952 931,3G 83 Linux

Dernière modification par geole (Le 14/12/2020, à 09:50)

MonsterNunch · Le 22/12/2020, à 22:27

Salut,

Désolé pour le délai, mais j'avais du mal à me résoudre à passer sur cette LiveUSB 14.04 non-persistante car l'affichage ne se règle pas du tout de base (pas les bords) et je ne peux installer les drivers videos qui solutionneraient cela car il faut redémarrer pour que cela soit pris en compte.

Voici le résultat de la passe Deepsearch de la beta de testdisk, et j'ai le même résultat que sur la 18.04 :

TestDisk 7.2-WIP, Data Recovery Utility, Novembre 2020
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
 D Linux                    0  32 31    31  26 57     497664
 D Linux                    0  32 33    31  26 59     497664
>* Linux                   31  59 29    31 124 29       4096

Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
Keys A: add partition, L: load backup, T: change type, 
     Enter: to continue
LUKS 1 (Data size unknown), 2097 KB / 2048 KiB

Quand je fais "Enter", il me propose d'écrire la partition sélectionnée.

Je vais poster plus tard ce qu'il me trouve sur la passe normale car je n'ai pas gardé cet affichage.

MonsterNunch · Le 23/12/2020, à 02:44

Le voici :

TestDisk 7.2-WIP, Data Recovery Utility, Novembre 2020
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
>* Linux                    0  32 33    31  26 59     497664
 P Linux                   31  59 29    31 124 29       4096

Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
ext4 blocksize=1024 Large_file Sparse_SB, 254 MB / 243 MiB

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 09/11/2020, à 12:47

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#27 Le 09/11/2020, à 18:45

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#28 Le 09/11/2020, à 22:02

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#29 Le 10/11/2020, à 00:03

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#30 Le 26/11/2020, à 09:09

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#31 Le 26/11/2020, à 10:37

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#32 Le 26/11/2020, à 12:40

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#33 Le 26/11/2020, à 17:06

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#34 Le 26/11/2020, à 19:53

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#35 Le 26/11/2020, à 20:11

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#36 Le 26/11/2020, à 20:26

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#37 Le 26/11/2020, à 23:24

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#38 Le 27/11/2020, à 11:20

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#39 Le 27/11/2020, à 19:29

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#40 Le 28/11/2020, à 06:20

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#41 Le 28/11/2020, à 07:27

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#42 Le 28/11/2020, à 11:03

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#43 Le 28/11/2020, à 17:47

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#44 Le 28/11/2020, à 18:22

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#45 Le 29/11/2020, à 00:24

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#46 Le 29/11/2020, à 00:40

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#47 Le 13/12/2020, à 20:47

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#48 Le 14/12/2020, à 09:49

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#49 Le 22/12/2020, à 22:27

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

#50 Le 23/12/2020, à 02:44

Re : [Résolu] Nouvel Ubuntu 18.04 top, mais data sur DD avec 14.10 perdues

Pied de page des forums