Disque dur devenu inaccessible !

Support Debian
#1

Hello,

J’ai acheté et formaté (je l’ai divisé en deux partoches pour accélérer l’accès au fichiers par des appareils de faible puissance de calcul) ce disque dur pour l’offrir à ma mère qui s’en sert pour enregistrer la TNT sur son adaptateur externe.

Un beau jour elle n’a plus pu y accéder.

J’imagine que la Table d’Allocation des Fichiers a été endommagée.

Quand je branche le disque sur mon système, il ne se monte pas.

GNOME Disks m’affiche cela, sans possibilité de monter les partitions :

En fait, même le FS n’est pas mentionné et je peux le configurer moi-même via GNOME Disks/Modifier la partition (de mémoire c’était du FAT32 mais GNOME Disks me propose plein de versions différentes)

Une idée de si c’est récupérable ?

Merci d’avance !

#2

Salut
Dans une fenêtre terminal, tu lances la commande

tail -f /var/log/kern.log

Puis tu branches le disque sur un port usb

Les messages en diront plus sur le disque et son état

ensuite la commande

sudo fdisk -l

#3

Merci :slight_smile:

Alors j’obtiens :

Jan 30 00:03:23 HAL kernel: [37595.573555] usb 1-1.3: new high-speed USB device number 15 using ehci-pci
Jan 30 00:03:23 HAL kernel: [37595.684588] usb 1-1.3: New USB device found, idVendor=0480, idProduct=a20c
Jan 30 00:03:23 HAL kernel: [37595.684592] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 30 00:03:23 HAL kernel: [37595.684594] usb 1-1.3: Product: External USB 3.0
Jan 30 00:03:23 HAL kernel: [37595.684595] usb 1-1.3: Manufacturer: TOSHIBA
Jan 30 00:03:23 HAL kernel: [37595.684597] usb 1-1.3: SerialNumber: 23945B051704
Jan 30 00:03:23 HAL kernel: [37595.685138] usb-storage 1-1.3:1.0: USB Mass Storage device detected
Jan 30 00:03:23 HAL kernel: [37595.685280] scsi host6: usb-storage 1-1.3:1.0
Jan 30 00:03:26 HAL kernel: [37598.692596] scsi 6:0:0:0: Direct-Access     TOSHIBA  External USB 3.0 5438 PQ: 0 ANSI: 6
Jan 30 00:03:26 HAL kernel: [37598.693028] sd 6:0:0:0: Attached scsi generic sg3 type 0
Jan 30 00:03:26 HAL kernel: [37598.694801] sd 6:0:0:0: [sdc] 1953525164 512-byte logical blocks: (1.00 TB/932 GiB)
Jan 30 00:03:26 HAL kernel: [37598.695665] sd 6:0:0:0: [sdc] Write Protect is off
Jan 30 00:03:26 HAL kernel: [37598.695668] sd 6:0:0:0: [sdc] Mode Sense: 23 00 00 00
Jan 30 00:03:26 HAL kernel: [37598.696411] sd 6:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 30 00:03:26 HAL kernel: [37598.705086]  sdc: sdc1 sdc2 sdc3 sdc4
Jan 30 00:03:26 HAL kernel: [37598.705234] sdc: p4 start 4227891237 is beyond EOD, enabling native capacity
Jan 30 00:03:26 HAL kernel: [37598.709682]  sdc: sdc1 sdc2 sdc3 sdc4
Jan 30 00:03:26 HAL kernel: [37598.709935] sdc: p4 start 4227891237 is beyond EOD, truncated
Jan 30 00:03:26 HAL kernel: [37598.713867] sd 6:0:0:0: [sdc] Attached SCSI disk

Puis, pour la commande fdisk -l :

Disque /dev/sdc : 931,5 GiB, 1000204883968 octets, 1953525164 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 : 0x80250fa8

