Suppression partition/OS Mac

le retour :

Bloc de code: 
<plist version="1.0">
    <dict>
        <key>fsck_msg_type</key> <string>VERIFY</string>
        <key>fsck_verbosity</key> <integer>0</integer>
        <key>fsck_msg_number</key> <integer>101</integer>
        <key>fsck_msg_string</key> <string>Checking volume.</string>
    </dict>
</plist>
<plist version="1.0">
    <dict>
        <key>fsck_msg_type</key> <string>VERIFY</string>
        <key>fsck_verbosity</key> <integer>0</integer>
        <key>fsck_msg_number</key> <integer>201</integer>
        <key>fsck_msg_string</key> <string>Checking the container superblock.</string>
    </dict>
</plist>
<plist version="1.0">
    <dict>
        <key>fsck_msg_type</key> <string>VERIFY</string>
        <key>fsck_verbosity</key> <integer>0</integer>
        <key>fsck_msg_number</key> <integer>202</integer>
        <key>fsck_msg_string</key> <string>Checking the space manager.</string>
    </dict>
</plist>
<plist version="1.0">
    <dict>
        <key>fsck_msg_type</key> <string>VERIFY</string>
        <key>fsck_verbosity</key> <integer>0</integer>
        <key>fsck_msg_number</key> <integer>203</integer>
        <key>fsck_msg_string</key> <string>Checking the object map.</string>
    </dict>
</plist>
<plist version="1.0">
    <dict>
        <key>fsck_msg_type</key> <string>VERIFY</string>
        <key>fsck_verbosity</key> <integer>0</integer>
        <key>fsck_msg_number</key> <integer>205</integer>
        <key>fsck_msg_string</key> <string>Checking the APFS volume superblock.</string>
    </dict>
</plist>
warning: apfs_sb at apfs_fs_index (0): apfs_features describes new features (18)
error: apfs_sb at apfs_fs_index (0): apfs_incompatible_features has unsupported flags: (0x4)
<plist version="1.0">
    <dict>
        <key>fsck_msg_type</key> <string>ERROR</string>
        <key>fsck_verbosity</key> <integer>0</integer>
        <key>fsck_msg_number</key> <integer>306</integer>
        <key>fsck_msg_string</key> <string>Volume superblock is invalid.</string>
    </dict>
</plist>
<plist version="1.0">
    <dict>
        <key>fsck_msg_type</key> <string>FAIL</string>
        <key>fsck_verbosity</key> <integer>0</integer>
        <key>fsck_msg_number</key> <integer>106</integer>
        <key>fsck_msg_string</key> <string>The volume %1$@ could not be verified completely.</string>
        <key>parameters</key>
        <array>
            <dict><key>volumename</key> <string>/dev/disk1s2</string></dict>
        </array>
    </dict>
</plist>
 
Bon.

- comme il se fait trop tard pour moi à présent --> je te donne rendez-vous demain dans ce même fil.​
 
On obtient la maigre information suivante -->
Bloc de code: 
        <key>fsck_msg_string</key> <string>Checking the APFS volume superblock.</string>
    </dict>
</plist>
warning: apfs_sb at apfs_fs_index (0): apfs_features describes new features (18)
error: apfs_sb at apfs_fs_index (0): apfs_incompatible_features has unsupported flags: (0x4)

  • càd. une vague déclaration formelle d'erreur > alors que ce qui serait attendu est -->
Bloc de code: 
warning: nx_block_count is xxxxxxxx, while device block count is 29444346
Checking the container superblock
error: nx_block_count is xxxxxxxx, while device block count is 29444346

  • qui signifierait : le décompte théorique des blocs assignant la taille valide du Conteneur est : xxxxxxxx => alors que le décompte actuel des blocs mesurant la taille de la partition est 29444346 (blocs octuples du défaut de 512 octets = 120,60 Go). Si une mention chiffrée de ce que j'ai indiqué par mon xxxxxxxx se trouvait affichée => alors on saurait - au bloc près - l'extension que doit avoir la partition apfs --> pour que le système de fichiers soit délivré de l'erreur de taille actuelle et puisse régénérer le Conteneur avec ses volumes montés.

Tu n'auras qu'à refaire signe ici quand tu seras de nouveau disponible.
 
Repasse un :
Bloc de code: 
diskutil list

  • et poste le tableau des disques => que je voie si les index d'appareils sont restés les mêmes.
 
Pas de changement à ce niveau la :

Bloc de code: 
/dev/disk0 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +2.1 GB     disk0
   1:                  Apple_HFS OS X Base System        2.0 GB     disk0s1

/dev/disk1 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         251.0 GB   disk1
   1:                        EFI EFI                     314.6 MB   disk1s1
   2:                 Apple_APFS Container disk18        120.6 GB   disk1s2
   3:       Microsoft Basic Data BOOTCAMP                130.1 GB   disk1s3

