Pages : 1
#1 Le 30/08/2019, à 12:01
- Markorki
Données sur partition "perdue" mais vue par gparted
Bonjour. C'est un appel au secours!
Si mon post n'estpas où il devrait être, merci de m'informer et de le déplacer ou de me demander de le déplacer.
J'ai un PC qui m'a valu pas mal d'ennuis : multiplication d'erreurs smart avec toujours une au boot, mais tout semblant aller bien à part cette erreur systématique. Geole m'a aidé, et m'a conseillé d'attendre quelques semaines pour voir la multiplication des erreurs et tenter de voir si un logiciel était en cause. En attendant, je commandais un DD de 4T.
Et soudain une semaine d'orage (j'ai un anti-surtension, avec du monde dessus, dont ma live-box qui est OK), mon PC a rebooté 2 fois de suite en plein boulot, sans raison apparente. Plusieurs fois ensuite un DD passait en read-only en cours de session, et le temps de chercher à comprendre, le PC ne bootait plus. J'ai écarté le pb de pile de BIOS en la changeant, et en restant brancéh au mur avec le switch arrière de la 'alim de la tour sur "on", et mis le setup en "par déaut" , config pas rapide mais normalement sans risque.
J'ai donc tenté de booter en live : ok, mais une partition n'est plus vue, hélas partition de données, dernière sauvegarde récente (mi-Juillet) mais beaucoup de changements depuis sur cette partition.
Je soupçonne un pb de faiblesse de la carte mère (selon boot, le "menu de démarrage " voyant 1, 2 ou 3 DD, et le boot sur DD ne finissant jamais, et live pas toujours.
Par contre, la partition est partiellement "vue" par Gparted , par sa taille, mais comme de type inconnu.
Or avec mes ennuis précédents, j'ai toutes les infos en secteurs sur cette partition, et sur son type, par des sorties de fdisk -l .
Est-il possible de "réparer" la table de partitions avec les infios de fdisk -l , et maintenant que j'ai un gros disque, de récupérer le contenu ou au moins ce qu'on pourra ?
Merci.
Hors ligne
#2 Le 30/08/2019, à 12:47
- Nasman
Re : Données sur partition "perdue" mais vue par gparted
Que donne
sudo fdisk -l
Donne aussi des infos sur tes partitions (type de systèmes de fichiers, taille des partitions, ordre des partitions...)
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#3 Le 30/08/2019, à 16:49
- Markorki
Re : Données sur partition "perdue" mais vue par gparted
Merci de me répondre.
Je suis sur le PC de ma femme, où j'ai heureusement une copie de mon home d'il y a qq mois, et donc mes mots de passe.
Le DD malade est dans un dock USB acheté récemment, arrivé *après* la cata.
Voici le résultat actuel de fdisk -l :
sda est le disque où je boote (~ 500Go, en 16-04) , sdf est le disque malade
annemarie@PC-4c-AM:~$ sudo fdisk -l
[sudo] Mot de passe de annemarie :
Désolé, essayez de nouveau.
[sudo] Mot de passe de annemarie :
Disque /dev/sda : 465,8 GiB, 500107862016 octets, 976773168 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 : 0x000bc2e5
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sda1 * 2048 20809727 20807680 9,9G 83 Linux
/dev/sda2 20809728 41617407 20807680 9,9G 83 Linux
/dev/sda3 41617408 58394623 16777216 8G 82 partition d'échang
/dev/sda4 58394624 976773119 918378496 437,9G 5 Étendue
/dev/sda5 955965440 976773119 20807680 9,9G 83 Linux
/dev/sda6 935157760 955965439 20807680 9,9G 83 Linux
/dev/sda7 58396672 834779135 776382464 370,2G 83 Linux
/dev/sda8 834781184 883965951 49184768 23,5G 83 Linux
/dev/sda9 883968000 935155711 51187712 24,4G 83 Linux
Les entrées de la table de partitions ne sont pas dans l'ordre du disque.
Disque /dev/sdf : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 4096 octets / 33553920 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x000cc6b4
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sdf1 * 20897790 1048594431 1027696642 490G 5 Étendue
/dev/sdf2 1048594680 3907024064 2858429385 1,3T 83 Linux
/dev/sdf5 20897792 42606591 21708800 10,4G 83 Linux
/dev/sdf6 42608640 64727039 22118400 10,6G 83 Linux
/dev/sdf7 64729088 88076287 23347200 11,1G 83 Linux
/dev/sdf8 178364416 1048594431 870230016 415G 83 Linux
/dev/sdf9 88078336 129044479 40966144 19,5G 83 Linux
/dev/sdf10 129060864 178358271 49297408 23,5G 83 Linux
La partition 1 ne commence pas sur une frontière de cylindre physique.
Les entrées de la table de partitions ne sont pas dans l'ordre du disque.
annemarie@PC-4c-AM:~$
à rapprocher du fdisk -l de décembre dernier, où le disque en question esten sdb :
et fdisk-l_181213 :
Disque /dev/sda : 465,8 GiB, 500107862016 octets, 976773168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000a14a8
Périphérique Amorçage Start Fin Secteurs Size Id Type
/dev/sda1 * 63 21093344 21093282 10,1G 83 Linux
/dev/sda2 21093345 42186689 21093345 10,1G 83 Linux
/dev/sda3 959980140 976768064 16787925 8G 82 partition d'échange Linux / Solaris
/dev/sda4 42186877 959980139 917793263 437,7G f Étendue W95 (LBA)
/dev/sda5 42186879 880908209 838721331 400G 83 Linux
/dev/sda6 880908273 898515449 17607177 8,4G 83 Linux
/dev/sda7 898515576 915994091 17478516 8,3G 83 Linux
/dev/sda8 915994233 959980139 43985907 21G 83 Linux
Partition table entries are not in disk order.
Disque /dev/sdb : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x000cc6b4
Périphérique Amorçage Start Fin Secteurs Size Id Type
/dev/sdb1 * 4096 1048594431 1048590336 500G 5 Étendue
/dev/sdb2 1048594680 3907024064 2858429385 1,3T 83 Linux
/dev/sdb5 16065 20884499 20868435 10G 83 Linux
/dev/sdb6 20897792 42606591 21708800 10,4G 83 Linux
/dev/sdb7 42608640 64727039 22118400 10,6G 83 Linux
/dev/sdb8 64729088 88076287 23347200 11,1G 83 Linux
/dev/sdb9 178364416 1048594431 870230016 415G 83 Linux
/dev/sdb10 88078336 129044479 40966144 19,5G 83 Linux
/dev/sdb11 129060864 178358271 49297408 23,5G 83 Linux
Partition table entries are not in disk order.
Disque /dev/sdc : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x0005810e
Périphérique Amorçage Start Fin Secteurs Size Id Type
/dev/sdc1 2048 30714938 30712891 14,7G 83 Linux
/dev/sdc2 30716280 64308194 33591915 16G 82 partition d'échange Linux / Solaris
/dev/sdc3 64308319 3907020799 3842712481 1,8T 5 Étendue
/dev/sdc5 3882446848 3907020799 24573952 11,7G 83 Linux
/dev/sdc6 * 3857868800 3882444799 24576000 11,7G 83 Linux
/dev/sdc7 3833288704 3857864703 24576000 11,7G 83 Linux
/dev/sdc8 3808706328 3833285714 24579387 11,7G 83 Linux
/dev/sdc9 3784126878 3808706264 24579387 11,7G 83 Linux
/dev/sdc10 64308321 3616199369 3551891049 1,7T 83 Linux
Partition table entries are not in disk order.
Pour les types et usages de mes partitions, il n'y a plus que la partition de données "Data_3" qui soit critique.
Sur ce blkid, c'est donc sdb, avec comme partitions :
fichier blkid_181213 :
/dev/sda1: LABEL="Boot_10-04" UUID="c28c2dba-8133-4a29-ab58-149d6b55f2dc" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="000a14a8-01"
/dev/sda2: LABEL="Boot_12-04" UUID="55e096fc-b3dd-476d-8abd-736e982feae9" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="000a14a8-02"
/dev/sda5: LABEL="Data_1_MM" UUID="33072dff-3674-481d-937a-fc197b9ebc53" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="000a14a8-05"
/dev/sda6: LABEL="Home_10-04" UUID="60a643e0-0601-4caa-9389-78ab39ccfa40" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="000a14a8-06"
/dev/sda7: LABEL="Home_12-04" UUID="de91580a-8792-45d1-9d23-6b891418d878" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="000a14a8-07"
/dev/sda8: LABEL="Data_2_MM" UUID="6a8e8460-d91a-4b94-9437-6b168c565f98" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="000a14a8-08"
/dev/sdb10: UUID="d59f39da-616e-4498-9616-c8f32e2cabe5" TYPE="ext4" PARTUUID="000cc6b4-0a"
/dev/sdb11: UUID="30ee13ff-8aaf-4e87-ba17-f1e922f6a654" TYPE="ext4" PARTUUID="000cc6b4-0b"
/dev/sdb2: LABEL="MM_133T" UUID="6ba028f3-3862-495d-9245-e2a82a193cb7" TYPE="ext4" PARTUUID="000cc6b4-02"
/dev/sdb5: LABEL="Boot_xu14" UUID="4f8361e8-9c7c-434f-9ad4-016f45abe5f6" TYPE="ext4" PARTUUID="000cc6b4-05"
/dev/sdb6: LABEL="Home_xu14" UUID="4e14e710-83ee-4318-b7f8-9197d116bd47" TYPE="ext4" PARTUUID="000cc6b4-06"
/dev/sdb7: LABEL="Boot_flbk14" UUID="b2ff9651-9ba4-44aa-811f-fce5d418afd8" TYPE="ext4" PARTUUID="000cc6b4-07"
/dev/sdb8: LABEL="Home_flbk14" UUID="c6997aa3-e837-441c-8818-9ac0b3afd91c" TYPE="ext4" PARTUUID="000cc6b4-08"
/dev/sdb9: LABEL="Data_3_MM" UUID="c6dbc3e4-2066-49c7-a754-e1378e7d2af2" TYPE="ext4" PARTUUID="000cc6b4-09"
/dev/sdc1: LABEL="Boot_0_201504" UUID="04762e64-8c69-492d-b460-d01d3b6aa5e4" TYPE="ext4" PARTUUID="0005810e-01"
/dev/sdc10: LABEL="MM_166T" UUID="a503d397-0bee-47df-baf1-170310fd7a22" TYPE="ext4" PARTUUID="0005810e-0a"
/dev/sdc5: LABEL="Home_0_201504" UUID="067088c8-2058-4f6a-a524-deda8f643c0c" TYPE="ext4" PARTUUID="0005810e-05"
/dev/sdc6: LABEL="Boot_1_ref" UUID="04762e64-8c69-492d-b460-d01d3b6aa5e4" TYPE="ext4" PARTUUID="0005810e-06"
/dev/sdc7: LABEL="Home_1_ref" UUID="19473ae1-3263-4502-ac56-0cd9d7165aed" TYPE="ext4" PARTUUID="0005810e-07"
/dev/sdc8: LABEL="Boot_2_201504" UUID="0ad813d1-039d-4b9b-96f3-17b7e32ee20c" TYPE="ext4" PARTUUID="0005810e-08"
/dev/sdc9: LABEL="Home_2_201504" UUID="9704e834-9ba6-482b-8c4e-b7c1562c9043" TYPE="ext4" PARTUUID="0005810e-09"
Les partitions marquées Home ou Boot sont des systèmes installés pour test il y a longtemps, que je devais nettoyer en un seul morceau.
Celle qui m'intéresse est "Data3_MM, les autres partitions de données sont sauvegardées, pour DATA_3, pas eu le temps.
Le système où je bootais est sur un disque que j'ai laissé dans le PC à pb. C'est une 18-04-mate avec un home séparé, Tu veux plus de caractéristiques ? Je suis connecté sous le compte de ma femme, et c'est plus facile de trouver mes notes en étant sous mon compte sur sa machine.
Dernière modification par Markorki (Le 30/08/2019, à 16:53)
Hors ligne
#4 Le 30/08/2019, à 17:23
- Nasman
Re : Données sur partition "perdue" mais vue par gparted
S'il n'y a pas eu de repartitionnement de fait entre la version de décembre et la situation actuelle, il doit être possible de restaurer l'accès aux partitions
sdf2, sdf5-sdf10, soit sdb2, sdb6-sdb11.
On va regarder le contenu du mbr de sdf et les ebr ("tables des partitions logiques)
sudo dd if=/dev/sdf bs=512 count=1 | hexdump -C
et
sudo dd if=/dev/sdf1 bs=512 count=1 | hexdump -C
(1er ebr=partition étendue)
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#5 Le 30/08/2019, à 18:49
- Markorki
Re : Données sur partition "perdue" mais vue par gparted
MBR de sdf :
annemarie@PC-4c-AM:~$ sudo dd if=/dev/sdf bs=512 count=1 | hexdump -C
[sudo] Mot de passe de annemarie :
00000000 eb 63 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |.c..............|
1+0 enregistrements lus
1+0 enregistrements écrits
00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..|
00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u|
00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.........|...t..|
512 bytes copied, 4,73209 s, 0,1 kB/s
00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.....|.........|
00000050 00 00 00 00 00 00 00 00 00 00 00 80 01 00 00 00 |................|
00000060 00 00 00 00 ff fa 90 90 f6 c2 80 75 02 b2 80 ea |...........u....|
00000070 74 7c 00 00 31 c0 8e d8 8e d0 bc 00 20 fb a0 64 |t|..1....... ..d|
00000080 7c 3c ff 74 02 88 c2 52 bb 17 04 80 27 03 74 06 ||<.t...R....'.t.|
00000090 be 88 7d e8 1c 01 be 05 7c f6 c2 80 74 48 b4 41 |..}.....|...tH.A|
000000a0 bb aa 55 cd 13 5a 52 72 3d 81 fb 55 aa 75 37 83 |..U..ZRr=..U.u7.|
000000b0 e1 01 74 32 31 c0 89 44 04 40 88 44 ff 89 44 02 |..t21..D.@.D..D.|
000000c0 c7 04 10 00 66 8b 1e 5c 7c 66 89 5c 08 66 8b 1e |....f..\|f.\.f..|
000000d0 60 7c 66 89 5c 0c c7 44 06 00 70 b4 42 cd 13 72 |`|f.\..D..p.B..r|
000000e0 05 bb 00 70 eb 76 b4 08 cd 13 73 0d f6 c2 80 0f |...p.v....s.....|
000000f0 84 d0 00 be 93 7d e9 82 00 66 0f b6 c6 88 64 ff |.....}...f....d.|
00000100 40 66 89 44 04 0f b6 d1 c1 e2 02 88 e8 88 f4 40 |@f.D...........@|
00000110 89 44 08 0f b6 c2 c0 e8 02 66 89 04 66 a1 60 7c |.D.......f..f.`||
00000120 66 09 c0 75 4e 66 a1 5c 7c 66 31 d2 66 f7 34 88 |f..uNf.\|f1.f.4.|
00000130 d1 31 d2 66 f7 74 04 3b 44 08 7d 37 fe c1 88 c5 |.1.f.t.;D.}7....|
00000140 30 c0 c1 e8 02 08 c1 88 d0 5a 88 c6 bb 00 70 8e |0........Z....p.|
00000150 c3 31 db b8 01 02 cd 13 72 1e 8c c3 60 1e b9 00 |.1......r...`...|
00000160 01 8e db 31 f6 bf 00 80 8e c6 fc f3 a5 1f 61 ff |...1..........a.|
00000170 26 5a 7c be 8e 7d eb 03 be 9d 7d e8 34 00 be a2 |&Z|..}....}.4...|
00000180 7d e8 2e 00 cd 18 eb fe 47 52 55 42 20 00 47 65 |}.......GRUB .Ge|
00000190 6f 6d 00 48 61 72 64 20 44 69 73 6b 00 52 65 61 |om.Hard Disk.Rea|
000001a0 64 00 20 45 72 72 6f 72 0d 0a 00 bb 01 00 b4 0e |d. Error........|
000001b0 cd 10 ac 3c 00 75 f4 c3 b4 c6 0c 00 00 00 80 fe |...<.u..........|
000001c0 ff ff 05 fe ff ff fe df 3e 01 02 68 41 3d 00 fe |........>..hA=..|
000001d0 ff ff 83 fe ff ff f8 48 80 3e c9 2b 60 aa 00 00 |.......H.>.+`...|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200
annemarie@PC-4c-AM:~$
et EBR
annemarie@PC-4c-AM:~$ sudo dd if=/dev/sdf1 bs=512 count=1 | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
1+0 enregistrements lus
1+0 enregistrements écrits
*
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe |................|
000001c0 ff ff 83 fe ff ff 02 00 00 00 00 40 4b 01 00 fe |...........@K...|
000001d0 ff ff 05 fe ff ff 02 40 4b 01 00 88 51 01 00 00 |.......@K...Q...|
512 bytes copied, 0,000340083 s, 1,5 MB/s
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200
annemarie@PC-4c-AM:~$
Hors ligne
#6 Le 31/08/2019, à 08:44
- Nasman
Re : Données sur partition "perdue" mais vue par gparted
Le mbr dit :
sdf1 (étendue) est en 20897790 et a une taille de 1027696642 secteurs (se termine donc en 1048594431)
sdf2 (principale en extx) commence en 1048594680 et fait 2858429385 secteurs (se termine en 3907024064)
sdf1 correspond à un alignement au Mio (-2 secteurs car partition étendue) et sdf2 est alignée au cylindre
L'en-tête de sdf1 indique une première partition logique sdf5 en extx commençant en 20897790+2 = 20897792 (donc alignée au Mio)
Le deuxième ebr commence en 1048594680+21708802=1070303482
On va vérifier si on a deux entrées dans cet ebr, l'une vers sdf6 et l'autre vers un troisième ebr, si c'est le cas, le chainage sera correct avec
sudo dd if=/dev/sdf bs=512 count=1 skip=1070303482 | hexdump -C
D'autre part compte tenu du décalage des numéros des partitions logiques (sdfx et sdbx), je pense que la première partition a sauté
On va rechercher ce qu'il y a au secteur 4096 de sdf (peut être l'emplacement de la partition de sdb5)
sudo dd if=/dev/sdf bs=512 count=1 skip=4096 | hexdump -C
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#7 Le 01/09/2019, à 11:35
- Markorki
Re : Données sur partition "perdue" mais vue par gparted
Excuse mon absence hier, il y avait une réunion de famille chez moi, fallait que je bosse comme les autres :-)
résultat premier dd :
marc@PC-4c-AM:~$ sudo dd if=/dev/sdf bs=512 count=1 skip=1070303482 | hexdump -C[sudo] Mot de passe de marc :
00000000 1a 18 a6 b6 a9 7f 8d db 60 32 4c b1 85 a7 0a 1c |........`2L.....|
00000010 63 f8 ad f0 33 1c 2a cc ca 91 47 95 85 42 2d 7d |c...3.*...G..B-}|
1+0 enregistrements lus
1+0 enregistrements écrits
00000020 2e 26 37 e0 39 fb a5 7a b1 2c c5 f8 f7 e7 20 cc |.&7.9..z.,.... .|
00000030 75 71 01 0f 71 78 49 4a 48 49 bf 08 ed f4 a8 44 |uq..qxIJHI.....D|
512 bytes copied, 0,587457 s, 0,9 kB/s00000040 56 ff a3 58 a4 2b 5a e7 06 65 81 d8 e6 3b da fa |V..X.+Z..e...;..|
00000050 4b e5 a6 9b 7f c4 8d e8 c9 c7 e1 0a a3 cc 54 89 |K.............T.|
00000060 94 e6 dc 89 75 83 20 1a 13 17 00 92 12 e7 07 16 |....u. .........|
00000070 ae e2 cc 8e 07 69 48 0e 35 13 ff 8d ed c0 9b 35 |.....iH.5......5|
00000080 11 c0 1b 3c 74 6a 26 be db 1a 7c bd 90 7e 93 10 |...<tj&...|..~..|
00000090 d4 43 17 ef e2 42 23 6b 16 d6 5f db 44 c3 3c 08 |.C...B#k.._.D.<.|
000000a0 e3 26 25 ac bb 40 d8 fc 6a dc 61 c5 78 c7 95 54 |.&%..@..j.a.x..T|
000000b0 8d 33 42 39 4b fe 36 e3 b7 2d d6 ed 3d b2 d5 99 |.3B9K.6..-..=...|
000000c0 59 4c 8c 61 9e 35 de a9 71 b8 5c ab 5a 64 ff 82 |YL.a.5..q.\.Zd..|
000000d0 10 52 36 4f ab 25 cd 46 a8 40 89 75 37 73 2b 1a |.R6O.%.F.@.u7s+.|
000000e0 88 4e 86 a2 34 75 b5 42 34 34 aa bc 28 df dc 62 |.N..4u.B44..(..b|
000000f0 fa 7f e3 7b 4f 4c a1 82 56 2b d9 96 36 a6 aa c9 |...{OL..V+..6...|
00000100 e9 37 1b 07 7d 41 0e db db f1 b6 c3 10 8f b6 f6 |.7..}A..........|
00000110 65 50 c4 77 c7 82 13 b1 93 72 77 dd 69 ff 83 00 |eP.w.....rw.i...|
00000120 3c 89 a9 b9 94 59 8e 35 5e 11 82 2f 69 f0 ae 15 |<....Y.5^../i...|
00000130 27 0f fb ff 88 08 02 9e 75 b0 89 65 d6 68 74 e8 |'.......u..e.ht.|
00000140 2e f8 df 76 64 a7 3d 28 d3 2a 1a 51 ca 3c 65 1e |...vd.=(.*.Q.<e.|
00000150 74 31 39 f7 0b 08 c9 59 55 70 ad e8 f7 05 fe c9 |t19....YUp......|
00000160 f5 97 bf e2 04 0d a4 b8 7f ac 34 3c b4 70 c6 7c |..........4<.p.||
00000170 79 a8 9e d4 8a d2 0e 6d 80 10 46 d6 1c 74 ad b0 |y......m..F..t..|
00000180 98 4c 2f 86 dc 06 03 10 24 92 ee d8 22 15 07 c7 |.L/.....$..."...|
00000190 3f 53 68 72 2e ed 13 79 d8 2f e5 d8 fa fa ef 60 |?Shr...y./.....`|
000001a0 ff f8 53 33 8c c1 bb 66 d0 a9 36 e6 e8 57 03 91 |..S3...f..6..W..|
000001b0 7e e5 69 b3 19 35 c6 54 24 09 cc 4f f1 b4 4f 3e |~.i..5.T$..O..O>|
000001c0 9c d9 0e cb 84 7f 58 c0 60 47 bb cb 25 ed ff 85 |......X.`G..%...|
000001d0 24 f4 97 31 1d 1d 81 dc a2 72 3e 28 05 63 1b 0e |$..1.....r>(.c..|
000001e0 a4 c3 b7 63 c3 fe 9c 1f 05 70 24 ab cd 1f 60 6c |...c.....p$...`l|
000001f0 00 03 94 98 6b 12 48 9c 34 78 ef 99 36 19 71 31 |....k.H.4x..6.q1|
00000200
marc@PC-4c-AM:~$
Et le second
marc@PC-4c-AM:~$ sudo dd if=/dev/sdf bs=512 count=1 skip=4096 | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
1+0 enregistrements lus
1+0 enregistrements écrits
000001c0 01 01 83 fe ff ff c1 2e 00 00 53 6d 3e 01 00 fe |..........Sm>...|
000001d0 ff ff 05 fe ff ff 14 9c 3e 01 ec 73 4b 01 00 00 |........>..sK...|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
512 bytes copied, 4,91842 s, 0,1 kB/s
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200
marc@PC-4c-AM:~$
Conforme à ce que tu avais prévu ?
Hors ligne
#8 Le 01/09/2019, à 14:20
- Nasman
Re : Données sur partition "perdue" mais vue par gparted
Au secteur 4096 (deuxième commande) il y a une entrée qui pointe 11969 secteurs (séquence c1 2e 00 00) plus loin que l'ebr courant, soit à la LBA 16065 qui correspond au sdb5. La première partition logique doit pouvoir être retrouvée.
La deuxième entrée pointe vers l'ebr situé 20880404 secteurs après le début de la partition étendue. La question :
- doit on prendre comme base le début de l'actuelle partition étendue (soit 20897790), ce qui donnerait 20880404+20897790=41778194
- ou plutôt l'ancienne partition étendue qui commencerait en 4096, soit 20880404+4096=20884500 (donc juste après sdb5.
Que donne
sudo dd if=/dev/sdf bs=512 count=1 skip=20884500 | hexdump -C
Si c'est bien le bon ebr alors sa première entrée devrait pointer vers le secteur 20897792
La correction dans ce cas consisterait juste à indiquer le bon emplacement de la partition étendue au secteur 4096 au lieu de 20897790
La première commande ne semble pas correspondre à un ebr --> je pense que la vraie partition étendue commence en 4096 et non pas en 20897790
Dernière modification par Nasman (Le 01/09/2019, à 14:38)
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#9 Le 01/09/2019, à 14:38
- Markorki
Re : Données sur partition "perdue" mais vue par gparted
marc@PC-4c-AM:~$
marc@PC-4c-AM:~$ sudo dd if=/dev/sdf bs=512 count=1 skip=20884500 | hexdump -C
[sudo] Mot de passe de marc :
Désolé, essayez de nouveau.
[sudo] Mot de passe de marc :
1+0 enregistrements lus
1+0 enregistrements écrits
00000000 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 00 00 00 00 00 fe |................|
000001c0 ff ff 83 fe ff ff ec 33 00 00 00 40 4b 01 00 fe |.......3...@K...|
512 bytes copied, 0,607058 s, 0,8 kB/s
000001d0 ff ff 05 fe ff ff 00 10 8a 02 00 88 51 01 00 00 |............Q...|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200
marc@PC-4c-AM:~$
la première entrée, c'est ce qui démarre en 1bf ?
Où commence la chaine à convertir ?
Hors ligne
#10 Le 01/09/2019, à 15:38
- Nasman
Re : Données sur partition "perdue" mais vue par gparted
La première entrée commence par ec 33 00 00, c'est l'adresse hexa en mode little endian, soit 0x000033ec en hexa, soit 13292 secteurs après l'ebr courant, soit en 20884500+13292=20897792
L'autre entrée correspond à l'ebr suivant mais le déplacement est exprimé par rapport au début de la partition étendue - en l'occurence 4096
Ce qui donne 00 10 8a 02 --> 0x28A1000 --> 42602496. L'ebr suivant commence donc en 42602496+4096=42606592.
On va donc devoir corriger l'entrée vers la partition étendue du mbr, donnée par
000001b0 cd 10 ac 3c 00 75 f4 c3 b4 c6 0c 00 00 00 80 fe |...<.u..........|
000001c0 ff ff 05 fe ff ff fe df 3e 01 02 68 41 3d 00 fe |........>..hA=..|
par
000001b0 cd 10 ac 3c 00 75 f4 c3 b4 c6 0c 00 00 00 80 fe |...<.u..........|
000001c0 ff ff 05 fe ff ff 00 10 00 00 f8 38 80 3e 00 fe |........>..hA=..|
Les 4 premiers octets correspondent à la LBA de début (en hexa little endian), les 4 suivants correspondent à la taille en secteurs (hexa little endian).
Normalement la nouvelle fin est juste avant sdf2
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#11 Le 01/09/2019, à 16:09
- Markorki
Re : Données sur partition "perdue" mais vue par gparted
Les 4 premiers octets correspondent à la LBA de début (en hexa little endian), les 4 suivants correspondent à la taille en secteurs (hexa little endian).
Normalement la nouvelle fin est juste avant sdf2
Excuse ma prudence et ne la prends pas pour un manque de confiance en toi, mais sdf2 c'est l'autre partition de données, .
J'ai un moment de panique : C'est bien sdf8 qu'on récupère ? Qui se trouve physiquement avant sdf2.
Que se passe-t-il si tu on "mord" sur sdf2 : accès à sdf8 destructif ? tentative d'accès à sdf2 destructive, ou le risque n'est-il, si on n'accède qu'en lecture, que de ne pas arriver à lire ?
Tant qu'on reste en lecture, la modif est inoffensive et annulable, ou c'est quitte ou double ?
Hors ligne
#12 Le 01/09/2019, à 16:40
- Nasman
Re : Données sur partition "perdue" mais vue par gparted
La manip devrait permettre de récupérer ce qui correspond à sdb5. A priori je ne voit pas en quoi sdf8 différerait en terme d'accès à sdb9.
Dans le chainage tu as les partitions logiques qui se suivent ainsi
Partition étendue (1er ebr) indique la première partition logique sdX5 et la position de l'ebr2
L'ebr2 indique l'emplacement de la deuxième partition logique sdX6 et la position de l'ebr3
L'ebr3 indique l'emplacement de la troisième partition logique sdX7 et la position de l'ebr4
L'ebr4 indique l'emplacement de la quatrième partition logique sdX8 et la position de l'ebr5
L'ebr5 indique l'emplacement de la cinquième partition logique sdX9 et la position de l'ebr6
L'ebr6 indique l'emplacement de la sixième partition logique sdX10 et la position de l'ebr7
L'ebr7 indique l'emplacement de la septième partition logique sdX11 - il n'y a pas de deuxième entrée vue que sdX11 est la dernière partition logique (par ordre de création)
La partition étendue ou les ebr ne sont que des contenants qui doivent avoir une taille englobant les partitions logiques et ebr de numéros supérieurs
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#13 Le 01/09/2019, à 16:50
- Nasman
Re : Données sur partition "perdue" mais vue par gparted
la première entrée, c'est ce qui démarre en 1bf ?
Où commence la chaine à convertir ?
La structure des tables de partitions est la suivante :
début à l'offset 1be et 16 octets par partition.
Le mbr peut contenir 4 entrées, la première de 1be à 1cd, la deuxième de 1ce à 1dd, la troisième de 1de à 1ed et la quatrième de 1ed à 1fd.
Les ebr n'ont que deux entrées, la première correspond à une partition logique et la deuxième à l'ebr suivant
Les 16 octets sont
1be : 00 ou 80 (si flag boot *)
1bf 1c0 1c1 : tête secteur et cylindre (tête codée sur 8 bits, lescteur sur 6 bits, les bits supplémentaires codent les bits 8 et 9 du cylindre)
1c2 : identifiant du système de fichier (83 = extx, 82 linux-swap, 05 = ebr...)
1c3 1c4 1c5 fait de la partition en mode tête secteur et cylindre
1c6 1c7 1c8 1c9 LBA du début de la partition (hexa little endian)
1ca 1cb 1cc 1cd Taille partition (hexa little endian)
Idem pour la deuxième entrée
Ton entrée débute en 1be par un zéro (flag boot désactivé)
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#14 Le 01/09/2019, à 17:06
- Markorki
Re : Données sur partition "perdue" mais vue par gparted
OK, alors comment on modifie cette ligne 1c0 > 1cf ?
Après il me faudra du temps, : brancher mon DD 4To et recopier DATA_3 si je la vois (bon, j'y crois).
Il y a un inconvénient à copier via Caja ? Par cp -a ?
Au fait, comment on procède ? On modifie l'entrée, on démonte et on remonte les partitions concernées ?
Hors ligne
#15 Le 01/09/2019, à 18:10
- Nasman
Re : Données sur partition "perdue" mais vue par gparted
Pour modifier le mbr du (bon) disque il y a plusieurs moyens :
1) Soit en passant par un fichier, par exemple
sudo dd if=/dev/sdf of=~mbr_sdf.bs bs=512 count=1
qui va générer le fichier mbr_sdf.bs dans le dossier utilisateur
Modifier les octets à l'aide d'un éditeur hexa comme ghex
Enregistrer par exemple avec un nom comme mbr_sdf_modif.bs
Réimplanter le nouveau mbr
sudo dd if=~mbr_sdf_modif.bs of=/dev/sdf bs=512 count=1
2) Soit avec un éditeur qui peut travailler directement sur le disque comme hexedit
La première méthode permet de poster le contenu du fichier modifié, par exemple
sudo dd if=~mbr_sdf_modif.bs bs=512 count=1 | hexdump -C
pour vérification avant réimplantation (opération à faire avec prudence, l'erreur comme se tromper de destination n'est pas admise)
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#16 Le 01/09/2019, à 18:52
- Markorki
Re : Données sur partition "perdue" mais vue par gparted
help !
Je ne sais pas ce qui se pase, j'ai lancé d'un terminal "ghex ~mbr_sdf.bs" et modifié la ligne 1c0>1cf , mais il refuse de l'écrire comme ~mbr_sdf_modif.bs , il me répond "Can't open file for writing!".
Or, j'ai les droits dans ce répertoire, je l'ai vérifié par un "touch truc" qui a bien créé un fichier "truc".
Où est-ce que je me trompe ?
Hors ligne
#17 Le 01/09/2019, à 18:56
- Nasman
Re : Données sur partition "perdue" mais vue par gparted
Le fichier est propriété de root (commande en sudo dd...). Il faut changer le nom du fichier après les modifications.
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#18 Le 01/09/2019, à 19:17
- Markorki
Re : Données sur partition "perdue" mais vue par gparted
Bon, je crois avoir réussi la modif du fichier :
marc@PC-4c-AM:~$
marc@PC-4c-AM:~$ sudo dd if=~mbr_sdf_modif.bs bs=512 count=1 | hexdump -C
1+0 enregistrements lus
1+0 enregistrements écrits
00000000 eb 63 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |.c..............|
00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..|
00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u|
512 bytes copied, 8,4708e-05 s, 6,0 MB/s
00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.........|...t..|
00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.....|.........|
00000050 00 00 00 00 00 00 00 00 00 00 00 80 01 00 00 00 |................|
00000060 00 00 00 00 ff fa 90 90 f6 c2 80 75 02 b2 80 ea |...........u....|
00000070 74 7c 00 00 31 c0 8e d8 8e d0 bc 00 20 fb a0 64 |t|..1....... ..d|
00000080 7c 3c ff 74 02 88 c2 52 bb 17 04 80 27 03 74 06 ||<.t...R....'.t.|
00000090 be 88 7d e8 1c 01 be 05 7c f6 c2 80 74 48 b4 41 |..}.....|...tH.A|
000000a0 bb aa 55 cd 13 5a 52 72 3d 81 fb 55 aa 75 37 83 |..U..ZRr=..U.u7.|
000000b0 e1 01 74 32 31 c0 89 44 04 40 88 44 ff 89 44 02 |..t21..D.@.D..D.|
000000c0 c7 04 10 00 66 8b 1e 5c 7c 66 89 5c 08 66 8b 1e |....f..\|f.\.f..|
000000d0 60 7c 66 89 5c 0c c7 44 06 00 70 b4 42 cd 13 72 |`|f.\..D..p.B..r|
000000e0 05 bb 00 70 eb 76 b4 08 cd 13 73 0d f6 c2 80 0f |...p.v....s.....|
000000f0 84 d0 00 be 93 7d e9 82 00 66 0f b6 c6 88 64 ff |.....}...f....d.|
00000100 40 66 89 44 04 0f b6 d1 c1 e2 02 88 e8 88 f4 40 |@f.D...........@|
00000110 89 44 08 0f b6 c2 c0 e8 02 66 89 04 66 a1 60 7c |.D.......f..f.`||
00000120 66 09 c0 75 4e 66 a1 5c 7c 66 31 d2 66 f7 34 88 |f..uNf.\|f1.f.4.|
00000130 d1 31 d2 66 f7 74 04 3b 44 08 7d 37 fe c1 88 c5 |.1.f.t.;D.}7....|
00000140 30 c0 c1 e8 02 08 c1 88 d0 5a 88 c6 bb 00 70 8e |0........Z....p.|
00000150 c3 31 db b8 01 02 cd 13 72 1e 8c c3 60 1e b9 00 |.1......r...`...|
00000160 01 8e db 31 f6 bf 00 80 8e c6 fc f3 a5 1f 61 ff |...1..........a.|
00000170 26 5a 7c be 8e 7d eb 03 be 9d 7d e8 34 00 be a2 |&Z|..}....}.4...|
00000180 7d e8 2e 00 cd 18 eb fe 47 52 55 42 20 00 47 65 |}.......GRUB .Ge|
00000190 6f 6d 00 48 61 72 64 20 44 69 73 6b 00 52 65 61 |om.Hard Disk.Rea|
000001a0 64 00 20 45 72 72 6f 72 0d 0a 00 bb 01 00 b4 0e |d. Error........|
000001b0 cd 10 ac 3c 00 75 f4 c3 b4 c6 0c 00 00 00 80 fe |...<.u..........|
000001c0 ff ff 05 fe ff ff 00 10 00 00 f8 38 80 3e 00 fe |...........8.>..|
000001d0 ff ff 83 fe ff ff f8 48 80 3e c9 2b 60 aa 00 00 |.......H.>.+`...|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200
Je ne serai pas chez moi jusqu'à vendredi soir tard.
Je suppose que tu vas sans doute diner.
Peux tu me confirmer que je suis bon sur la modif, je ferai la suite ce soir ou vendedi soir selon que tu es dispo ce soir ou non.
En tout cas, merci, mon moral remonte.
Hors ligne
#19 Le 01/09/2019, à 21:35
- Nasman
Re : Données sur partition "perdue" mais vue par gparted
A priori les modifications apportées me paraissent correctes.
Si tu as gardé la copie de l'original, tu peux tenter la réimplantation - en vérifiant que le disque de destination est toujours /dev/sdf
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne
#20 Le 07/09/2019, à 23:49
- Markorki
Re : Données sur partition "perdue" mais vue par gparted
Bonjour,
Me revoilà, j'ai fait la modif et vérifié:
sudo dd if=~mbr_sdf_modif.bs of=/dev/sdf bs=512 count=1
Après arrêt et relance du disque, je constate que le bloc est bien modifié :
marc@PC-4c-AM:~$ sudo dd if=/dev/sdf bs=512 count=1 | hexdump -C
1+0 enregistrements lus
1+0 enregistrements écrits
512 bytes copied, 0,000154078 s, 3,3 MB/s
00000000 eb 63 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |.c..............|
00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..|
00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u|
00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.........|...t..|
00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.....|.........|
00000050 00 00 00 00 00 00 00 00 00 00 00 80 01 00 00 00 |................|
00000060 00 00 00 00 ff fa 90 90 f6 c2 80 75 02 b2 80 ea |...........u....|
00000070 74 7c 00 00 31 c0 8e d8 8e d0 bc 00 20 fb a0 64 |t|..1....... ..d|
00000080 7c 3c ff 74 02 88 c2 52 bb 17 04 80 27 03 74 06 ||<.t...R....'.t.|
00000090 be 88 7d e8 1c 01 be 05 7c f6 c2 80 74 48 b4 41 |..}.....|...tH.A|
000000a0 bb aa 55 cd 13 5a 52 72 3d 81 fb 55 aa 75 37 83 |..U..ZRr=..U.u7.|
000000b0 e1 01 74 32 31 c0 89 44 04 40 88 44 ff 89 44 02 |..t21..D.@.D..D.|
000000c0 c7 04 10 00 66 8b 1e 5c 7c 66 89 5c 08 66 8b 1e |....f..\|f.\.f..|
000000d0 60 7c 66 89 5c 0c c7 44 06 00 70 b4 42 cd 13 72 |`|f.\..D..p.B..r|
000000e0 05 bb 00 70 eb 76 b4 08 cd 13 73 0d f6 c2 80 0f |...p.v....s.....|
000000f0 84 d0 00 be 93 7d e9 82 00 66 0f b6 c6 88 64 ff |.....}...f....d.|
00000100 40 66 89 44 04 0f b6 d1 c1 e2 02 88 e8 88 f4 40 |@f.D...........@|
00000110 89 44 08 0f b6 c2 c0 e8 02 66 89 04 66 a1 60 7c |.D.......f..f.`||
00000120 66 09 c0 75 4e 66 a1 5c 7c 66 31 d2 66 f7 34 88 |f..uNf.\|f1.f.4.|
00000130 d1 31 d2 66 f7 74 04 3b 44 08 7d 37 fe c1 88 c5 |.1.f.t.;D.}7....|
00000140 30 c0 c1 e8 02 08 c1 88 d0 5a 88 c6 bb 00 70 8e |0........Z....p.|
00000150 c3 31 db b8 01 02 cd 13 72 1e 8c c3 60 1e b9 00 |.1......r...`...|
00000160 01 8e db 31 f6 bf 00 80 8e c6 fc f3 a5 1f 61 ff |...1..........a.|
00000170 26 5a 7c be 8e 7d eb 03 be 9d 7d e8 34 00 be a2 |&Z|..}....}.4...|
00000180 7d e8 2e 00 cd 18 eb fe 47 52 55 42 20 00 47 65 |}.......GRUB .Ge|
00000190 6f 6d 00 48 61 72 64 20 44 69 73 6b 00 52 65 61 |om.Hard Disk.Rea|
000001a0 64 00 20 45 72 72 6f 72 0d 0a 00 bb 01 00 b4 0e |d. Error........|
000001b0 cd 10 ac 3c 00 75 f4 c3 b4 c6 0c 00 00 00 80 fe |...<.u..........|
000001c0 ff ff 05 fe ff ff 00 10 00 00 f8 38 80 3e 00 fe |...........8.>..|
000001d0 ff ff 83 fe ff ff f8 48 80 3e c9 2b 60 aa 00 00 |.......H.>.+`...|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200
Mais la partition n'apparait toujours pas (sauf en "non alloué")
En lançant gparted, j'ai une boite de message :
Erreur de libparted
Table de partition invalide sur /dev/sdf
- signature erronée bcb5
Il y a un calcul de CRC quielque part ?
Le pb viendrait de (post 3)
la différence entre la ligne sdb1 de décembre et sdf1 actuel (4096 - 20897790)
et de la ligne sdb5 de décembre insérée entre sdb2 et sdb6.
On peut ruser avec la signature ? Ou utiliser un autre outil pour accéder aux données ?
Sinon, il y a ces infos obtenues de gparted :
non alloué 469.14Gio
Système de fichiers : non alloué
Chemin : non alloué
Premier secteur : 64727040
Dernier secteur 1048594679
Secteurs totaux 983867640
Hors ligne
#21 Le 15/09/2019, à 15:40
- Markorki
Re : Données sur partition "perdue" mais vue par gparted
Bon, je ne peux pas mettre "résolu", mais cette façon d'attaquer le pb est visiblement sans issue.
... mais je remercie nasman pour son aide : ça aurait pu marcher, il y avait très peu de modifs sur les partitions entre décembre et Juillet.
Puis-je espérer un peu d'aide pour utiliser ddrescue et/ou photorec sur la partition qui n'est plus vue comme une partition, mais dont les début et fin sont les mêmes que quand elle était reconnue?
J'ai tenté de lire la doc de Gnu ddrescue, mais j'avoue que ça me dépasse : il y a des exemples d'options à utiliser, mais peu d'infos sur les critères pour choisir une option plutôt qu'une autre.
JFaut-il ouvrir un autre fil, ou g ddrescue est à sa place dans "sécurité" ?
Faut-il que le disque cible en cas de création d(image de la partition soit nécessairement interne, ou un disque avec interface USB peut-il convenir ?
Dernière modification par Markorki (Le 15/09/2019, à 18:43)
Hors ligne
Pages : 1