OS X hat meine HFS + -Partition nicht mehr erkannt, als ich zuvor eine neue Partition erstellt hatte

655
Sirap

Ich habe ein 2-TB-USB-Laufwerk, das GPT verwendet, aber OSX (10.11.4) auf meinem Macbook Pro (Anfang 2015) erkannte meine HFS + -Partition nicht mehr, nachdem ich zuvor eine Partition auf der Festplatte eingelegt hatte.

Das hatte ich ursprünglich und OSX listete alle Partitionen korrekt im Finder auf:

[ Elements | Extra Fett | | Time machine ]  [ NTFS | ExFAT | Unallocated | HFS+ ] [ ~1500 | 97 | 97 | 167 ] (GB) 

Das Laufwerk hat derzeit das folgende Layout (ich habe Elemente verkleinert und TESTPART erstellt):

[ Elements | TESTPART | Extra Fett | | Time machine ]  [ NTFS | FAT32 | ExFAT | Unallocated | HFS+ ] [ ~1350 | 150 | 97 | 97 | 167 ] (GB) 

... aber das sieht OSX (listet nur die ersten drei im Finder auf):

[ Elements | TESTPART | Extra Fett | | ? ]  [ NTFS | FAT32 | ExFAT | Unallocated | ? ] [ ~1350 | 150 | 97 | 97 | 167 ] (GB) 

Was ist passiert? Ich dachte, diese Operation wäre auf einem GPT-Laufwerk kein Problem.


Extra Details

Ubuntu gdisksagt, dass es GPT mit einem schützenden MBR verwendet, und sowohl gdisk als auch gparted listen alle Partitionen ohne Probleme auf. Der Windows 10 Partition Manager listet auch alle Partitionen auf und sagt, dass das Laufwerk GPT verwendet.

Wenn ich diskutil listunter OSX laufe, bekomme ich:

/dev/disk2 (external, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *2.0 TB disk2 1: Microsoft Basic Data Elements 1.5 TB disk2s1 2: Microsoft Basic Data Extra Fett 104.9 GB disk2s2 3: Microsoft Basic Data 167.8 GB disk2s3 4: Microsoft Basic Data TESTPART 157.3 GB disk2s4 

Es gibt ein paar Probleme, die mir dabei einfallen:

  • Der nicht zugeordnete Speicherplatz wird nicht aufgelistet.
  • Die Partitionen werden definitiv in der falschen Reihenfolge aufgeführt .
  • Das HFS + -Volume # 3 (meine Zeitmaschine), das zuvor immer für OSX sichtbar war, hat sein Label verloren und wird als Microsoft-Grunddaten aufgeführt. Es wird nicht mehr im Finder oder Disk Utility angezeigt. Dies geschah, seit ich Elemente schrumpfte. Ich habe TESTPART im resultierenden Space erstellt (in Win10).
2

1 Antwort auf die Frage

3
Rod Smith

Unallocated space not appearing is not really a problem; many programs, including gdisk and diskutil, display only partitions, not unallocated space. Tools like GParted and cgdisk explicitly show unallocated space (although I think even GParted omits unallocated space below a certain size).

There are two ways to define partition order: The order on the disk of the partitions themselves and the order in which pointers to the partition exist in the partition table. It's least confusing if these two orders match, but there's nothing in GPT (or MBR primary partitions) to enforce this. Thus, out-of-order partitions are common and do not necessarily signify a problem. Don't worry about that detail.

Thus, the only real problem you're reporting is that your HFS+ volume has become inaccessible. This might be a partition table problem, but it's more likely to be a filesystem problem. Unfortunately, without detailed before-and-after information on partition start points, I can't differentiate the two possibilities. The safest way to proceed is:

  1. Do a low-level backup of the partition with dd in either OS X or Linux, as in sudo dd if=/dev/disk2s3 of=/path/to/lots/of/space/disk2s3-backup.img. This will preserve the data in the partition in case the next step makes things worse, which is a real possibility. You should also back up the partition table as it is now by using the b option on gdisk's main menu.
  2. Use OS X's Disk Utility to repair the partition. The GUI tool should be able to do this. I'm less familiar with the OS X command-line tools to do this, but in Linux it would be fsck, and it might be the same in OS X.
  3. If this doesn't work, restore the backup you made in step #1 by reversing the if= and of= options.

If that doesn't work, I do have another few suggestions:

  • You could delete the errant partition and try using TestDisk or something similar to recover it. The idea here is that whatever you used to modify your partitions might have adjusted the start point of your HFS+ partition, which would render it inaccessible. TestDisk scans for filesystems and creates new partition table entries for them, which should fix that problem. This isn't a sure thing, though.
  • Re-create the partition and restore its files from a backup.
  • If that fails, restore the original partition (by re-creating it using the exact start and end points it has now or by restoring the gdisk partition table backup) and use PhotoRec, or a similar tool, to recover the partition's contents on a file-by-file basis. This will be much more tedious than restoring files from a backup, and you're unlikely to recover everything, but with any luck you'll be able to recover most of the files.

It might be helpful to know what tool you used to resize the NTFS partition and create a new one. Although I don't know of any bugs in common utilities that would produce this exact symptom, I certainly trust some partitioning tools more than others. (The standard Windows utilities are very buggy with extended/logical partitions on MBR disks, for instance -- but yours is a GPT disk, so that's not really an issue.)


EDIT:

I just noticed something about your description: What should be an HFS+ volume is marked as being of type "Microsoft Basic Data" by diskutil. That's Just Plain Wrong. It's easily fixed with gdisk:

  1. Launch gdisk on the disk.
  2. Type p to view the partition table and positively identify the partition that can't be accessed. I expect it to be partition 3, but it's best to be sure.
  3. Type t to change the type code. You'll be asked for a partition number.
  4. Type 3 (or whatever the appropriate number is, as just identified).
  5. When prompted, enter a type code of AF00.
  6. Type w to save your changes. (You'll be asked for verification.)

This should fix the problem. (If you do it from OS X, you may need to reboot.) There's a chance that you'll need to enter AF05 rather than AF00 as the type code, so if it doesn't work, try repeating that process, but with that change.

Other tools can probably fix it, too, but I'm not familiar with the procedures, offhand. (Maybe removing the "msftdata flag" in parted or GParted would do it....)

Bis ich nach Hause komme und diese Antwort verdauen kann, möchte ich mich einfach bei Ihnen bedanken. Du bist immer sehr hilfsbereit. Ich musste Details auslassen, um eine Wand aus Text zu vermeiden, aber Sie haben Recht, ich habe den Windows 10-Partitionsmanager verwendet. Es identifizierte es korrekt als GPT-Datenträger und sah aus, als hätte es jede Partition richtig erkannt. Ich nahm an, dass es das beste Werkzeug für die Änderung der Größe von NTFS ist. Ich verstehe, wie diese Annahme falsch sein könnte. Sirap vor 8 Jahren 0
Bitte sehen Sie meine Bearbeitung oben; Ich habe etwas bemerkt, das ich bei meinem ersten Lesen übersehen hatte, und dies führt zu einer wahrscheinlichen Korrektur. Rod Smith vor 8 Jahren 0
Das Ändern des Typencodes in AF00 war der Trick. Ich weiß nicht, warum Windows 10 es für eine gute Idee hielt, eine nicht verwandte Partition wie diese zu ruinieren, aber ich denke, ich muss mir keine Sorgen machen, da ich dieses Microsoft-Dienstprogramm nie wieder verwenden werde. Sirap vor 7 Jahren 0