Como faço para recuperar a partição APFS de um Macbook usando o Ubuntu?

Question

Antecedentes

Eu uso um Macbook Pro que tem High Sierra e Fedora em dual-boot. Eu não estava usando o Fedora, então eu queria experimentar o Ubuntu 17.10 e executei um USB ao vivo (inicializando no modo EFI).

Dado que todos os meus arquivos relacionados ao trabalho, projetos e outras "coisas importantes" (no lado Mac) já foram copiados através do Dropbox ou repositórios Git remotos, eu decidi deletar o Fedora e instalar o Ubuntu sem fazer um completo imagem bitstream da unidade.

No começo, eu apaguei as partições relacionadas ao Fedora usando o Gnome Disks (isso é OK). Eu iniciei o instalador do Ubuntu e fiz estes passos:

• Selecionou um idioma > Continue
• Verificado "Download de atualizações durante a instalação do Ubuntu" > Continue
• Escolha "Outra coisa" para as partições > Continue
• Equivocou erroneamente o tipo de /dev/sda2 como "Volume físico para criptografia" e adicionou minha senha

Por favor note que eu não escolhi a opção "Sobrescrever espaço em disco vazio". Eu também não continuei com a instalação (não cheguei ao ponto em que ele pede para você confirmar a nova tabela de partições). Em vez disso, cliquei em "Voltar" e fechei o instalador imediatamente.

Isso não deve ter escrito nada no disco. No entanto, o instalador do Ubuntu decidiu escrever algo de qualquer maneira, parece.

Problema

Após a reinicialização rápida, ficou claro que algo errado foi gravado no disco, apesar de nunca ter chegado à etapa de confirmação. O tipo da partição foi alterado e nem o rEFInd (que carrega corretamente) nem a tela de inicialização da Apple podem encontrar o macOS.

Esta é a saída de lsblk :

NAME   FSTYPE LABEL              UUID                                 MOUNTPOINT
loop0  squash                                                         /rofs
sda                                                                   
├─sda1 vfat   EFI                67E3-17ED                            
├─sda2 crypto                    9b2ca99d-cf43-4d35-936d-be37db7b950d 
└─sda3 

Originalmente, sda2 era APFS. No mac OS Filevault foi habilitado, no entanto não posso dizer se ele estava usando CoreStorage ou criptografia APFS nativa (eu suspeito que o último como foi migrado de uma versão mais antiga com o HFS +).

A execução de diskutil list da recuperação do Apple Internet gera isso:

/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2: 7C3457EF-0000-11AA-AA11-00306543ECAC               349.7 GB   disk0s2
   3: 5361644D-6163-11AA-AA11-00306543ECAC               1.3 GB     disk0s3
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     Apple_partition_scheme                        *1.3 GB     disk1
   1:        Apple_partition_map                         30.7 KB    disk1s1
   2:                  Apple_HFS OS X Base System        1.3 GB     disk1s2

O segundo dispositivo é a recuperação da Internet.

Estranhamente, também /dev/sda3 aka disk0s3 não é reconhecido, apesar de nunca ser tocado de forma alguma. Assim, o Mac agora nem sequer inicializa a recuperação local, mas depende da Internet.

De volta ao Ubuntu, parted reclama de uma GPT corrompida, mas gdisk acha que está tudo bem. Aqui está a saída de parted -l :

Model: ATA APPLE SSD SM0512 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system  Name                  Flags
 1      20.5kB  210MB  210MB   fat32        EFI System Partition  boot, esp
 2      210MB   350GB  350GB
 3      350GB   351GB  1306MB


Error: Both the primary and backup GPT tables are corrupt.  Try making a fresh
table, and using Parted's rescue feature to recover partitions.

Perguntas

Mais importante, como posso usar o Ubuntu para corrigir a tabela da GPT e definir o tipo de sistema de arquivos correto para /dev/sda2 e /dev/sda3 ?

Em segundo lugar, o instalador do Ubuntu escreve coisas na tabela de partições antes mesmo de confirmar as mudanças? Isso é um comportamento pretendido?

Há chances de recuperar o sistema sem reinstalar? Como eu disse, tenho backups dos dados valiosos. O que me preocupa é que vou perder muito tempo para reinstalar aplicativos e coisas do tipo.

    

Answer 1

Você escreveu:

% bl0ck_qu0te%

Devido a seus problemas subsequentes, eu diria que o instalador do Ubuntu gravou no disco imediatamente ou algo mais danificou a partição em uma coincidência de tempo. De qualquer forma, sua melhor esperança de recuperação está no lado do macOS. O APFS é simplesmente novo demais para ter qualquer ferramenta de recuperação nativa do Linux, pelo menos tanto quanto eu sei. Mesmo que essas ferramentas estivessem disponíveis no Linux, eu ficaria um pouco desconfiado delas. Eu sugiro que você pergunte sobre a recuperação em um fórum do Mac. Você pode ou não receber qualquer coisa de volta; O APFS é novo o suficiente para que ainda não haja muita experiência disponível sobre como recuperar sistemas de arquivos danificados, e é concebível que o instalador do Ubuntu (ou o que quer que tenha causado o dano) tenha sobrescrito algo realmente crítico. Isso é especialmente verdadeiro se você usou criptografia no lado do macOS - embora a criptografia tenha algumas grandes vantagens, uma grande desvantagem é que danos menores no sistema de arquivos podem complicar muito a recuperação, talvez a ponto de impossibilitá-la. (Eu não sei como o APFS avança nesse aspecto.)

% bl0ck_qu0te%

A saída parted que você citou não é clara sobre a natureza do dano alegado e você não forneceu nenhuma saída de gdisk . Em particular, a opção v de gdisk (ou sgdisk -v ) pode ser útil, como seria a saída completa de quando você inicia gdisk e digita p (ou digita sudo gdisk -l ). Você pode ter ignorado um aviso gdisk ; ou pode ter reparado silenciosamente algum problema trivial que está provocando uma reclamação por parted ; ou parted pode estar reclamando sobre algo que realmente não é dano e que gdisk aceitou; ou parted pode ter notado um problema que gdisk não notou. As distinções entre algumas dessas coisas podem ser subjetivas - embora a especificação GPT seja muito mais clara do que a especificação MBR inexistente, ela tem algumas ambiguidades, então um programa pode interpretar algo incomum como dano enquanto outro pode pensar que está tudo bem. Se a tabela de partições estiver danificada, a página gdisk sobre a reparação de danos da GPT poderá seja útil. (Nota: Eu sou o autor de gdisk .) Sem saber exatamente o que o gdisk pensa do disco, não posso oferecer conselhos mais específicos sobre como consertá-lo, ou mesmo se ele precisa de reparo. / p>