Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#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

Nasman a écrit :

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

Markorki a écrit :

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