Seeking clarification
Please add to the opening question a note of whether the panic occurs during:
a) the preparation stage of installation (before the first automated restart of the system)
or
b) post-preparation, the installation stage (between the first and second automated restarts).
Logging the preparation and installation stages of installation
Screenshots at http://www.wuala.com/grahamperrin/public/2011/08/01/a/?mode=gallery demonstrate the Installer Log window in foreground whilst Mac OS X Installer runs — the installation stage.
During either stage (preparation or installation) you can present a log window by keying:
With luck, you might see — possibly greyed-out beneath the foreground detail of the panic — the point at which panic occurs.
At the root of the volume to which installation is attempted: if installation fails you may find a directory:
Mac OS X Install Data
Within that directory, a log. If present, that log may be informative to you, but not as useful (to readers here) as the .panic file.
PRAM, kernel panic information and the .panic file
Apple's Mac OS X: What's stored in PRAM tells us that recent kernel panic information is stored in PRAM. If the first normal start following a panic does not present the customary dialogue, you should wonder whether/how that information was lost from PRAM.
If the kernel panic occurs during the installation stage — and if the subsequent start defaults to attempt continuation of the installation, or Mac OS X Utilities (not a normal start) — and if you are without an obvious interface to kernel panic information — then my hunch would be that whilst started in that special mode, the path to which a .panic file might normally be written is read-only …
… if that's the case and if you're comfortable at the command line, maybe start in single user mode following the panic then use the following command to see whether panic information is legible on screen:
nvram -p
(For the number of ifs above, apologies!)
Mounting the volume
Disk Utility verification and possible repair of the partition map
If you have not already done so, use Disk Utility 13 (426) in OS X 10.8 to select then verify:
- not the greyed-out partition
- instead, the physical disk that contains the partition.
If verification reveals a problem with the partition map, then consider allowing Disk Utility to attempt a repair.
Proceeding without Disk Utility
Credit to Caesium's answer for finding the asr
suggestion.
Here with a disposable JHFS+ volume, an example of adjustments working as expected. Note the file system checks:
macbookpro08-centrim:~ gjp22$ diskutil unmount /dev/disk12s1
Volume sandpit on disk12s1 unmounted
macbookpro08-centrim:~ gjp22$ sudo asr adjust --target /dev/disk12s1 --settype "Apple_UFS"
Fsck /dev/disk12s1 ....10....20....30....40....50....60....70....80....90....100
Adjust completed successfully
macbookpro08-centrim:~ gjp22$ diskutil list disk12
/dev/disk12
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *256.9 MB disk12
1: Apple_UFS sandpit 256.9 MB disk12s1
macbookpro08-centrim:~ gjp22$ diskutil mount readOnly /dev/disk12s1
Volume on disk12s1 failed to mount
macbookpro08-centrim:~ gjp22$ sudo asr adjust --target /dev/disk12s1 --settype "Apple_HFS"
Fsck /dev/disk12s1 ....10....20....30....40....50....60....70....80....90....100
Adjust completed successfully
macbookpro08-centrim:~ gjp22$ diskutil mount readOnly /dev/disk12s1
Volume sandpit on /dev/disk12s1 mounted
macbookpro08-centrim:~ gjp22$
If the type of your own /dev/disk0s4
can not be safely adjusted or (re)set to Apple_HFS
then:
- the operating system may no longer work with the HFS Plus file system (or remnants thereof) that occupies, or occupied, the affected area of the physical disk; and
- you might doubt the integrity of the partition (start and end blocks, and so on).
Relevant lines from /private/var/log/install.log
should reveal what, if anything, happened to disk0s4
before, during or after installation of the OS to disk0s2
. This logged information may become critical to regaining easy access to the data.
Getting the data without mounting the volume
Good luck with your use of Data Rescue 3 – I have the app, but have never attempted to recover from any area of a disk where the partition type has been affected in this way.
Observations
Device/media name
This is sometimes, not always, a match for the volume name. Here for example:
macbookpro08-centrim:~ gjp22$ diskutil info disk0s2 | grep Name:
Device / Media Name: swap
Volume Name: swap
macbookpro08-centrim:~ gjp22$ diskutil info disk0s4 | grep Name:
Device / Media Name: Untitled
Volume Name: spare
For Todd K., presence of the device/media name –
MacBook Data
– raises hope that start and end blocks etc. are good, that only the type
of the partition is wrong.
Recovery HD implies Recovery OS 10.7.x.
In any case such as this, an installation that is incomplete (that is without the expected upgrade to the Apple_Boot
slice) signals that a nonstandard method of installation – with only part of Apple's installer app – may have been used.
Side note
GUID Partition Table, as it's described in Disk Utility, is the norm for this type of modern installation of OS X – not Master Boot Record.
Best Answer
The recommended way to create a recovery partition on an external disk is now to use Apple's Recovery Disk Assistant. It was released after that Mac OS X Hints article and Lion DiskAssistant.
If your Mac has firmware support for internet recovery mode (like Macs released after 2010-2011), you won't probably need any external recovery partition. http://support.apple.com/kb/ht4718: