Risolvere un avvio della partizione di Windows usando gli strumenti di OS X.

Question

Risolvere un avvio della partizione di Windows usando gli strumenti di OS X.

#1 da (0 voti)

2

Ho un sistema di avvio triplo sul Mac Book Pro di inizio 2013: OS X, Windows 7 e Ubuntu. Sto usando REFInd come gestore di avvio. La mia installazione di Windows si avvia utilizzando l'avvio legacy del BIOS e l'avvio di OS X e Ubuntu con avvio EFI nativo.

Tutto ha funzionato fino a quando non ho aggiornato a OS X Yosemite. Che ha rotto il mio Windows:

"No bootable device -- insert boot disk and press any key"

Credo che avrei dovuto eseguire il backup del settore di avvio prima dell'aggiornamento, ma ora è troppo tardi! Poiché Windows si avvia in modalità BIOS, legge l'MBR ibrido e infatti, la partizione di Windows non è stata contrassegnata come avviabile. Dopo averlo contrassegnato come avviabile con fdisk, il messaggio è cambiato in:

"Missing operating system"

Ho controllato l'MBR con fdisk e GPT con gdisk che sono effettivamente compatibili e sincronizzati. Dopo ore passate a cercare e provare tutto, ho finalmente capito qual era il problema:

Ho avuto alcune settimane prima di ridimensionare la partizione di Windows, riducendo la partizione di OS X in OS X, e poi, usando un certo software Windows, crescendo la partizione di Windows per accogliere il nuovo spazio libero che ora ha mentito prima la partizione di Windows. Ora sembra che quel programma abbia aggiornato SOLO MBR: dal punto di vista GPT c'è uno spazio non partizionato prima della partizione Windows, e dal punto di vista MBR lo spazio utilizzato da Windows.

Tuttavia, durante l'installazione di Yosemite, ha sincronizzato l'MBR ibrido per conformarsi al GPT, contrassegnando la parte superiore della partizione di Windows come spazio libero. Quel "spazio libero", ovviamente contiene il bootloader di Windows e un sacco di dati!

La mia domanda è, c'è un modo per scansionare la porzione apparentemente non partizionata del disco e determinare il primo settore della partizione Windows? Immagino che sia possibile, ma ho bisogno degli strumenti giusti per questo.

Per informazioni, ecco i miei dati GPT:

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640       731723959   348.7 GiB   AF05  Macintosh HD
   3       731723960       732993495   619.9 MiB   AB00  Recovery HD
   4       799528960       906948607   51.2 GiB    0700  WINDOWS 1
   5       906948608       977104895   33.5 GiB    0700  UBUNTU

e i dati da MBR protettivi / ibridi:

 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -     409639] <Unknown ID>
 2: AC 1023 254  63 - 1023 254  63 [    409640 -  731314320] <Unknown ID>
 3: AB 1023 254  63 - 1023 254  63 [ 731723960 -    1269536] Darwin Boot 
*4: 0C 1023 254  63 - 1023 254  63 [ 732993496 -  173955112] Win95 FAT32L

Si noti che esiste un settore 66535465, 31,7 GiB gap prima della partizione 51,2 GiB Windows. Quando Windows ha funzionato, ha visto la sua partizione come 80 partizione GiB. Quindi, l'inizio "reale" di quella partizione Windows è da qualche parte in quella distanza. Come eseguirne la scansione?

windows bootcamp boot partition refind

posta GolDDranks 18.10.2014 - 04:30

fonte

1 risposta

Leggi altre domande sui tag windows bootcamp boot partition refind

Aggiunta di caratteri X a XQuartz Come cambio l'effetto sonoro feedback / volume su quello in Mavericks?

score 0 · Accepted Answer

Pubblicherò questa risposta come risposta, anche se non ha risolto il mio problema: alla fine si trattava di un caso perso. Conseguenze: ho eseguito il backup della partizione di Windows nella mia partizione OS X:

sudo dd bs=512 if=/dev/disk0 of=windows_backup skip=732993496 count=173955112

Ora ho avuto un dump esadecimale da 80 gig che ho potuto esaminare in sicurezza. Ho usato un editor esadecimale per cercare tutti i tipi di metadati:

"NTFS" (codificato in ASCII) che avvia un volume NTFS.
"FILE" (codificato in ASCII) che avvia un record di immissione file nella tabella $ MFT o master in NTFS.
Nomi file di sistema NTFS (come "MFT", provato con little-endian UTF-16 e ASCII)

... e così via. Ma senza successo. Sono stato in grado di trovare tutti i tipi di dati dal dump, ma tutti i metadati, incluso il record di avvio (il primo settore del volume), il file $ Boot (i primi 15 settori dopo il record di avvio), il file $ MFT che tiene traccia di tutti i file sul file system, erano spariti.

La cosa che mi sconcerta è che non sono riuscito a trovare il file $ MFTMirr, che è il file di backup dei file di metadati e salvato a metà del volume.

Sono riuscito a trovare un backup del settore di avvio dalla sua posizione standard, l'ultimo settore del volume. Tuttavia, i dati erano vecchi, dall'epoca prima di ridimensionare il volume. Il settore di avvio ha memorizzato l'offset del file di metadati del file $ MFT, ma ispezionare i riferimenti era discutibile, non c'era nulla di valore lì.

Alla fine, ho concluso che il volume era totalmente bloccato. La morale della storia? Master Boot Record ibrido è malvagio. Inoltre, sembra che il programma che ha ridimensionato il volume abbia fatto un lavoro subparente, non aggiornando alcuni dei metadati.