Périphérique Amorçage      Début        Fin   Secteurs Taille Id Type
/dev/sdc1                      0      65535      65536    32M  0 Vide
/dev/sdc2              847282274  851509457    4227184     2G 62 inconnu
/dev/sdc3                  32842     491593     458752   224M 70 DiskSecure Mult
/dev/sdc4             4227891237 8455782548 4227891312     2T 70 DiskSecure Mult```
Les entrées de la table de partitions ne sont pas dans l'ordre du disque.
#4

À mon avis, le disque doit être dans un format propriétaire ou non-standard pour l’adaptateur TNT.
Est-ce que tu peux nous préciser la marque et le modèle de cet adaptateur TNT ?

#5

sdc: p4 start 4227891237 is beyond EOD

si EOD veut dire end of dssk, l’architecture du disque est incohérente, la partition sdc4 commence après la fin du disque??

les type des partitions: inconnu, DiskSecure Mult :confounded: ça ne m’inspire pas

Faut attendre l’avis d’un expert ,

quel est l’erreur si tu fais

sudo mount /dev/sdc4 /mnt

#6

Ou bien, comme le suppose @Almtesh, le MBR ne contient pas de table de partition DOS, et ce que le noyau et fdisk essaient d’interpréter comme une table de partition donne des résultats incohérents.

Ça pourrait être intéressant de voir ce qu’en dit file.

file -sk /dev/sdc

C’est peut-être un disque non partitionné (mode super-disquette) avec un système de fichiers de type connu.

#7

Merci de vos retours

sudo mount /dev/sdc4 /mnt
mount: /mnt : le périphérique spécial /dev/sdc4 n’existe pas.

Dans Disks (photo ci-dessus), de gauche à droite :
“Partition 1” est /dev/sdc1
"Partition 3" est /dev/sdc3
"Espace disponible" est Espace non alloué
"Partition 2" est /dev/sdc2
"Espace disponible" est Espace non alloué

file -sk /dev/sdc
/dev/sdc: DOS/MBR boot sector; partition 2 : ID=0x62, start-CHS (0x248,0,8), end-CHS (0x248,128,48), startsector 847282274, 4227184 sectors; partition 3 : ID=0x70, start-CHS (0x235,0,0), end-CHS (0x0,128,0), startsector 32842, 458752 sectors; partition 4 : ID=0x70, start-CHS (0x0,0,0), end-CHS (0x21b,128,24), startsector 4227891237, 4227891312 sectors DOS/MBR boot sector COM executable for DOS\012- data

Je précise qu’avant ce pb, le disque était bien lu tant sur l’adaptateur CGV que sur PC

#8

grandtoubab, PascalHambourg et les autres : est-ce que ces derniers résultats permettent d’en savoir plus sur le problème ?
Merci d’avance !

#9

En cherchant

https://www.disk-partition.com/ssd-management/toshiba-ssd-secure-erase-3889.html

Aucune idée si ça peut t’aider, je ne connais pas ce type de fichier

#10

Désolé, mais je ne peux rien tirer de ces dernières informations.

Néanmoins, le contenu de la table de partition du MBR étant manifestement invalide, je doute que la piste “Disksecure” mène quelque part. Quant à l’effacement sécurisé de SSD de Toshiba, je ne vois carrément pas le rapport.

Si le contenu était lisible depuis Debian, c’est forcément qu’il y avait un système de fichiers de type reconnu. Peut-être que testdisk pourrait retrouver son emplacement.

#11

Merci, testdisk semble prometteur, je vais creuser cette piste
https://www.cgsecurity.org/wiki/TestDisk_FR

#12

je suis https://www.cgsecurity.org/wiki/TestDisk_Etape_par_Etape et note ici les résultats au fur et à mesure du test :

1°) j’ai lancé l’analyse :

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

2 P Sys=62 52740 224 63 53004 3 9 4227184

Bad relative sector.
3 P DiskSecure MB 2 11 20 30 153 5 458752

Warning: Bad starting sector (CHS and LBA don’t match)
4 P DiskSecure MB 263174 14 46 526348 30 39 4227891312

Warning: Bad starting sector (CHS and LBA don’t match)
No partition is bootable

Maintenant je lance le Quick Search…
Le test est long, je reviendrai sûrement poster la suite après diner

#13

2°) Quick Search :

Disk /dev/sdc - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
>* FAT32 LBA            63231  64  2 121601  57 56  937713664 [toshiba2]

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,
#14

Ensuite je valide et l’utilitaire revient au sommaire

Est-ce que si je change les caractéristiques en passant chaque partoche en FAT32 à la main ça me permettrait de récupérer le disque ?
Au moins pour les deux grosses partoches données sous GNOME Disks comme “Espace non alloué”, de 434Go et 564Go ? Edit : Ha zut, faut d’abord créer une partoche… je sens que c’est une mauvaise idée pour récupérer mes données ?

#15

La partition détectée par testdisk contiendrait un système de fichiers FAT32 et s’étendrait sur la deuxième moitié du disque. Cela te semble-t-il correct ? Y avait-il plusieurs partitions sur le disque ? Sinon, ça peut être le reste d’une ancienne partition qui avait été supprimée et dont le contenu n’a pas été écrasé par de nouvelles données.

Ce qui est pénible avec testdisk, c’est qu’il utilise encore l’adressage CHS oboslète alors que l’adressage LBA est généralisé depuis longtemps…
Avec la position en LBA, il aurait été possible de monter le disque (en lecture seule) à l’offset indiqué pour voir ce que contient ce supposé système de fichiers FAT. Avec la position CHS, il faut convertir en LBA sans se tromper dans la formule.

LBA = ((63231 * 255) + 64) * 63 + 2 - 1 = 1015810048

C’est un multiple entier de 2048 secteurs, la taille de bloc sur laquelle les partitionneurs modernes alignent les partitions donc c’est plutôt bon signe.

mount -r -t vfat -o loop,offset=520094744576 /dev/sdc /mnt

Est-ce que testdisk a modifié la table de partition du disque pour y mettre la partition détectée ? Sinon, il faut peut-être appuyer sur A pour ajouter la partition comme indiqué.

Quelles partitions ? Celles définies dans la table de partition actuelle sont bidon.

Ce ne sont pas des partitions, c’est de l’espace non alloué entre les portions soit-disant occupées par les partitions bidon. Donc tout aussi bidon.

#16

Hello,

Après inondations et vacances, j’ai pu reprendre cette tâche où je m’étais arrêté, et voici le CR :

  • tesdisk est super, je ne connaissais pas, mais je n’ai pu résoudre mon pb avec. Un des pbs est qu’il me demande de lui dire quel était le FS et je ne savais pas, entre les différents FAT (lequel est celui pratiqué par GNOME Disque dans la multitude proposée ?) et NTFS je ne me souvenais plus.
  • photorec est également super et a pu me récupérer moult fichiers et j’ai ensuite reformaté le disque dur (avec fdisk, car GNOME Disque n’a pas su quoi faire avec les erreurs présentes sur le disque) en 2 partoches égales FAT32 et y recopier les fichiers sauvés.

NB :

Merci à vous trois !