달력

11

« 2024/11 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
2012. 11. 21. 15:18

HDD 복구 방법 - Invalid BS_impBoot macOS/Tip2012. 11. 21. 15:18




Update : http://cafe.naver.com/uefi/7064


1. 증상

아래 그림과 같이 "Invalid BS_impBoot in boot block:fa31c0"라는 메시지를 Disk Utility 에서 복구를 실행하면 볼 수 있다.

구글링하면 이 증상으로 쌍코피 흘리는 맥 사용자들이 아우성이다.

뭐 그닥 Apple사에서도 관심없는 듯 하고 아뭏든 사용자 실수이니 직접 해결할 수 밖에,,,,

Invalid BS_impBoot in boot block


 2012-11-21  3.56.38


- Mac OS X(Journal)로 포맷된 파티션이 어느날 갑자기 아래 그림과 같이 Disk Utility에서 MS-DOS(FAT) 포맷으로 보인다.


 2012-11-21  3.56.38


2. Windows 에서 Pragon HDD Manager를 이용하여 보면 Apple HFS로 정상적으로 보인다.

- 물론 Paragon HDD manager로 디스크 체크를 해보면 정상적으로 체크는 되지 않는다.

- 이 현상은 "Still Waiting Root Device"의 원인이 되기도 한다.

- 일반적으로 부팅실패하고 부팅시도하면 금지마크로 보인다.

- 이럴때는 손상된 파티션을 Paragon HDD manager의 백업기능이나 파티션 복사 기능을 이용하여 여분의 HDD의 공간에 파티션 복사를 하여 준 다음 다시 원위치하면 간단하게 해결할 수 있다. 즉 paragon으로 복구시 자동으로 파티션을 복구하는 기능을 이용하는 방법이다.

- 그런데 460G정도의 파티션 기준으로 24시간 정도의 시간이 걸린다.  다시 복사하는 데 24 시간 해서 토탈 복구시간은 4일 그냥 우습게 지나간다.

- HDD 파티션의 데이타에 미련이 없다면 깔끔하게 재파티션 후 포맷을 해주는 것이 적절하다.

- 유사한 HDD 이슈는 다음글을 참조한다.  http://osx86.tistory.com/1515


3. 근본적인 원인은 현재 Mac Drive등의 소프트웨어로 인해 맥 파티션의 파티션 블락에 손상을 입힌다 정도이다. 물론, 무분별한 Mac OS X 반복설치때에도 발생하기도 한다.

- 용팔이 들이 은근슬쩍 사용자에게 이 소프트웨어 설치를 권하고 문제가 발생하여 HDD 복구요청을 하면 대략 30만원 정도 요구를 할 것이다.

- 용팔이들의 호갱용이다. ㅎ ㅎ 



Update:


INVALID BS_JMPBOOT IN BOOT BLOCK: 000000

MediaFour‘s MacDrive (7.2.6) keeps screwing up the GPT on my external GPT-formatted drive. It has one HFS+ partition and one 200 MB EFI system partition, and when I boot my iMac into Windows (Vista SP1 x86), mount the drive, and then boot back into Mac OS X (10.5), I usually find that OS X won’t recognize the HFS+ volume any more. The characteristic error is an ignore/eject/format unrecognized dialog after OS X login, and “invalid BS_jmpBoot in boot block: 000000″ from Disk Utility when trying to repair it.

It seems that the GUID for the HFS+ volume is changed from {48465300-0000-11AA-AA11-00306543ECAC} (HFS+) to {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7} (“Microsoft Basic Data”). Windows doesn’t have any trouble mounting it as long as MacDrive is installed, it’s OS X that has the problem. I was able to fix the GPT by changing the GUID back to what it should be, at which point the drive was recognized by OS X, and found that the actual HFS+ file system was unharmed. I wrote most of a GPT editor in the process, and if Mediafour doesn’t fix MacDrive soon, I may end up turning it into a one-click GPT fixer.

***

update:

Here’s the tool I used to fix my own disk: gpt_surgeon.py

It’ll need Python 2.5 or higher, and has only been tried in OS X on my own machine. Run it with no arguments or look at the code for a usage statement. The repair process goes like this:

First, list the partitions on your disk to figure out which one needs to be relabeled with the right filesystem type. If you don’t know what your disk device path is, go look in Disk Utility or System Profiler or run diskutil(8) with its list option. The path for my external disk is /dev/disk1.

$ ./gpt_surgeon.py list /dev/disk1

Read MBR and GPT from /dev/disk1.
partition 0:
     type: EFI System
     name: u'EFI System Partition'
    flags: 0x00000000
partition 1:
     type: Microsoft Basic Data
     name: u'Untitled'
    flags: 0x00000000

Note the partition that says “Microsoft Basic Data”. Assuming that you had a single non-system partition on the disk, and that the partition was HFS+ before MacDrive got to it, this is probably that partition. In my case, it’s partition 1. Remember the number; you’ll need it in the next step.

If you have multiple data partitions on the disk, especially if one of them is actually a Windows data partition, you should use something like disktype to check what filesystems are present in each partition, so that you don’t accidentally relabel the wrong one.

If you have any other partitions from this disk mounted, unmount them now.

You’ll need to run with sudo to get the privileges necessary to actually repair the GPT on disk.

$ sudo ./gpt_surgeon.py repair /dev/disk1 1

Read MBR and GPT from /dev/disk1.
Changing type of partition #1 on /dev/disk1 to HFS+...
    Opened /dev/disk1 for writing.
    Wrote MBR.
    Wrote GPT header.
    Wrote GPT entries.
    Closed /dev/disk1.
Done.

And this is what the disk’s GPT should look like afterwards. Your HFS+ partition should be mountable now.

$ ./gpt_surgeon.py list /dev/disk1

Read MBR and GPT from /dev/disk1.
partition 0:
     type: EFI System
     name: u'EFI System Partition'
    flags: 0x00000000
partition 1:
     type: Apple HFS+
     name: u'Untitled'
    flags: 0x00000000

***

second update: commenter James let me know that Christophe Grenier‘s TestDisk utility can also be used to fix this problem.

***

third update: here’s a video walkthrough of the process. For people who have Flash turned off for some reason, please see the QuickTime version of the walkthrough.

***

last updategpt-surgeon is opening up! Thanks to all who submitted usage reports, suggestions, failure data, and proposed patches. I hope you’ll find future versions at least as useful.Comments have been turned off for this post; all questions, comments, suggestions, and support requests about gpt-surgeon must be submitted through the gpt-surgeon LaunchPad siteand should be accompanied with disktype reports.


:
Posted by Ritz®™