/dev/disk2 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +5.2 MB     disk2

/dev/disk3 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk3

/dev/disk4 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk4

/dev/disk5 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk5

/dev/disk6 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk6

/dev/disk7 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk7

/dev/disk8 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk8

/dev/disk9 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +6.3 MB     disk9

/dev/disk10 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk10

/dev/disk11 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +1.0 MB     disk11

/dev/disk12 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk12

/dev/disk13 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk13

/dev/disk14 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk14

/dev/disk15 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +1.0 MB     disk15

/dev/disk16 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +6.3 MB     disk16

/dev/disk17 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk17

/dev/disk18 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +ERROR      disk18
                                 Physical Store disk1s2
 
Passe la commande :
Bloc de code: 
diskutil repairVolume disk18

  • qui instruit une réparation du Conteneur

Poste le retour.

Note : la réparation est bien sûr impossible => mais ce qui est espéré serait toujours l'information sur la taille théorique attendue du Conteneur que la réparation n'aurait pas pu effectuer.
 
Pas trop d'infos encore :

Bloc de code: 
Started file system repair on disk18
Verifying storage system
Checking volume
Checking the container superblock
Checking the space manager
Checking the object map
Checking the APFS volume superblock
The volume /dev/disk18 could not be verified completely
Storage system check exit code is 0
Finished file system repair on disk18
-bash-3.2#
 
Rien à faire.

- alors question : est-ce que tu tiens aux données et à l'installation de ton volume BOOTCAMP ? - un procédé de la dernière chance consisterait à supprimer cette partition > de manière à recréer un descripteur de la partition apfs avec approximativement la taille originelle (autour des 200 Go). Pour voir si l'erreur de taille du Conteneur est supprimée - ou du moins si une information sur la taille exacte attendu est récupérée.​
​
- le problème étant que : rien n'assure du tout qu'une recréation du descripteur de la partition apfs avec une extension de 200 Go ou plus => débloquera en quoi que ce soit la situation du Conteneur apfs et de ses volumes. Auquel cas (dont la probabilité est très élevée) => tu aurais sacrifié le volume BOOTCAMP et sa partition en vain.​

=> qu'est-ce que tu en penses ?
 
Je suis d'accord pour cette solution, je n'ai aucune données de valeur sur mon bootcamp Windows donc le supprimer ne pose aucun problème ! (Si on parle bien de la paritition Windows)
Je suis partant pour essayer ça.
 
Alors passe la commande :
Bloc de code: 
diskutil eraseVolume free null disk1s3

  • la commande supprime la partition du volume BOOTCAMP (130 Go en bas de disque)

