[Résolu] Disque dur 4to marque 1.64to sur Gparted

N²Heisenberg · Le 18/09/2019, à 08:18

Bonjour la communauté...

J'ai posté cette question sur le forum xubuntu.fr

Malheureusement j'ai pas trouvé comment régler mon problème, alors je me permets de la poser ici aussi.

Disque dur 4to marque 1.64to sur Gparted

J'ai un problème avec un disque dur qui dormait dans mon placard.
Un disque dur de 4to, je voulais voir ce qu'il y avait dessus mais je pense qu'il y a un problème.

Il n'est pas détecté par Xubuntu et si je lance Gparted il me l'affiche à 1.64to.

Il marque " ERREUR de libparted " Argument invalide lors d'un positionnement pour lecture sur /dev/sdb.
Il marque " ERREUR de libparted " The backup GPT table is corrupt, but the primary appears OK, so that will be used.

J'ai besoin d'aide, est-que je peux récupérer mes données ? Et mon disque est-il mort ?

Ma partition c'est une GPT. (Un ancien disque qui tournait sur windows.)

J'ai fait une récupération de donnée mais ça foire...

Le problème c'est que je n'ai même pas la totalité du disque dur.

Merci pour votre aide.

Dernière modification par N²Heisenberg (Le 24/10/2019, à 21:15)

N²Heisenberg · Le 18/09/2019, à 09:20

Merci grandtoubab, voilà le résultat :

fsck de util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Numéro magique invalide dans le super-bloc
fsck.ext2 : Superbloc invalide, tentons d'utiliser les blocs de sauvetage...
fsck.ext2: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sdb

Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
    e2fsck -b 8193 <périphérique>
 ou
    e2fsck -b 32768 <périphérique>

Trouvé une table de partitions PMBR dans /dev/sdb

geole · Le 18/09/2019, à 10:02

Bonjour

La commande fsck est destinée à controler la qualité des partitions et non du disque.

Peux-tu indiquer si ton disque est branché en USB ou si c'est un disque interne

Pour le smarctl, je préfère une commanbde plus bavarde. Donne le retour de

sudo smartctl    -a   /dev/sdb

On devrait y voir la référence du disque et sa capacité prévue.

Donne aussi ce retour

ls   -ls  /dev/disk/by-path

Peux-tu indiquer si tu as des données importantes à récuperer dans ce disque ?

Hypothèse probable: Vu le mauvais état de la table de partion GPT, il aurait pu être utiiliséavec un vieux windows ne sachant pas gérer les disques de taille supérieure à 2,2 To

Dernière modification par geole (Le 18/09/2019, à 10:11)

N²Heisenberg · Le 18/09/2019, à 12:20

Geole, c'est un disque qui était interne et qui tournait sur un Windows 7. Je l'ai mis en externe, branchement en USB sur une station d'accueil.

Réponse à la ligne de commande

sudo smartctl    -a   /dev/sdb

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-5.0.0-27-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     ST4000DM005-2DP166
Serial Number:    ZDH0FH9Y
LU WWN Device Id: 5 000c50 093714b21
Firmware Version: 0001
User Capacity:    4000787030016 bytes [4,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5980 rpm
Form Factor:      3.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 1.5 Gb/s)
Local Time is:    Wed Sep 18 12:06:54 2019 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		(  591) seconds.
Offline data collection
capabilities: 			 (0x73) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					No Offline surface scan supported.
					Self-test supported.
					Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   1) minutes.
