10.13 High Sierra How to fix my corrupted APFS container?
- Créateur du sujet Rainyday
- Date de début
Appreciate it, my friend. You've done an amazing job so far. You are the best! See you tomorrow again..
I'll do my best to take a dd clone as soon as possible in order to be completely ready for your interesting Plan B!
Sorry for some inexplicable reasons I'd rather not say that but surely somewhere far away from France and Eiffel tower!
Sorry for some inexplicable reasons I'd rather not say that but surely somewhere far away from France and Eiffel tower!
I can read Cupertino, CA between these lines...
It's a test, Maco'!
M
Membre supprimé 1060554
Invité
- la source du clonage ici est une partition de disque : la partition /dev/disk0s2 -->
Bloc de code:
/dev/disk0 (internal):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 250.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk2 249.8 GB disk0s2- cette partition "source" a une capacité de 249,8 Go = 487987488 blocs de 512-octets.
La destination du clonage via dd doit être alors une partition de disque > partition d'une capacité au moins égale à 249,8 Go (487987488 blocs) > mais pouvant être supérieure. À supposer la partition de destination d'une plus grande capacité (contenir davantage de blocs) --> alors tous les blocs dans la partition de destination au-delà de la quantité de blocs de la source => seront neutralisés en tant qu'« espace allouable ». Cela veut dire qu'en finalisation de la copie de dd > ces blocs excédentaires seront marqués par des x > ce qui les transformera en « null blocks » en ce qui concerne le gestionnaire de l'espace de la partition = le système de fichiers (filesystem). Par contre > du point de vue de la table de partition (GPT) --> l'espace d'extension de la partition aura toujours la capacité (nombre de blocs) primitive. Bref : étant donné une partition de destination /dev/disk1s2 (supposition en ce qui concerne l'index du device) > d'une capacité de 350 Go = 683593750 blocs (de 512-octets) --> le conteneur de la partition aura toujours une capacité de 683593750 blocs à la sortie du clonage (description par la GPT). Mais le système de fichiers interne à la partition (headers inscrits sur les blocs de départ de la partition) --> ne recensera que 487987488 blocs comme "espace indexable" > les 195606261 blocs excédentaires étant neutralisés comme « null blocks ».
M
Membre supprimé 1060554
Invité
dd (data_doubler) est un programme exécutant non pas une copie de fichiers (file_copy) > mais une copie de blocs (block_copy) --> tous les blocs contenus du n°409640 au n°488397128 dans la partition "source" => seront clonés en mode identique dans la partition "destination" > du n°409640 au n° 488397128. Ce qui signifie que dd clone les headers de systèmes de fichiers incrits sur les blocs de tête de la partition "source" => sur les blocs de tête correspondants de la partition de destination. Il va donc cloner en mode exact les headers du système de fichiers apfs de la partition /dev/disk0s2 => sur autant de blocs symétriques de la partition de destination (disk1s2 dans mon exemple). La corruption du système de fichiers apfs de la source = sera exportée exactement en corruption du système de fichiers cloné sur la destination. Une partition est comme un "conteneur logique" (un contenant) qui va chez toi d'un bloc n°409640 à un bloc n° 488397128 (pour une extension de 487987488 blocs). Tout est cloné dans le conteneur de destination > à partir de son 1er bloc. Càd. remplacé ou substitué en terme d'écritures. Si un système de fichiers fat32 existe sur les blocs de tête de la partition de destination > il va être substitué par les headers du système de fichiers apfs de la source. Tout le contenu est remplacé > gestionnaire de la partition compris (en résumé).
Mais une partition (un conteneur de blocs) a un type logique > indexé par un hex code équivalant à un UUID universel dans le descripteur correspondant de la table GPT. L'UUID du type de partition "Apple_APFS" est 7C3457EF-0000-11AA-AA11-00306543ECAC > le hex code : af0a. Le type de partition est donc un index qui n'existe pas sur les blocs de la partition > mais qui fait partie de la description de la partition dans la table GPT (localisée sur les 33 premiers blocs du disque). Un descripteur dans la table GPT > est ce qui permet l'adressage de la partition : soit par le programme de boot du Mac (EFI) > soit par le noyau opératoire du Système démarré (kernel). C'est le kernel qui monte les volumes sur les partitions > par la prise en charge des systèmes de fichiers inscrits sur leurs en-têtes. On admet donc que le kernel lit les descripteurs des partitions dans la table GPT. Il lit donc les index de types de partitions qui font partie des descripteurs. Le type d'une partition définit la classe de systèmes de fichiers compatibles pouvant être trouvés dans le conteneur de la partition. Ainsi, le type Af0a (UUID = 7C3457EF-0000-11AA-AA11-00306543ECAC ou "Apple_APFS") > définit la classe des système de fichiers compatibles : apfs > apfs sensible à la casse > apfs chiffré > apfs sensible à la casse chiffré. Et aucun autre. Si une partition a un type logique qui ne correspond pas au système de fichiers contenu (exemple : type "Apple_APFS" vs système de fichiers exFAT) => alors le kernel rejette la prise en charge du système de fichiers comme incompatible avec le type de la partition : aucun volume n'est alors monté.
Mais une partition (un conteneur de blocs) a un type logique > indexé par un hex code équivalant à un UUID universel dans le descripteur correspondant de la table GPT. L'UUID du type de partition "Apple_APFS" est 7C3457EF-0000-11AA-AA11-00306543ECAC > le hex code : af0a. Le type de partition est donc un index qui n'existe pas sur les blocs de la partition > mais qui fait partie de la description de la partition dans la table GPT (localisée sur les 33 premiers blocs du disque). Un descripteur dans la table GPT > est ce qui permet l'adressage de la partition : soit par le programme de boot du Mac (EFI) > soit par le noyau opératoire du Système démarré (kernel). C'est le kernel qui monte les volumes sur les partitions > par la prise en charge des systèmes de fichiers inscrits sur leurs en-têtes. On admet donc que le kernel lit les descripteurs des partitions dans la table GPT. Il lit donc les index de types de partitions qui font partie des descripteurs. Le type d'une partition définit la classe de systèmes de fichiers compatibles pouvant être trouvés dans le conteneur de la partition. Ainsi, le type Af0a (UUID = 7C3457EF-0000-11AA-AA11-00306543ECAC ou "Apple_APFS") > définit la classe des système de fichiers compatibles : apfs > apfs sensible à la casse > apfs chiffré > apfs sensible à la casse chiffré. Et aucun autre. Si une partition a un type logique qui ne correspond pas au système de fichiers contenu (exemple : type "Apple_APFS" vs système de fichiers exFAT) => alors le kernel rejette la prise en charge du système de fichiers comme incompatible avec le type de la partition : aucun volume n'est alors monté.
Dernière édition par un modérateur:
M
Membre supprimé 1060554
Invité
Si ta partition de destination est de type "Microsoft Basic Data" (hex code : 0700) > pour une capacité de blocs au moins égale à ceux de la source > alors dd clonera dans le conteneur de la partition les 487987488 blocs de la source > avec donc un header constitué par un système de fichiers apfs corrompu. Mais il ne changera pas le type de la partition qui restera 0700 dans la table GPT. En conséquence > le kernel du Système démarré rejettera toute reconnaissance du système de fichiers apfs cloné (qu'il soit intègre ou corrompu) comme incompatible avec le type de la partition. Il faut donc veiller soigneusement à ce que le type de la partition de destination soit identique au type de la partition source > sinon il faut après coup restaurer le type de la partition de destination à l'identique de celui de la source (càd écrire à la table GPT du disque de destination). Ce qui est toujours une opération sophistiquée. Si tu m'as suivi > tu auras compris que le type de la partition source chez toi étant af0a (UUID = 7C3457EF-0000-11AA-AA11-00306543ECAC ou Apple_APFS) > le plus simple est que le type de la partition de destination (disk1s2 dans mon exemple) soit lui aussi af0a (UUID = 7C3457EF-0000-11AA-AA11-00306543ECAC ou Apple_APFS).
Imagine donc que tu aies le tableau suivant :
Imagine donc que tu aies le tableau suivant :
Bloc de code:
/dev/disk0 (internal):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 250.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk2 249.8 GB disk0s2
/dev/disk1 (external):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 500.1 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_APFS Container disk5 350.0 GB disk1s2
3: Apple_HFS Brol 149.8 GB disk1s3- la commande tu as à passer est du type :
Bloc de code:
sudo dd if=/dev/rdisk0s2 of=/dev/rdisk1s2 bs=4096 conv=noerror,notrunc- aucun volume dépendant de la partition source ou destination ne devant être monté. La commande dd est mutique. Pour une grande quantité de données à cloner > passe d'abord une commande de type :
Bloc de code:
caffeinate -dimsu &- qui lance un processus caffeinate empêchant le Mac de dormir > et le renvoyant en arrière plan pour redonner l'invite de commande et permettre d'exécuter une opération en avant-plan.
Dernière édition par un modérateur:
(When too many people reply on a subject, it may become hard to read and inefficient, so I stepped down.)
Note that dd may also copy data towards a file on any partition allowing large size files (in your case: ExFAT, NTFS, ext4, APFS etc.) It's rather practical when you have enough room on a drive, since you avoid repartition it.
That would be :
Bloc de code:
sudo dd if=/dev/rdisk0s2 of=dd_disk0s2.bkp bs=1M
Bloc de code:
sudo dd if=/dev/rdisk0s2 bs=1M | gzip -c > dd_disk0s2.bkp.gzThe actual path of the backup is up to you, depending on the available space.
I forgot to mention that, to revert the content of the file to a disk slice, it's simply the same command, with of and if inverted.
Hence, if you copy back onto the same disk slice :
Obviously, the slice has to be unmounted.
By the way, the notrunc option is useless.
Hence, if you copy back onto the same disk slice :
Bloc de code:
sudo dd if=dd_disk0s2.bkp of=/dev/rdisk0s2 bs=1MBy the way, the notrunc option is useless.
Thank you bompi & macomaniac. You're gorgeous guys!
Very precise well-structured long answers in a meticulous details. Really appreciate it. MerC!
Last night, I asked someone on IRC freenode ##linux and he kindly gave me exactly this command (.img/.bkp as a FILE for destination path). Combined all three and now it's in progress.
----------------------------------------------
An app called iBoysoft (known as APFS Data Recovery on MacAppStore) can easily find those 4 partitions (takes only 4sec to find them all!!) even with their correct names (macSSD was my chosen name for the system partition). It's amazing how that app can find the names of lost partitions!
So what I'm going to say is the UUID and actually block part of each lost partition are still exist and we should be able to find them somehow and redefine them for the corresponding APFS container.
A unique answer which I found an AskDifferent. Need your help to check it out whether it's helpful in my case or not :
https://apple.stackexchange.com/questions/318082/how-can-i-fix-my-partition-table
The author of the answer, klanomath, reminds me macomaniac in term of precise long detailed answers!
Very precise well-structured long answers in a meticulous details. Really appreciate it. MerC!
Last night, I asked someone on IRC freenode ##linux and he kindly gave me exactly this command (.img/.bkp as a FILE for destination path). Combined all three and now it's in progress.
----------------------------------------------
An app called iBoysoft (known as APFS Data Recovery on MacAppStore) can easily find those 4 partitions (takes only 4sec to find them all!!) even with their correct names (macSSD was my chosen name for the system partition). It's amazing how that app can find the names of lost partitions!
So what I'm going to say is the UUID and actually block part of each lost partition are still exist and we should be able to find them somehow and redefine them for the corresponding APFS container.
A unique answer which I found an AskDifferent. Need your help to check it out whether it's helpful in my case or not :
https://apple.stackexchange.com/questions/318082/how-can-i-fix-my-partition-table
The author of the answer, klanomath, reminds me macomaniac in term of precise long detailed answers!
Dernière édition:
Link to my own question on AskDifferent :
https://apple.stackexchange.com/questions/336223/how-to-fix-my-corrupted-apfs-container
https://apple.stackexchange.com/questions/336223/how-to-fix-my-corrupted-apfs-container
Really nice post indeed.
I guess it can help when the GUID partition table is wrong while the data remain untouched and consistant. All commands are at the GPT level with the gpt command.
My understanding is your issues are at APFS level : it's the APFS container map one needs to rebuild. So, I'm afraid it won't help much.
We should pay a visit to Apple developer site and its APFS documentation [I still don't have any APFS container to play with].
M
Membre supprimé 1060554
Invité
RainydayMon plan B en ce qui te concerne est exactement la même manipulation que décrit klanomath à la fin de son intervention -->
- supprimer le descripteur de la partition n°2 du SSD > puis recréer ce descripteur exactement par une commande de la forme qu'il donne. Cette opération > si l'on passe des commandes adéquates > est absolument sûre et sans problème.
À la différence du cas de figure qu'il traite > il n'y a aucun besoin chez toi de se lancer dans des calculs pour déterminer le nombre de blocs à allouer comme extension à la partition apfs à recréer. Car le tableau des blocs que tu as donné montre ceci -->
Bloc de code:
409640 487987488 2 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC- il est donc certain a priori que la partition apfs démarre au bloc n° 409640 du SDD > et a une extension de 487987488 blocs (de 512 octets) > ce qui la fait se terminer au bloc 488397127 inclus (car il faut inclure le bloc n° 409640 comme n° 1 de l'extension des 487987488 blocs de la partition > et pas ajouter les 487987488 blocs au bloc n° 409640.
Ces certitudes de base font que les 2 commandes dans ton cas sont :
Bloc de code:
sudo gpt remove -i 2 /dev/disk0
sudo gpt add -b 409640 -s 487987488 -t 7C3457EF-0000-11AA-AA11-00306543ECAC -i 2 /dev/disk0----------
Comme je l'avais souligné antérieurement > cette opération de suppression / recréation d'un descripteur dans la table GPT --> n'a dans mon esprit qu'un enjeu tout à fait ténu : vérifier si > à la recréation du conteneur de la partition apfs > le système de fichiers apfs toujours inscrit sur les blocs du disque à partir du n° 409640 => ne se "remettrait pas en place" avec sa réactivation consécutive à la redéfinition exacte du conteneur de la partition disk0s2. C'est miser sur un effet de chance tout à fait infime > mais pourquoi pas puisque l'opération est sûre ?
Cependant je dois t'avouer que je n'y crois pas moi-même. Car mon examen précédent de l'affichage retourné par la vérification --> m'a paru montrer que les composants du "tronc commun" du système de fichiers apfs comportent des erreurs invalidantes. On a donc affaire à un problème interne au système de fichiers apfs > et pas à une question de description de la partition apfs dans la GPT du disque. Je m'accorde donc entièrement avec bompi à ce sujet.
Mon plan B en ce qui te concerne est exactement la même manipulation que décrit klanomath à la fin de son intervention -->
- supprimer le descripteur de la partition n°2 du SSD > puis recréer ce descripteur exactement par une commande de la forme qu'il donne. Cette opération > si l'on passe des commandes adéquates > est absolument sûre et sans problème.
À la différence du cas de figure qu'il traite > il n'y a aucun besoin chez toi de se lancer dans des calculs pour déterminer le nombre de blocs à allouer comme extension à la partition apfs à recréer. Car le tableau des blocs que tu as donné montre ceci -->
Bloc de code:409640 487987488 2 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
- il est donc certain a priori que la partition apfs démarre au bloc n° 409640 du SDD > et a une extension de 487987488 blocs (de 512 octets) > ce qui la fait se terminer au bloc 488397127 inclus (car il faut inclure le bloc n° 409640 comme n° 1 de l'extension des 487987488 blocs de la partition > et pas ajouter les 487987488 blocs au bloc n° 409640.
Ces certitudes de base font que les 2 commandes dans ton cas sont :
Bloc de code:sudo gpt remove -i 2 /dev/disk0 sudo gpt add -b 409640 -s 487987488 -t 7C3457EF-0000-11AA-AA11-00306543ECAC -i 2 /dev/disk0
----------
Comme je l'avais souligné antérieurement > cette opération de suppression / recréation d'un descripteur dans la table GPT --> n'a dans mon esprit qu'un enjeu tout à fait ténu : vérifier si > à la recréation du conteneur de la partition apfs > le système de fichiers apfs toujours inscrit sur les blocs du disque à partir du n° 409640 => ne se "remettrait pas en place" avec sa réactivation consécutive à la redéfinition exacte du conteneur de la partition disk0s2. C'est miser sur un effet de chance tout à fait infime > mais pourquoi pas puisque l'opération est sûre ?
Cependant je dois t'avouer que je n'y crois pas moi-même. Car mon examen précédent de l'affichage retourné par la vérification --> m'a paru montrer que les composants du "tronc commun" du système de fichiers apfs comportent des erreurs invalidantes. On a donc affaire à un problème interne au système de fichiers apfs > et pas à une question de description de la partition apfs dans la GPT du disque. Je m'accorde donc entièrement avec bompi à ce sujet.
Hi my man!
Bloc de code:
Last login: Thu Sep 13 10:15:34 on console
RainyHighSierras-MacBook-Pro:~ rainyhighsierra$ sudo gpt remove -i 2 /dev/disk0
Password:
/dev/disk0s2 removed
RainyHighSierras-MacBook-Pro:~ rainyhighsierra$ sudo gpt add -b 409640 -s 487987488 -t 7C3457EF-0000-11AA-AA11-00306543ECAC -i 2 /dev/disk0
/dev/disk0s2 added
RainyHighSierras-MacBook-Pro:~ rainyhighsierra$What shall I do then? Tried First Aid on disk0s2 but still same errors.
M
Membre supprimé 1060554
Invité
Je vois qu'il n'y a rien eu de changé, alors. C'était prévisible.
Je ne dispose pas d'outils qui permettraient de réparer les erreurs de l'apfs. Je ne sais pas s'il en existe.
À part la récupération de données que tu as effectuée > ou essayer d'en récupérer encore d'autres --> je ne vois rien de mieux.
Je ne dispose pas d'outils qui permettraient de réparer les erreurs de l'apfs. Je ne sais pas s'il en existe.
À part la récupération de données que tu as effectuée > ou essayer d'en récupérer encore d'autres --> je ne vois rien de mieux.
bompi & macomaniac
3 apps which particularly claim to be able to find lost partitions:
iBoysoft => https://i.imgur.com/G9Y2Oc9.jpg & https://i.imgur.com/qyPlWnI.jpg ==> Justifiably claims that can FIND lost partition and recover data, not repairing (restoring) them
TestDisk (Quick Scan) => https://i.imgur.com/B7Qaahi.jpg ==> I already knew it doesn't support APFS. Useless?
reclaime => https://www.reclaime.com/default.aspx ==> Need a Windows machine and possibly have to plug the SSD instead of ODD using a caddy. Didn't try it yet. What do think of it?
Know more?
3 apps which particularly claim to be able to find lost partitions:
iBoysoft => https://i.imgur.com/G9Y2Oc9.jpg & https://i.imgur.com/qyPlWnI.jpg ==> Justifiably claims that can FIND lost partition and recover data, not repairing (restoring) them
TestDisk (Quick Scan) => https://i.imgur.com/B7Qaahi.jpg ==> I already knew it doesn't support APFS. Useless?
reclaime => https://www.reclaime.com/default.aspx ==> Need a Windows machine and possibly have to plug the SSD instead of ODD using a caddy. Didn't try it yet. What do think of it?
Know more?
M
Membre supprimé 1060554
Invité
@ Rainyday
Comme Justain te le suggère > tu peux sortir ton SSD du Mac > le mettre dans un boîtier SATA <=> USB pour disque 2,5" > et vérifier si le système de fichiers apfs se montre toujours aussi corrompu. L'hypothèse qu'il pourrait s'agir d'erreurs dans la transmission des données du disque à la carte-mère (I/O errors) --> mérite d'être explorée.
----------
Les logiciels de récupération de données (comme iBoysoft ou reclaime) --> ne sont pas des logiciels de réparation de systèmes de fichiers. Il peuvent retrouver des fichiers > pas corriger des erreurs de l'apfs.
Comme Justain te le suggère > tu peux sortir ton SSD du Mac > le mettre dans un boîtier SATA <=> USB pour disque 2,5" > et vérifier si le système de fichiers apfs se montre toujours aussi corrompu. L'hypothèse qu'il pourrait s'agir d'erreurs dans la transmission des données du disque à la carte-mère (I/O errors) --> mérite d'être explorée.
----------
Les logiciels de récupération de données (comme iBoysoft ou reclaime) --> ne sont pas des logiciels de réparation de systèmes de fichiers. Il peuvent retrouver des fichiers > pas corriger des erreurs de l'apfs.
- je ne sais pas si TestDisk est capable de réparer une partition apfs.
- je ne sais pas si TechTool Pro est capable de réparer une partition apfs.
- en ce qui concerne DiskWarrior (extrait de la documentation) -->
Bloc de code:
Apple File System (APFS) disks are recognized by DiskWarrior 5.1 but are not able to be rebuilt.
• What's in the works
The next major release of DiskWarrior will include the ability to rebuild APFS disks.
Our developers are waiting for Apple to release the final APFS format documentation
in order to safely rebuild APFS disks.- il me semble clair que c'est ta meilleure chance > mais il te faut attendre la prochaine mise à jour majeure du logiciel qui prendra en charge la reconstruction de l'apfs.
The SSD is a master-password enabled one!
firmware+user
So I've tried a lot but Windows machine can't detect it and initial using it due to the bios password protection (Disk Management is not responding as soon as connect the USB cable!)
That's why I swiped SSD and HDD internally instead of using the BOX.
Unfortunately using another SATA port didn't solve the problem. So I concluded it comes back to corrupted fs rather than a damaged sata cable, unlike your case..
As said before it's not possible to plug in the drive externally due to the bios password protection.
Yeah.. I've already knew the one and only, the powerful tool of the field, (DiskWorrier) gonna support APFS rebuilding in the next major update. They have been waiting for apple to release APFS documentation more than a year and I don't think that happens any time soon. Seems like it'd be the only easy solution as of now.
macomaniac
The following command adds a new volume to the container. Possible to add a NAME to newly created volume?
The following command adds a new volume to the container. Possible to add a NAME to newly created volume?
Bloc de code:
sudo gpt add -b 409640 -s 487987488 -t 7C3457EF-0000-11AA-AA11-00306543ECAC -i 2 /dev/disk0Sujets similaires
- Membre supprimé 1171291
- Accessoires Mac
10.14 Mojave
Supprimer les snapshot sur disque de User
10.13 High Sierra
Installer High Sierra sur SSD sans conversion APFS
- Deleted member 1099514
- macOS