How to use fdisk -e in terminal?

Question

Level 1

4 points

How to use fdisk -e in terminal?

My problem is bit complicated, I will try explain this simple as possible.
It started because disk drive random eject, detail on this thread:
http://discussions.apple.com/message.jspa?messageID=13106931#13106931
Now one of my partition didn't mount. I try to fix this using disk utility -repair disk function- and disk warrior, both not succeed. Then I want to try repair it using Ubuntu live cd, but before that, some tutorial that I found in someone blog says I must disable journaling. It success at other 2 partition but the one that I need to repair wasn't return any dialog after about 2 minutes, that made me close Terminal. Disk1s2 is the problem.

My assumption after some googling, my partition table is messed up and need repairing. I found enlightenment when found tesdisk http://www.cgsecurity.org/wiki/TestDisk . Summaries from what I read there, I should able repair it after run test disk to analyze then using pdisk function in terminal to restore or fix the partition.

What is this mean CHS and LBA didn't match? I assume this value is needed to be repaired.

From the explanation on that site, "use pdisk to recreate the Mac partition map using the values given by TestDisk." Then I realized my partition scheme isn't Apple Partition Map. Refer to image screenshoot #1 it written Fdisk partitonscheme or better known as MBR. Pdisk only support APM, and so far tutorial I found only write about pdisk:
http://perrohunter.com/read/30/repair-a-mac-os-x-hfs-partition-table
CMIIW but fdisk -e, edit function probably able to insert this new values on MBR. I just don't know how to do this.

So is there anyone in that able for *helping me to understand how I could edit this value using fdisk -e?* Please don't refer me to http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/ man8/fdisk.8.html . I've read that and still confused.
If possible using step by step explanation, similar with perrohunter pdisk. I'm not really expert with CLI.
Re-format the disk is not solution.

----
As for now my external drive condition is:
1. Random eject still occur.
2. One partition didn't mount.
3. Diskutil failed to disable journaling. Thus make worrying if fdisk also unable to do the job. But at least I want to give a try.
4. Slow write/read speed even on detected partition.

iMac 7,1 2.0 GHz, Mac OS X (10.6.6)

Posted on Mar 3, 2011 6:13 AM

Reply

Answer 1

Linc Davis

Level 10

209,739 points

Apr 1, 2011 8:55 AM in response to Christopher Murphy

+GPT fdisk (gdisk) will automatically look at the two partition tables and if they aren't the same will offer to fix them.+

There is no "gdisk" on my system. Do you mean gpt(8)?

Reply

Answer 2

MrHoffman

Level 10

146,461 points

Mar 4, 2011 3:45 PM in response to Linc Davis

The +Re-format the disk is not solution+ phrasing implies that there's no recent backup available.

What is this mean CHS and LBA didn't match? I assume this value is needed to be repaired.

CHS is Cylinder, Head and Sector (which is a form of disk block addressing not particularly used on EFI, nor on most any recent computers) and LBA is Logical Block Address. What that diagnostic means, you'll need to discuss with the author of the tool.

From a cursory look, it appears that the GPT disk partitioning table is corrupted. Given a native EFI environment normally automatically detects and recovers from a corrupted GPT by restoring a copy from the alternate GPT that's usually present on an EFI disk, what's going on here is not clear.

Presuming no current backup, you're going to want to learn how the GPT and the partitions are structured on the disk media (the Intel and UEFI folks have low-level EFI specifications here), and you'll probably want to work with the author of that diagnostic tool to recover your data, or potentially to engage and work with a data recovery firm or somebody that can get access to the disk structures and have a look at what went wrong, and at what is left.

And if something "strafed" the disk with some rogue writes, then all bets are off.

Before making any modifications, dd this whole disk somewhere.

Reply

Answer 3

Linc Davis

Level 10

209,739 points

Mar 4, 2011 4:55 PM in response to MrHoffman

+What that diagnostic means, you'll need to discuss with the author of the tool.+