Extended self-test routine
recommended polling time: 	 ( 654) minutes.
Conveyance self-test routine
recommended polling time: 	 (   2) minutes.
SCT capabilities: 	       (0x10a5)	SCT Status supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   077   064   006    Pre-fail  Always       -       52740128
  3 Spin_Up_Time            0x0003   094   094   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   098   098   020    Old_age   Always       -       2292
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   076   060   045    Pre-fail  Always       -       37046441
  9 Power_On_Hours          0x0032   096   096   000    Old_age   Always       -       4175 (89 56 0)
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       790
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   072   057   040    Old_age   Always       -       28 (Min/Max 25/28)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       852
193 Load_Cycle_Count        0x0032   098   098   000    Old_age   Always       -       5662
194 Temperature_Celsius     0x0022   028   043   000    Old_age   Always       -       28 (0 9 0 0 0)
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       1370 (137 193 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       18015484389
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       12875277238

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      4173         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Réponse à la ligne de commande

ls   -ls  /dev/disk/by-path

total 0
0 lrwxrwxrwx 1 root root  9 sept. 18 11:59 pci-0000:00:1d.7-usb-0:4:1.0-scsi-0:0:0:0 -> ../../sdb
0 lrwxrwxrwx 1 root root  9 sept. 18 09:22 pci-0000:00:1f.2-ata-1 -> ../../sda
0 lrwxrwxrwx 1 root root 10 sept. 18 09:22 pci-0000:00:1f.2-ata-1-part1 -> ../../sda1
0 lrwxrwxrwx 1 root root  9 sept. 18 09:22 pci-0000:00:1f.2-ata-2 -> ../../sr0

Je ne sais plus ce qu'il y a dessus je sais juste qu'il était plein.

Je l'ai testé sur un windows 10, il met un temps fou à le charger et une fois quasiment charger il fait tout buger !

geole · Le 18/09/2019, à 12:48

Du point de vue hardware, il est bien détecté comme ayant toujours une capacité de 4 To.
User Capacity: 4000787030016 bytes [4,00 TB]
Mais aucune partition n'a été trouvée.
Je te suggère de réinitialiser les tables de partitions avec cette commande

 sudo sgdisk -Z /dev/sdb

Après cette action, il est nécessaire de débrancher le disque et de le rebrancher pour prise en compte,
Tu devras alors pouvoir fabriquer une table de partition GPT avec gparted et puis créer les partitions que tu souhaites.

Cependant, si tu tiens à savoir si c'est récupérable, il faudrait que tu utilises TESTDISK. ( https://doc.ubuntu-fr.org/testdisk )

Dernière modification par geole (Le 18/09/2019, à 12:49)

moko138 · Le 18/09/2019, à 15:19

N²Heisenberg a écrit :

c'est un disque qui était interne et qui tournait sur un Windows 7

  9 Power_On_Hours          -       4175 (89 56 0)
193 Load_Cycle_Count        -       5662

5662 mises sous tension pour 4175 heures, ça fait des sessions courtes (environ 45 minutes).
Es-tu certain que ce n'était pas plutôt un DDE ?

EDIT :
5.662, c'est le nombre de parcages !

  9 Power_On_Hours          -       4175 (89 56 0)
 12 Power_Cycle_Count       -       790

Ça nous met la session moyenne à 5h15', ce qui est cohérent avec une utilisation comme disque interne.

Dernière modification par moko138 (Le 19/09/2019, à 05:14)

N²Heisenberg · Le 18/09/2019, à 17:58

moko138 a écrit :

N²Heisenberg a écrit :
c'est un disque qui était interne et qui tournait sur un Windows 7
  9 Power_On_Hours          -       4175 (89 56 0)
193 Load_Cycle_Count        -       5662
5662 mises sous tension pour 4175 heures, ça fait des sessions courtes (environ 45 minutes).
Es-tu certain que ce n'était pas plutôt un DDE ?

Oui car il est bien rayé par les fixation de mon ancienne tour.
Mais c'est vrai que maintenant j'ai un doute.

N²Heisenberg · Le 18/09/2019, à 18:04

Après la ligne de commande :

 sudo sgdisk -Z /dev/sdb

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! One or more CRCs don't match. You should repair the disk!

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.

N²Heisenberg · Le 18/09/2019, à 18:07

J'ai toujours la partition à 1.64to (?)

geole · Le 18/09/2019, à 18:21

Avais-tu pensé à débrancher le disque et à le rebrancher?
Normalement, tu ne devrais rien voir puisque GPT data structures destroyed!

N²Heisenberg · Le 19/09/2019, à 02:07

geole a écrit :

Avais-tu pensé à débrancher le disque et à le rebrancher?
Normalement, tu ne devrais rien voir puisque GPT data structures destroyed!

Oui et il apparaît toujours comme ça dans Gparted.

N²Heisenberg · Le 19/09/2019, à 02:22

Je viens de le mettre sur windows 10 il ne le voit pas.
Je suis allé dans le gestionnaire de stockage, il le voit et me demande de le passer en partition GPT ou en disque principale.

Je pense que je vais abandonner le fait de vouloir voir ce qu'il y a dessus et reprendre le disque dans sa totalité vu qu'il n'a pas d'erreur majeur, qu'il est en bonne santé. (je pense)

moko138 · Le 19/09/2019, à 04:48

geole;
Taille maxi en msdos = 2 Tio (si je ne m'abuse).
Taille reconnue : 1,64 Tio

Somme des deux : 3,64 Tio = environ 4 To.
J'ai donc l'impression qu'il y a eu une fausse manip' sur ce disque, du genre
y copier une image de partition de 4To depuis un S.E. qui ne reconnaissait pas la GPT.

Puisque N²Heisenberg demande

est-que je peux récupérer mes données ?

l'utilisation de testdisk me semble hautement recommandable.
Et si testdisk échouait, celle de photorec.
Ne crois-tu pas ?

P.S. : Je viens de voir une bêtise dans mon message d'hier, je vais corriger.

N²Heisenberg · Le 19/09/2019, à 09:06

Je viens de lancer testdisk je reviens vers vous après, car c'est long, très long...

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

Disk /dev/sdb - 1801 GB / 1678 GiB - CHS 219051 255 63
Analyse cylinder 4023/219050: 01%

  MS Data                   264192 7814035455 7813771264

Petite interrogation en attendant, je ne comprends pas pourquoi il est scindé en deux alors que je ne fais jamais ça, mes disques restent toujours brute je ne les partitionne jamais.

Nasman · Le 19/09/2019, à 10:34

Que donne

sudo fdisk -l

sudo dd if=/dev/sdb bs=512 count=3 | hexdump -C

La première commande devrait donner le nombre de secteurs du disque
La deuxième montrera le mbr (ou mbr protector) avec les tables des partitions (codé sur 4 octets pour mbr protector et 8 octets pour table gpt).
On vérifiera avec le backup

N²Heisenberg · Le 19/09/2019, à 11:06

Nasman, voilà ce que donne :

sudo fdisk -l

Disque /dev/sda : 223,6 GiB, 240057409536 octets, 468862128 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 : 0xb2bf0665

Périphérique Amorçage Début       Fin  Secteurs Taille Id Type
/dev/sda1    *         2048 468860927 468858880 223,6G 83 Linux




Disque /dev/sdb : 1,7 TiB, 1801763774464 octets, 3519069872 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

Et voilà ce que donne :

sudo dd if=/dev/sdb bs=512 count=3 | hexdump -C

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
3+0 enregistrements lus
3+0 enregistrements écrits
1536 bytes (1,5 kB, 1,5 KiB) copied, 0,00636282 s, 241 kB/s
00000600

Nasman · Le 19/09/2019, à 11:32

Peut-on avoir le retour complet des commandes genre

user@machine:$~ma_commande
bla bla
user@machine:$~

A priori tu n'as plus de mbr (ni de mbr protector), plus de table de partition.
Il est difficile de voir le backup si tu es sur que ton disque fait 4 To car le fdisk n'indique que 3519069872 qui es en deçà de la limite des 2 Tio.

En partant de l'hypothèse que ton disque fait 4000787030016 octets, cela correspond à 7814037168 secteurs. Les LBA vont donc de 0 à 7814037167.
Dans le dernier secteur est sensé se trouver le backup de l'en-tête gpt (dont la partie à la LBA=1 est vide).
Que donne

sudo dd if=/dev/sdb bs=512 count=1 skip=7814037167 | hexdump -C

Que donne aussi

sudo dd if=/dev/sdb bs=512 count=1 skip=7814037135 | hexdump -C

Le backup de la table des partitions gpt se trouve dans les secteurs précédents.

En résumé :
LBA=0 mbr protector
LBA=1 En-tête gpt
LBA=2 - LBA=33 : 32 secteurs de 4 entrées - 128 partitions possibles

LBA=fin_disque-32 - fin_disque-1 : backup de la table des partitions (32 secteurs)
LBA=fin_disque Backup en-tête gpt

moko138 · Le 19/09/2019, à 11:48

Vous avez vu le #9 ?

Nasman · Le 19/09/2019, à 12:13

J'ai l'impression qu'il y a eu des mesures correctives d'appliquées sans avoir parfaitement cerné le problème - Ces mesures ont sans doute amoindri les chances de récupérer des données.
En attente de voir ce qu'il y a en fin de disque.
S'il n'y a plus rien alors ce sera à testdisk de jouer.

N²Heisenberg · Le 19/09/2019, à 13:17

Résultat du fdisk :

Disk /dev/sdb - 1801 GB / 1678 GiB - CHS 219051 255 63

The harddisk (1801 GB / 1678 GiB) seems too small! (< 4000 GB / 3726 GiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partition can't be recovered:
     Partition               Start        End    Size in sectors
>  MS Data                   264192 7814035455 7813771264

NTFS, blocksize=4096, 4000 GB / 3725 GiB

N²Heisenberg · Le 19/09/2019, à 13:39

sudo dd if=/dev/sdb bs=512 count=1 skip=7814037167 | hexdump -C

heisenberg@Meth-Desktop:~$ sudo dd if=/dev/sdb bs=512 count=1 skip=7814037167 | hexdump -C
dd: /dev/sdb : impossible de passer outre: Argument invalide
0+0 enregistrements lus
0+0 enregistrements écrits
0 bytes copied, 0,000410889 s, 0,0 kB/s
heisenberg@Meth-Desktop:~$

Que donne aussi

sudo dd if=/dev/sdb bs=512 count=1 skip=7814037135 | hexdump -C

heisenberg@Meth-Desktop:~$ sudo dd if=/dev/sdb bs=512 count=1 skip=7814037135 | hexdump -C
dd: /dev/sdb : impossible de passer outre: Argument invalide
0+0 enregistrements lus
0+0 enregistrements écrits
0 bytes copied, 0,000240262 s, 0,0 kB/s
heisenberg@Meth-Desktop:~$

N²Heisenberg · Le 19/09/2019, à 13:43

Nasman a écrit :

J'ai l'impression qu'il y a eu des mesures correctives d'appliquées sans avoir parfaitement cerné le problème - Ces mesures ont sans doute amoindri les chances de récupérer des données.
En attente de voir ce qu'il y a en fin de disque.
S'il n'y a plus rien alors ce sera à testdisk de jouer.

:'( :'( :'(

moko138 · Le 19/09/2019, à 14:15

sdb
     Partition               Start        End    
>  MS Data                   264192 7814035455

Mais

sudo dd if=/dev/sdb bs=512 count=1 skip=7814037135 | hexdump -C

On est au-delà du disque.

moko138 · Le 19/09/2019, à 14:25

Je ne maîtrise pas ces choses-là, contrairement à Nasman, mais essaie :

sudo dd if=/dev/sdb bs=512 count=1 skip=7814035454 | hexdump -C

et

sudo dd if=/dev/sdb bs=512 count=1 skip=7814035453 | hexdump -C

Nasman · Le 19/09/2019, à 14:34

moko138 a écrit :

sdb
     Partition               Start        End    
>  MS Data                   264192 7814035455
Mais
sudo dd if=/dev/sdb bs=512 count=1 skip=7814037135 | hexdump -C
On est au-delà du disque.

Les LBA proposées partaient des infos disponibles en #16, soit une capacité du disque de 4000787030016 octets, soient 4000787030016/512 = 7814037168 secteurs.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 18/09/2019, à 08:18

[Résolu] Disque dur 4to marque 1.64to sur Gparted

#2 Le 18/09/2019, à 09:20

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#3 Le 18/09/2019, à 10:02

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#4 Le 18/09/2019, à 12:20

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#5 Le 18/09/2019, à 12:48

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#6 Le 18/09/2019, à 15:19

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#7 Le 18/09/2019, à 17:58

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#8 Le 18/09/2019, à 18:04

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#9 Le 18/09/2019, à 18:07

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#10 Le 18/09/2019, à 18:21

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#11 Le 19/09/2019, à 02:07

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#12 Le 19/09/2019, à 02:22

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#13 Le 19/09/2019, à 04:48

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#14 Le 19/09/2019, à 09:06

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#15 Le 19/09/2019, à 10:34

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#16 Le 19/09/2019, à 11:06

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#17 Le 19/09/2019, à 11:32

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#18 Le 19/09/2019, à 11:48

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#19 Le 19/09/2019, à 12:13

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#20 Le 19/09/2019, à 13:17

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#21 Le 19/09/2019, à 13:39

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#22 Le 19/09/2019, à 13:43

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#23 Le 19/09/2019, à 14:15

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#24 Le 19/09/2019, à 14:25

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

#25 Le 19/09/2019, à 14:34

Re : [Résolu] Disque dur 4to marque 1.64to sur Gparted

Pied de page des forums