Impossible de booter sur OSX

[ogee]

L'UUID : 48465300-0000-11AA-AA11-00306543ECAC est par convention le désignateur universel du type de partition : "Apple_HFS".

- c'est l'UUID : 7C3457EF-0000-11AA-AA11-00306543ECAC qui est le désignateur universel du type de partition : "Apple_APFS".​

Il est impossible a priori qu'une partition de type "Apple_APFS" soit décrite par un descripteur GPT qui lui assignerait comme UUID : 48465300-0000-11AA-AA11-00306543ECAC de type : "Apple_HFS".

La configuration du disque que tu affiches -->

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.7 GB   disk0s2

• n'a rien à voir avec la distribution sous-jacente de blocs que tu avais affiché antérieurement -->

    start     size  index  contents
        0        1         PMBR
        1        1         Pri GPT header
        2       32         Pri GPT table
       34        6    
       40  3932000      1  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  3932040   262151    
  4194191       32         Sec GPT table
  4194223        1         Sec GPT header

• car la configuration pour le kernel montre 2 partitions dont une partition EFI au rang n°1 > alors que la distribution de blocs GPT ne montre qu'1 partition et pas de partition EFI.

• l'extension de la partition est de 3932000 blocs de 512 octets = 2.01 Go soit la taille du volume de l'image-disque recelant un OS de secours démarré.

• l'invite de commande -bash-3.2# qui précédait le tableau des blocs montre que la commande a été passée dans le terminal de la session de secours ouverte.

Conclusion : le disk0 indexait alors l'image-disque de l'OS de secours démarré > et pas le disque interne du Mac d'une capacité de 251 Go qui devait avoir été indexé disk1. Bref : ta commande s'est trompée de cible.

Bien vu! Je suis désolé effectivement vu que j'arrivais pas a faire de "gpt show" sur ma session j'ai booté sur le Recovery, d'où l'incohérence entre les deux commandes. Par contre pour PonchoYa tu penses qu'on peut faire quelque chose?

 

[Membre supprimé 1060554]

Le SIP (protocole de sécurisation) activé interdit la lecture de la table GPT à la commade gpt depuis la session d'utilisateur. Il faut donc désactiver le SIP pour utiliser la commande gpt dans le terminal de l'OS démarré.

- démarre en mode secours > passe la commande :​

csrutil disable