Cela fait > passe la commande :
Bloc de code: 
gpt remove -i 2 disk1

  • qui supprime le descripteur GPT de la partition apfs (qu'on a recréé pour la 2è fois)

Enfin passe la commande :
Bloc de code: 
gpt show disk1

  • qui affiche la distribution des blocs résultante pour le disque interne

Poste les retours.
 
Voici les retours après les commandes :

Bloc de code: 
eraseVolume free null disk1s3
Started erase on disk1s3 BOOTCAMP
Unmounting disk
Finished erase on disk1
-bash-3.2# gpt remove -i 2 disk1
disk1s2 removed
-bash-3.2# gpt show disk1
     start      size  index  contents
         0         1         PMBR
         1         1         Pri GPT header
         2         4         Pri GPT table
         6     76800      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     76806  61202533         
  61279339         4         Sec GPT table
  61279343         1         Sec GPT header
-bash-3.2#
 
Cette ligne -->
Bloc de code: 
     76806  61202533

  • montre la situation actuelle : à compter du bloc n° 76806 (1er bloc libre après la partition EFI n°1) > s'étend une bande de 61202533 blocs libres (blocs octuples du défaut de 512 octets = 250.68 Go).
  • on sait que le 1er bloc libre n° 76806 --> est le super-bloc du système de fichiers apfs toujours inscrit sur les blocs : càd. le bloc d'inscription de son header. Ce qui permet à la recréation d'un descripteur de partition prenant ce super-bloc en bloc de départ => au système de fichiers apfs de se trouver instantanément pris en charge par le kernel du Système démarré (OS de secours ici).
  • le problème consiste pour la recréation d'un descripteur GPT de la partition apfs => à assigner une extension valide pour cette partition. Tu disais au début de ce fil :
lbarto a dit:
Mon mac avait à peu près plus de 200 Go pour lui. L'application Bootcamp a automatiquement alloué au début, 24 ou 32 Go il me semble.
Cliquez pour agrandir...

  • est-ce que cette taille de la partition du volume U du tableau de départ du disque -->
Bloc de code: 
   2:       Microsoft Basic Data U                       26.2 GB    disk0s2

  • (26,2 Go) te paraît correspondre à la taille qu'avait la partition BOOTCAMP à la base (avant tes manipulations) ?
 
J'ai quand même encore une question : est-ce que l'Assistant BootCamp avait accepté de créer une aussi petite partition de 26,2 Go et d'y installer Windows ?

- car il me semble que l'Assistant requiert environ 40 Go comme minimum...​
 
Je suis sûr que je devais avoir 42 Go de disponible car j’ai du libérer de l’espace pour installer le bootcamp. J’avais ensuite 42 Go de disponible sur la partition Windows. Donc les 26,2 Go sont sûrement la partition que j’ai créer dans l’utilitaire de disques pour tenter d’agrandir la partition Windows.
 
D'accord -->

- alors est-ce que la partition additionnelle de 26,2 Go => tu l'avais créée à partir de la session de macOS via l'Utilitaire de disque ? - ou depuis la session de Windows ?​
 
D'accord. Alors voici ce qu'on peut envisager en mode spéculatif -->

- la partition de macOS avait été rétrécie canoniquement d'abord d'une partition BOOTCAMP de 42 Go. Puis re-rétrécie canoniquement d'une partition de 26,2 Go. Ces 2 repartitionnements effectués donc de manière canonique (par adressage au système de fichiers apfs de la partition macOS donneuse). Partition qui était valide en taille après cette double amputation de 68,2 Go.​
​
- la partition de 26,2 Go > on sait d'après le tableau de la distribution des blocs de départ qu'elle avait une extension exacte de 6397440 blocs (blocs octuples du défaut = 4096 octets). Une partition de 42 Go équivaut à 10253906 blocs octuples de 4096 octets (mesure spéculative ici - rien n'indiquant qu'il s'agissait exactement de 42 Go pile et donc de la taille en blocs correspondante).​
​
- une carte des blocs en blocs octuples de 4096 octets (imposée par l'apfs) => ménage des tampons d'espace libre de 32768 blocs (de 4096 octets = 134.21 Mo) entre les partitions. Et il n'existe plus de tampon d'espace libre entre la fin de la dernière partition et le départ de la GPT secondaire de queue de disque (comme avec les distributions en blocs défaut de 512 octets => où il y avait toujours un tampon de 7 blocs libres).​
​
- ces computations d'apothicaire conduisent à ceci : l'espace libre total actuel (entre la partition EFI et le départ de la GPT secondaire) est de 61202533 blocs de 4096 octets. Il faut leur soustraire 6397440 blocs de la partition de 26,2 Go créée en second + 10253906 blocs de la partition BOOTCAMP de 42 Go créée en premier (mesure spéculative) + 32768 blocs tampon entre la partition apfs et la partition de 26,1 Go + 32768 blocs tampon entre la partition de 26,2 Go et la partition BOOTCAMP. Ce qui donne un total de : 16716882 blocs de 4096 octets. 61202533 blocs d'espace libre total - 16716882 blocs occupés par les partitions et les tampons => 44485651 blocs de 4096 octets pour le dernier état de la partition apfs valide. Soit 182.21 Go pour cette partition apfs.​

=> on peut donc envisager spéculativement de recréer un descripteur GPT de partition apfs > avec une extension de 44485651 blocs de 4096 octets = 182.21 Go. D'accord ?
 
Comme les tailles des partitions ont toujours un nombre de blocs pair (et jamais impair) --> on va transformer les 44485651 blocs d'extension spéculative en 44485650 blocs.

- donc passe la commande (copier-coller à rebours) :​
Bloc de code: 
gpt add -b 76806 -s 44485650 -t 7C3457EF-0000-11AA-AA11-00306543ECAC -i 2 disk1

  • qui recrée un descripteur GPT de partition telle que : bloc de tête = n° 76806 > extension = 44485650 (blocs de 4096 octets = 182.21 Go) > type = "Apple_APFS" (via son UUID de type = 7C3457EF-0000-11AA-AA11-00306543ECAC) > rang = 2

Poste le retour.
 

Sujets similaires

16bol
Problème d’accès à ma partition mac os
Réponses
1
Affichages
250
Windows sur Mac
Ahiqar
A
D
macOS Sonoma L'espace utilisé de mac HD augmente sans raison
Réponses
35
Affichages
2K
macOS
Dadprod38
D
S
10.15 Catalina Mise à jour Mac Book Pro 15" mi-2012
Réponses
52
Affichages
5K
macOS
pascrep
P
M
10.13 High Sierra PB Installation macOS
Réponses
9
Affichages
2K
macOS
Linda1
L
J
10.13 High Sierra Suppression Boot Camp par erreur - Monterrey
Réponses
2
Affichages
997
macOS
ericse
ericse
Haut Bas