Tipo di partizione FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, unità smontabile

1

Sì, ho già provato questo: Tipo di partizione improvvisamente FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, unità smontabile

La mia partizione principale si trova in questo formato ffffffff-ffff-ffff-ffff-ffffffffffff o qualunque esso sia. E ho bisogno di tutti i dati su questo disk3s2.

Ecco un'immagine del mio disco, un paio di ore fa:

  • disk3s1: EFI
  • disk3s2: Macintosh (ffffffff-ffff-ffff-ffff-ffffffffffff partizione con tutti i miei dati su, voglio questi dati!)
  • disk3s3: Apple_HFS Recovery HD
  • disk3s4: New (un'altra partizione inutile, è vuota.)
  • disk3s5: Apple_Boot Recovery HD

Che cosa ho fatto per provare a riparare il mio disco:

diskutil umountDisk /dev/disk3
sudo gpt destroy /dev/disk3
diskutil umountDisk /dev/disk3
sudo gpt create -f /dev/disk3

sudo gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk3

Quindi ogni volta che provo ad aggiungere un'altra partizione, ottengo questo errore:

gpt add: /dev/disk3: error: no space available on device

Aiutatemi se avete suggerimenti, ho perso molti dati importanti !!!

Aggiornamento:

diskutil list

porta a questo:

 /dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage SSD                     119.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            SSD                    +118.8 GB   disk1
                                 Logical Volume on disk0s2
                                 ...deleted it...
                                 Unencrypted

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *320.1 GB   disk3
   1:                        EFI EFI                     209.7 MB   disk3s1

e

sudo gpt -r show disk3

porta a questo:

    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  624732774         
  625142414         32         Sec GPT table
  625142446          1         Sec GPT header
    
posta Seliem 08.01.2017 - 12:10
fonte

1 risposta

1

I volumi potrebbero essere ripristinati in una sessione di TeamViewer cercando stringhe speciali simili al metodo descritto in questa risposta: My SATA hardrive è stato espulso e non è possibile rimontarlo a causa di problemi .

Le ipotesi fatte:

  • disk3s4 (24,6 GB) e disk3s5 (650 MB) si trovano alla fine del disco (vedi diskutil list screenshot della domanda - entrambi svaniti dopo aver distrutto la vecchia tabella delle partizioni con sudo gpt destroy /dev/disk3 )
  • disk3s2 (Macintosh) occupa / occupa l'intero spazio disco non allocato (tranne il 1 ° Recovery HD) di ~ 294 GB ed è crittografato.

Per ottenere il blocco iniziale del primo Recovery HD immettere (che deve essere nell'intervallo 271 GiB - 274 GiB o ~ 291 GB - ~ 295 GB del disco)

sudo hexdump -s 271g /dev/disk3 | grep "48 46 53 4a"

(hexdump usa GibiBytes invece di GigaBytes!) che ha rivelato:

447f801400 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f828a00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f840c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 00 06
447f871e00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
...

0x447f801400 è il byte 294196876288 (o il blocco 574603274) del disco. Poiché la stringa HFSJ risiede nel terzo blocco di un volume, Recovery HD inizia con il blocco 574603272.

L'output tipico se il volume precedente non era un FileVault ma un normale volume HFSJ avrebbe invece questo aspetto:

447f800c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 01 ff
447f801400 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f828a00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f840c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 00 06
447f871e00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
...

Il numero del primo e del secondo byte mostrano una differenza di 0xc00-0x1400 = 0x800 o 2048 byte perché il precedente volume OS X ha un'intestazione di volume alternativa nel secondo blocco ultimo mentre i volumi di FileVault non ne hanno uno.

Il Recovery HD ha una dimensione fissa di 1269536 blocchi e può essere aggiunto con gpt alla tabella delle partizioni.

sudo gpt add -i 3 -b 574603272 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk3

Ora verifica il volume con

diskutil verifyVolume disk3s3

Se i limiti della partizione e il volume sono / è OK, otterrai un codice di uscita 0.

Nello spazio su disco non allocato tra EFI e Recovery HD è stata aggiunta una partizione CoreStorage:

sudo gpt add -i 2 -b 409640 -s 574193632 -t 53746F72-6167-11AA-AA11-00306543ECAC disk3

La finestra della password di FileVault è spuntata e la password è stata inserita, quindi è stata aggiunta con successo probabilmente.

Il disco e il volume sono stati verificati con:

diskutil verifyDisk disk3
diskutil verifyVolume disk3s2

che sono entrambi usciti con il codice 0 e tutto andava bene.

Successivamente il volume di FileVault è stato esteso alle dimensioni complete del disco con:

diskutil cs lvUUID resizeStack 318g #with lvUUID: the Logical Volume UUID of the second CoreStorage container
    
risposta data 08.01.2017 - 20:19
fonte

Leggi altre domande sui tag