Whatever it means, it's not what's keeping his volume from mounting. He has three HFS partitions, two with the same fault (if that's really what it is), and only one that doesn't mount.

+... to engage and work with a data recovery firm or somebody that can get access to the disk structures and have a look at what went wrong, and at what is left.+

This. A guy who doesn't even make backups is not going to solve this problem by Googling or booting from a Linux CD. He's been at it for two weeks. All he's going to do is destroy whatever chance he has of recovering any data. He's already deleted the journal, a destructive and pointless act. And dd won't save him if the disk is malfunctioning.

Reply

Answer 4

MrHoffman

Level 10

146,461 points

Mar 4, 2011 5:19 PM in response to Linc Davis

Yep. You're right. I just looked back at some history here, and at what turns out to be rather detail around what is involved here.

Something is wrong here with the storage hardware or with the connection (or the USB port), and the contents of this drive certainly do appear corrupted.

Usual approach with failed disk hardware is not reformatting, it's wholesale device replacement.

Buggy hardware or failing storage hardware is not typically recoverable, and reformatting a failing device is futile. That often works for a while but (unless you're really lucky) the problems generally return.

The OP might still have some success with somebody that can recover (some) data from the corrupt HFS partitions, assuming those are not sufficiently damaged. That's not usually cheap, though.

And yes, a corrupt GPT can cause all manner of havoc with a disk volume. Been there, created those, and occasionally zonked them with a coding bug. A reformat will clear a corrupt GPT.

Reply

Answer 5

omega8719 Author

Level 1

4 points

Mar 10, 2011 8:40 PM in response to Linc Davis

I only have partial back up burned on DVD. Not everything lost but still..... ;_; :sob :sob
---
OK now I just realized, test disk analyze function in my very first attempt (when I took that screenshot) wasn't complete. It doing another procedure called quick search. It able to search and display whatever-value-number-that-is in first partition. But when it began searching second partition, my disk was ejected. I try again for the second time, it still ejected again.

Probably I will not able to use this fdisk and pdisk as solution because I cannot insert correct value if test disk failed in analyzing value-number of the partition.
Thank you for the reply, guys.
---
I'll just find a way to read my partition before return for warranty. Any idea what is other OS that capable reading HFS+ without adding/purchase another software?
It just about two months old(counted from buying date). Sigh ~600 GB and Data Rescue app didn't help.

Reply

Answer 6

Mar 31, 2011 9:06 PM in response to omega8719

GPT fdisk (gdisk) will automatically look at the two partition tables and if they aren't the same will offer to fix them. There's ample info on the web about gdisk's options. I wouldn't let fdisk touch a GPT partitioned disk, it's for MBR disks only.

Mac OS only uses LBA with hard drives. Internally the hard drive maps those logical block addresses to physical sectors, it's entirely possible mismatches are normal. The drive will take "bad" sectors out of use, keeping the LBA the same, but pointing to a different physical sector from a spare set of sectors.

Reply

Answer 7

MrHoffman

Level 10

146,461 points

Apr 1, 2011 9:29 AM in response to Christopher Murphy

GPT fdisk (gdisk) will automatically look at the two partition tables and if they aren't the same will offer to fix them. There's ample info on the web about gdisk's options. I wouldn't let fdisk touch a GPT partitioned disk, it's for MBR disks only.

GPT disks do include an MBR, the so-called protective MBR. This is usually configured with four partitions of OS-type codes of EF or EE, IIRC.

Mac OS only uses LBA with hard drives. Internally the hard drive maps those logical block addresses to physical sectors, it's entirely possible mismatches are normal. The drive will take "bad" sectors out of use, keeping the LBA the same, but pointing to a different physical sector from a spare set of sectors.

I haven't seen anybody use CHS or ECHS in years. Not outside of some very specialized or legacy environments. The layout of the blocks on the disk surface aren't conducive to using that model any more (as the numbers of sectors present can vary by the track), and given that most everything after the first or second generation of ATA storage allows LBA. All the low-level driver stuff now tosses block numbers at the disk controller, and the disk controller and the disk map that to the particular physical or virtual geometry and figure out where the data with that address is stored, and returns it. SSD geometry, for instance, is entirely synthetic.

As for the GPT, EFI can find and fix what it considered bogus GPTs, which royally twisted some of the OS code I was working with around online disk volume expansions, and also snarled some stuff around non-GPT aware file systems with the copy of the GPT that is located at the highest LBA addresses. (I haven't checked this with the Apple implementation of EFI, but I've met a number of versions of EFI that do (often silently) repair corrupt GPTs. The EFI folks were probably better served by not silently repairing the GPT but rather tossing some diagnostics, but that's another discussion.)

As for the OP, the fix for a corrupted disk volume structure is to get the data off of the disk (quite possibly with the brute-force dd approach, if there's no current backup), and to then reinitialize and reload the disk volume. The dd gets you a copy of whatever is out there before repairs are attempted.

And to the OP, if you want to learn about the GPT structures, go have a look at the Intel EFI site or the UEFI forum sites. The details on the GPT structures are in the EFI specifications there.

Reply

Answer 8

Linc Davis

Level 10

209,739 points

Mar 4, 2011 2:38 PM in response to omega8719

+Re-format the disk is not solution.+

Yes, it is.

Reply