• qui désactive le SIP (commande invalide dans le terminal de la session d'utilisateur)

- de retour dans ta session > tu peux alors passer la commande :​

sudo gpt show disk0

• qui affiche la distribution des blocs du disque interne

Note : sudo obligé avec gpt dans le terminal de la session d'utilisateur. Ce qui retourne une demande de password : tu tapes en aveugle ton mot-de-passe de session (admin) et tu revalides.

 

[ogee]

Ha OK le SIP bloquait le "gpt show". Merci de l'info je retentirai demain le "gpt show" demain. Mais j'ai l'impression que mon intervention foireuse avec le lien qui marche pas, mes commandes foireuses et mon fixage sur les octuples, on en a un peu oublié PonchoYa, du coup je m'en veux un peu lol. D'autant plus que mon mac n'a pas de soucis en plus

En tout cas un grand merci pour ton aide et ta pédagogie, j'ai appris plein de trucs grâce à toi. Je te laisse avec PonchoYa!

 

[Membre supprimé 1060554]

Il arrive dans un même fil que plusieurs conversations s'entremêlent. Dans les grands romans d'Ancien Français du XIIIè siècle (comme le Lancelot en Prose ou le Tristan en Prose) > ce procédé est appelé l'« entrelacement ». Tant que l'entrelacement intervient comme ici en tenant compte de suspensions logiques d'une conversation pour donner carrière à une nouvelle : ça ne crée pas de confusion.

 

[ogee]

Hello,

PonchoYa a réussi a retrouver sa session grâce à l'aide de klanomath, un utilisateur de StackExchange. Du coup je vais poster sa solution sur ce forum au cas où ça pourrait aider quelqu'un. Par contre, je n'arrive pas mettre le lien de la réponse StackExchange sans que le lien devienne corrompu donc je le mets avec un espace aprés le https:
https:// apple.stackexchange.com/questions/387732/unable-to-boot-on-my-apfs-partition

Pour info, la cause du probleme serait que le superblock du container APFS a été réécrit par un MBR, probablement suite à un arrêt inopiné du macbook, dû à une batterie defectueuse aprés seulement 400cycles, .

On peut le voir ici:

-bash-3.2# dd if=/dev/disk0 bs=512 count=1 skip=614448 2>/dev/null | vis -wc; echo
3\M-@\M^N\M-P\M-<\0|\M^N\M-@\M^N\M-X\M->\0|\M-?\0\^F\M-9\0\^B\M-|\M-s\M-$Ph\^\\^F\M-K\M-{\M-9\^D\0\M-=\M->\a\M^@~\0\0|\v\^O\M^E\^P\^A\M^C\M-E\^P\M-b\M-q\M-M\^X\M^HV\0U\M-FF\^Q\^E\M-FF\^P\0\M-4A\M-;\M-*U\M-M\^S]r\^O\M^A\M-{U\M-*u\t\M-w\M-A\^A\0t\^C\M-~F\^Pf`\M^@~\^P\0t&fh\0\0\0\0f\M^?v\bh\0\0h\0|h\^A\0h\^P\0\M-4B\M^JV\0\M^K\M-t\M-M\^S\M^_\M^C\M-D\^P\M^^\M-k\^T\M-8\^A\^B\M-;\0|\M^JV\0\M^Jv\^A\M^JN\^B\M^Jn\^C\M-M\^Sfas\^^\M-~N\^Q\^O\M^E\f\0\M^@~\0\M^@\^O\M^D\M^J\0\M-2\M^@\M-k\M^BU2\M-d\M^JV\0\M-M\^S]\M-k\M^\\M^A>\M-~}U\M-*un\M^?v\0\M-h\M^J\0\^O\M^E\^U\0\M-0\M-Q\M-fd\M-h\^?\0\M-0\M-_\M-f`\M-hx\0\M-0\M^?\M-fd\M-hq\0\M-8\0\M-;\M-M\^Zf#\M-@u;f\M^A\M-{TCPAu2\M^A\M-y\^B\^Ar,fh\a\M-;\0\0fh\0\^B\0\0fh\b\0\0\0fSfSfUfh\0\0\0\0fh\0|\0\0fah\0\0\a\M-M\^ZZ2\M-v\M-j\0|\0\0\M-M\^X\240\M-7\a\M-k\b\240\M-6\a\M-k\^C\240\M-5\a2\M-d\^E\0\a\M^K\M-p\M-,<\0t\M-|\M-;\a\0\M-4\^N\M-M\^P\M-k\M-r+\M-I\M-dd\M-k\0$\^B\M-`\M-x$\^B\M-CInvalid\spartition\stable\0Error\sloading\soperating\ssystem\0Missing\soperating\ssystem\0\0\0\0bz\M^Yq\^T\^Q\^Y\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0U\M-*

[~] $ echo -n '3\M-@\M^N\M-P\M-<\0|\M^N\M-@\M^N\M-X\M->\0|\M-?\0\^F\M-9\0\^B\M-|\M-s\M-$Ph\^\\^F\M-K\M-{\M-9\^D\0\M-=\M->\a\M^@~\0\0|\v\^O\M^E\^P\^A\M^C\M-E\^P\M-b\M-q\M-M\^X\M^HV\0U\M-FF\^Q\^E\M-FF\^P\0\M-4A\M-;\M-*U\M-M\^S]r\^O\M^A\M-{U\M-*u\t\M-w\M-A\^A\0t\^C\M-~F\^Pf`\M^@~\^P\0t&fh\0\0\0\0f\M^?v\bh\0\0h\0|h\^A\0h\^P\0\M-4B\M^JV\0\M^K\M-t\M-M\^S\M^_\M^C\M-D\^P\M^^\M-k\^T\M-8\^A\^B\M-;\0|\M^JV\0\M^Jv\^A\M^JN\^B\M^Jn\^C\M-M\^Sfas\^^\M-~N\^Q\^O\M^E\f\0\M^@~\0\M^@\^O\M^D\M^J\0\M-2\M^@\M-k\M^BU2\M-d\M^JV\0\M-M\^S]\M-k\M^\\M^A>\M-~}U\M-*un\M^?v\0\M-h\M^J\0\^O\M^E\^U\0\M-0\M-Q\M-fd\M-h\^?\0\M-0\M-_\M-f`\M-hx\0\M-0\M^?\M-fd\M-hq\0\M-8\0\M-;\M-M\^Zf#\M-@u;f\M^A\M-{TCPAu2\M^A\M-y\^B\^Ar,fh\a\M-;\0\0fh\0\^B\0\0fh\b\0\0\0fSfSfUfh\0\0\0\0fh\0|\0\0fah\0\0\a\M-M\^ZZ2\M-v\M-j\0|\0\0\M-M\^X\240\M-7\a\M-k\b\240\M-6\a\M-k\^C\240\M-5\a2\M-d\^E\0\a\M^K\M-p\M-,<\0t\M-|\M-;\a\0\M-4\^N\M-M\^P\M-k\M-r+\M-I\M-dd\M-k\0$\^B\M-`\M-x$\^B\M-CInvalid\spartition\stable\0Error\sloading\soperating\ssystem\0Missing\soperating\ssystem\0\0\0\0bz\M^Yq\^T\^Q\^Y\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0U\M-*' | unvis | hexdump -Cv
00000000  33 c0 8e d0 bc 00 7c 8e  c0 8e d8 be 00 7c bf 00  |3.....|......|..|
00000010  06 b9 00 02 fc f3 a4 50  68 1c 06 cb fb b9 04 00  |.......Ph.......|
00000020  bd be 07 80 7e 00 00 7c  0b 0f 85 10 01 83 c5 10  |....~..|........|
00000030  e2 f1 cd 18 88 56 00 55  c6 46 11 05 c6 46 10 00  |.....V.U.F...F..|
00000040  b4 41 bb aa 55 cd 13 5d  72 0f 81 fb 55 aa 75 09  |.A..U..]r...U.u.|
00000050  f7 c1 01 00 74 03 fe 46  10 66 60 80 7e 10 00 74  |....t..F.f`.~..t|
00000060  26 66 68 00 00 00 00 66  ff 76 08 68 00 00 68 00  |&fh....f.v.h..h.|
00000070  7c 68 01 00 68 10 00 b4  42 8a 56 00 8b f4 cd 13  ||h..h...B.V.....|
00000080  9f 83 c4 10 9e eb 14 b8  01 02 bb 00 7c 8a 56 00  |............|.V.|
00000090  8a 76 01 8a 4e 02 8a 6e  03 cd 13 66 61 73 1e fe  |.v..N..n...fas..|
000000a0  4e 11 0f 85 0c 00 80 7e  00 80 0f 84 8a 00 b2 80  |N......~........|
000000b0  eb 82 55 32 e4 8a 56 00  cd 13 5d eb 9c 81 3e fe  |..U2..V...]...>.|
000000c0  7d 55 aa 75 6e ff 76 00  e8 8a 00 0f 85 15 00 b0  |}U.un.v.........|
000000d0  d1 e6 64 e8 7f 00 b0 df  e6 60 e8 78 00 b0 ff e6  |..d......`.x....|
000000e0  64 e8 71 00 b8 00 bb cd  1a 66 23 c0 75 3b 66 81  |d.q......f#.u;f.|
000000f0  fb 54 43 50 41 75 32 81  f9 02 01 72 2c 66 68 07  |.TCPAu2....r,fh.|
00000100  bb 00 00 66 68 00 02 00  00 66 68 08 00 00 00 66  |...fh....fh....f|
00000110  53 66 53 66 55 66 68 00  00 00 00 66 68 00 7c 00  |SfSfUfh....fh.|.|
00000120  00 66 61 68 00 00 07 cd  1a 5a 32 f6 ea 00 7c 00  |.fah.....Z2...|.|
00000130  00 cd 18 a0 b7 07 eb 08  a0 b6 07 eb 03 a0 b5 07  |................|
00000140  32 e4 05 00 07 8b f0 ac  3c 00 74 fc bb 07 00 b4  |2.......<.t.....|
00000150  0e cd 10 eb f2 2b c9 e4  64 eb 00 24 02 e0 f8 24  |.....+..d..$...$|
00000160  02 c3 49 6e 76 61 6c 69  64 20 70 61 72 74 69 74  |..Invalid partit|
00000170  69 6f 6e 20 74 61 62 6c  65 00 45 72 72 6f 72 20  |ion table.Error |
00000180  6c 6f 61 64 69 6e 67 20  6f 70 65 72 61 74 69 6e  |loading operatin|
00000190  67 20 73 79 73 74 65 6d  00 4d 69 73 73 69 6e 67  |g system.Missing|
000001a0  20 6f 70 65 72 61 74 69  6e 67 20 73 79 73 74 65  | operating syste|
000001b0  6d 00 00 00 00 62 7a 99  71 14 11 19 00 00 00 00  |m....bz.q.......|
000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
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

On peut le comparer avec un superblock normal de conteneur APFS :

Du coup voici les étapes pour la résolution du probléme en anglais:

To fix this (via TeamViewer & external boot volume with Catalina installed) another (older) superblock of disk0s2 was used to overwrite the MBR data.

1. Install HexFiend and search for the magic bytes of a superblock: NXSB on partition disk0s2. The first occurance was after the first ~3 GB of disk0s2. The metadata part of an APFS container usually houses various older superblocks. The current superblock usually is the copy of one "older" superblock if the Mac was shut down properly previously.
   

   Although thereʼs only one container, there are several copies of the container superblock (an instance of nx_super block_t) stored on disk. These copies hold the state of the container at past points in time. Block zero contains a copy of the container superblock thatʼs used as part of the mounting process to find the checkpoints. Block zero is typically a copy of the latest container superblock, assuming the device was properly unmounted and was last modified by a correct Apple File System implementation. However, in practice, you use the block zero copy only to find the checkpoints and use the latest version from the checkpoint for everything else. (Source : https:// developer.apple.com/support/downloads/Apple-File-System-Reference.pdf )

   The size of a superblock appears to be 1382 Bytes. Since an MBR has a size of 512 Bytes, I expected that the latter 870 Bytes (1382-512) of the superblock haven't been overwritten and decided to copy only the first 512 Bytes of an older superblock to keep as much as possible of the leftovers of the original one.
2. dd the 512 Bytes of this older superblock to a file on the desktop:
   sudo dd if=/dev/disk0s2 of=/Users/user_name/oldsuperblock.bin bs=1 count=512 skip=3063808000 #"3063808000" is just an example Byte offset because the zsh history file with the original command is lost
3. dd the file to block0:
   sudo dd if=/Users/user_name/oldsuperblock.bin of=/dev/disk0s2 bs=512 count=1
4. Reboot the Mac to the temporary boot volume to "reload" the APFS superblock of the internal APFS container
5. Repair the APFS container (with encrypted volumes!):
   diskutil repairVolume disk1
   diskutil (or better fsck_apfs) complained about a wrong checksum of the superblock but fixed it without any trouble.
6. Check if the encrypted Data Volume can be mounted with Disk Utility > Mount. To unlock the volume a password of a user of the "broken" disk has to be entered.
7. Boot to the internal boot volume
8. SUCCESS!

Conclusion:

I haven't been able to find any numbering scheme or time stamps for superblocks in the Apple APFS documentation or by comparing the various older versions of the superblock I have found.

It's unclear whether it was pure luck to fetch a working older superblock. No current backup was available so it's even more uncertain whether reinstating an old superblock leads to data loss. At least the Mac booted and the encrypted volumes could be unlocked.

Voilà, et encore merci @macomaniac pour ton aide!

 

[Membre supprimé 1060554]

Bonjour ogee

J'ai réussi à trouver le fil où se trouve exposée l'intervention de klanomath. Je te livre mes impressions -->

- belle technique de la commande dd (data_doubler) - dont personnellement je ne me sers que rarement (mais j'ai peut-être tort).​

​

- théorisation contestable : il assume que le super-bloc de l'apfs a été réécrit par le bloc n°0 qui porte la table de partition MBR du disque. Or il raisonnne constamment comme si le bloc n°0 en question avait une taille de 512 octets (bloc standard) => ce qui fait que les seuls 512 octets initiaux du super-bloc de l'apfs auraient été écrasés > un super-bloc apfs ayant une taille réglementaire de 1382 octets. Il resterait donc 1382 octets - 512 octets = 870 octets de super-bloc non écrasés. Or sachant que se trouve stockés plusieurs backups logiques de super-bloc > les 512 octets suivant les 512 octets écrasés par les 512 octets de la MBR => auraient des chances de receler un backup de superbloc opérationnel pour initialiser le Conteneur apfs. Il a donc copié (via dd) les octets allant du 513è au 1024è > puis il es a restaurés sur les octets 1 à 512 du super-bloc apfs qui avaient été écrasés. Il faut croire que ça aurait marché.​

​

- il y a une objection fondamentale à cette recréation spéculative. C'est que le gabarit de bloc actif sur le disque de PonchoYa est le bloc octuple de 4096 octets. Ce qui se voit au fait que la table GPT directrice occupe les seuls blocs 1 => 5 > alors qu'elle occupe les blocs 1 > 33 lorsque le gabarit de blocs est le standard de 512 octets. Donc le gabarit de bloc est bien le bloc octuple de 4096 octets. Voici alors la conséquence qui s'en tire : le bloc n°0 où se trouve inscrite la table MBR alternative => ne fait absolument pas 512 octets comme il le présume > mais 4096 octets. S'il y a eu écrasement du super-bloc de l'apfs > ce n'est donc pas par les 512 octets d'un bloc n°0 MBR standard > mais par les 4096 octets du bloc n°0 MBR actif. Son argument que les 870 octets suivant les 512 octets initiaux du super-bloc apfs seraient valides car non écrasés => est donc invalide > puisqu'il y a eu écrasement par les 4096 octets du bloc n°0 réel de la MBR.​

En résumé : il plaque constamment un schéma expérimental correspondant à une computation en unité de blocs de 512 octets => sur un disque régi par une computation d'unités de blocs de 4096 octets. Je ne vois franchement pas comment ça pourrait marcher. Il a apparemment pris la maîtrise via TeamViewer du Mac à problème : j'en déduis que la restituation écrite qu'il donne après-coup de ses interventions et qui correspond à un disque régi par une computation de bloc de 512 octets => ne peut pas restituer les opérations qu'il aurait effectuées en mode live.