Stockage Problèmes rencontrés sur la carte de partition risquant d'empêcher le démarrage.

  • Créateur du sujet Créateur du sujet Membre supprimé 1198363
  • Date de début Date de début
Ce n'est pas du tout cohérent avec le GPT, qui lui montre bien deux partitions, avec un espace vide de 2008 caractères entre les deux.

fdisk quant à lui ne voit qu'une partition, de type inconnu, qui commence à la position 1. Je ne comprends pas.

Essaie de réparer en mode récupération, comme je le suggérais plus haut. Et fais aussi un SOS sur le volume Seagate lui-même.
 
sinbad21 a dit:
Ce n'est pas du tout cohérent avec le GPT, qui lui montre bien deux partitions, avec un espace vide de 2008 caractères entre les deux.

fdisk quant à lui ne voit qu'une partition, de type inconnu, qui commence à la position 1. Je ne comprends pas.

Essaie de réparer en mode récupération, comme je le suggérais plus haut. Et fais aussi un SOS sur le volume Seagate lui-même.
Cliquez pour agrandir...
Moi non plus, je ne comprends pas :(
Pour réparer en mode récupération, je les ai faits et aussi un SOS sur le volume, mais ça ne marche toujours pas :(
 
J'ai l'impression que fdisk est perdu avec la combinaison GUID / exfat. J'ai formaté une clé usb de 16Go avec cette combinaison et j'obtiens le même résultat que toi (sauf les tailles bien sûr), à la fois avec GPT et avec fdisk. Mais chez moi le SOS ne trouve aucune anomalie. Le problème viendrait-il des 5 To ?

Bloc de code: 
sudo gpt show disk4
     start      size  index  contents
         0         1         PMBR
         1         1         Pri GPT header
         2        32         Pri GPT table
        34         6         
        40    409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
    409640      2008         
    411648  31289344      2  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  31700992      2015         
  31703007        32         Sec GPT table
  31703039         1         Sec GPT header

Bloc de code: 
fdisk /dev/disk4
Disk: /dev/disk4    geometry: 1973/255/63 [31703040 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -   31703039] <Unknown ID>
 2: 00    0   0   0 -    0   0   0 [         0 -          0] unused     
 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused     
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused
 
sinbad21 a dit:
J'ai l'impression que fdisk est perdu avec la combinaison GUID / exfat. J'ai formaté une clé usb de 16Go avec cette combinaison et j'obtiens le même résultat que toi (sauf les tailles bien sûr), à la fois avec GPT et avec fdisk. Mais chez moi le SOS ne trouve aucune anomalie. Le problème viendrait-il des 5 To ?

Bloc de code: 
sudo gpt show disk4
     start      size  index  contents
         0         1         PMBR
         1         1         Pri GPT header
         2        32         Pri GPT table
        34         6       
        40    409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
    409640      2008       
    411648  31289344      2  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  31700992      2015       
  31703007        32         Sec GPT table
  31703039         1         Sec GPT header

Bloc de code: 
fdisk /dev/disk4
Disk: /dev/disk4    geometry: 1973/255/63 [31703040 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -   31703039] <Unknown ID>
 2: 00    0   0   0 -    0   0   0 [         0 -          0] unused   
 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused   
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused
Cliquez pour agrandir...
Tu voudrais dire que ça serait mon disque dur externe qui ne marcherait pas très bien ?
Il faudrait alors le changer ?
 
Non, je pense plutôt à une limite de taille de disque dur avec le exfat. Je ne connais pas bien ce format, mais je sais que le fat32 ne sait pas gérer ces très gros volumes.

Si tu arrives à lire et à des écrire des fichiers sur ce disque il n'y a pas de problème a priori. Cet après-midi je vais tenter des manips avec ma clé usb, en modifiant dans fdisk la table de partitions telle qu'elle devrait être. Je te tiendrai au courant des résultats.
 
sinbad21 a dit:
Non, je pense plutôt à une limite de taille de disque dur avec le exfat. Je ne connais pas bien ce format, mais je sais que le fat32 ne sait pas gérer ces très gros volumes.

Si tu arrives à lire et à des écrire des fichiers sur ce disque il n'y a pas de problème a priori. Cet après-midi je vais tenter des manips avec ma clé usb, en modifiant dans fdisk la table de partitions telle qu'elle devrait être. Je te tiendrai au courant des résultats.
Cliquez pour agrandir...
D'accord merci pour ton aide :)
 
J'ai testé avec un autre disque dur externe SSD que j'ai branché à la Livebox, je l'ai formaté en ExFAT (MBR) puis en ExFAT (GUID) et impossible de voir les données en réseau que je suis sur l'ordinateur ou bien sur le décodeur Orange.
Par contre, ça marche si je le formate en FAT32 (MBR).
Je ne comprends pas !
 

Fichiers joints

  • Capture d’écran 2023-04-04 à 12.58.53.png
    Capture d’écran 2023-04-04 à 12.58.53.png
    23,5 KB · Affichages: 25
C'est comme si Utilitaire de disque ne partitionnait pas correctement pour le couple GUID / exfat.

J'ai testé ma clé usb en modifiant la table de partitions uniquement dans fdisk, ça donne ceci :
Bloc de code: 
sudo fdisk /dev/disk2   
Disk: /dev/disk2    geometry: 1973/255/63 [31703040 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE    0   0   2 - 1023 254  63 [         1 -     411647] <Unknown ID>
 2: 0C 1023 254  63 - 1023 254  63 [    411648 -   31291392] Win95 FAT32L
 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused     
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused
Ça ne change rien dans GPT, et le SOS dans Utilitaire de disque ne râle pas. C'est comme s'il y avait une table de partition pour macOS, et une pour Windows.

Si tu es d'accord on peut tenter la même manip sur ton dd externe. Peut-être que ça règlera ton problème, ou pas.
 
sinbad21 a dit:
C'est comme si Utilitaire de disque ne partitionnait pas correctement pour le couple GUID / exfat.

J'ai testé ma clé usb en modifiant la table de partitions uniquement dans fdisk, ça donne ceci :
Bloc de code: 
sudo fdisk /dev/disk2  
Disk: /dev/disk2    geometry: 1973/255/63 [31703040 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE    0   0   2 - 1023 254  63 [         1 -     411647] <Unknown ID>
 2: 0C 1023 254  63 - 1023 254  63 [    411648 -   31291392] Win95 FAT32L
 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused    
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused
Ça ne change rien dans GPT, et le SOS dans Utilitaire de disque ne râle pas. C'est comme s'il y avait une table de partition pour macOS, et une pour Windows.

Si tu es d'accord on peut tenter la même manip sur ton dd externe. Peut-être que ça règlera ton problème, ou pas.
Cliquez pour agrandir...
Oui, je serai d'accord si ça ne supprime pas les données du disque :)
 
Non, en aucun cas. Les utilitaires GPT et fdisk ne touchent qu'à la table de partitions, pas aux données du disque. Ce qui peut arriver, c'est qu'une mauvaise correction fasse que le volume n'est plus accessible, mais c'est réversible, il suffit de remettre les valeurs initiales pour se retrouver au point de départ.

Donc ce qu'on va faire, c'est éditer dans fdisk les items 1 et 2, pour mettre les mêmes valeurs qu'avec GPT. On va donc lancer fdisk en mode édition, vérifie auparavant que le disque est toujours le disk10, sinon change avec la bonne valeur :
Bloc de code: 
sudo fdisk -e /dev/disk10
 
sinbad21 a dit:
Non, en aucun cas. Les utilitaires GPT et fdisk ne touchent qu'à la table de partitions, pas aux données du disque. Ce qui peut arriver, c'est qu'une mauvaise correction fasse que le volume n'est plus accessible, mais c'est réversible, il suffit de remettre les valeurs initiales pour se retrouver au point de départ.

Donc ce qu'on va faire, c'est éditer dans fdisk les items 1 et 2, pour mettre les mêmes valeurs qu'avec GPT. On va donc lancer fdisk en mode édition, vérifie auparavant que le disque est toujours le disk10, sinon change avec la bonne valeur :
Bloc de code: 
sudo fdisk -e /dev/disk10
Cliquez pour agrandir...
Ok, voici :
Last login: Tue Apr 4 18:19:24 on console
ludvic@iMac-de-Ludvic ~ % sudo fdisk -e /dev/disk10
Password:
fdisk: could not open MBR file /usr/standalone/i386/boot0: No such file or directory
Enter 'help' for information
fdisk: 1>
Cliquez pour agrandir...
 
La deuxième valeur entre crochets [EE] est la valeur actuelle, on ne va pas la changer. Fais enter une fois et poste le retour.
 

Sujets similaires

M
Partition SSD Time Machine devenue inaccessible
Réponses
6
Affichages
1K
Accessoires Mac
Bicus
Bicus
LeTux
10.8 Mountain Lion SSD partitions corrompu, réparable ?
Réponses
3
Affichages
335
macOS
LeTux
LeTux
Cric
Installation et partition d'un SSD sous MacOS Monterey
Réponses
5
Affichages
458
macOS
Cric
Cric
H
iMac problème de disque externe en lecture ecriture
Réponses
10
Affichages
2K
Accessoires Mac
Membre supprimé 1060554
M
CatFauve
iMac Après la màj, plus moyen de démarrer sur le disque externe
Réponses
9
Affichages
1K
Accessoires Mac
Sly54
Sly54
Haut Bas