Partitionstabelle wiederherstellen, geht das?

Hallo,

Ich habe mir gestern leider die Partitiontabelle auf meinem MBP teilweise zerschossen (genaugenommen die ersten vier sind futsch). Nun bootet er nicht mher, bzw. nur von der Install-DVD

Ich fahre auf dem MBP OSX und Linux. Die erste Partition ist die übliche (unter OSX unsichtbare) EFI-Partition, dann die OSX Partition und zwei Linux-root-Partitionen. Die folgenden Partitionen (Linux-swap und home) sieht Diskutil noch. Leider habe ich die genauen Größen der Partitionen nicht mehr. Ich kann sie also nicht mehr einfach in diskutl anlegen.

Gibt es eine Möglichkeit zumindest die EFI und OSX-Partition zu recovern? (die Linux partitionen könnte ich dann neu installieren, die home-Partition ist ja noch da).

Im Terminal der Installation-DVD habe ich noch ein Program names gpt entdeckt. Laut usage-Zeile scheint das ein Äquivalent zu pdisk bei den ppc-Macs mit dem Apple-Partitionschema zu sein. Weiss jemand wie man die bedient. Ich kann leider keine man-page finden.

BTW: Passiert ist das als ich Xen installieren wollte, um damit ein wenig zu experimentieren.
Dabei hat der grub offenbar Mist gebaut.

Bis dann

R"udiger

also GRUB wird das nicht gewesen sein...
schau mal auf http://refit.sourceforge.net/myths/

"man gpt" gibt dir doch die man page im terminal (ist eventuell nicht ausgepackt auf der DVD)...
online findest du die z.B. da:
http://www.hmug.org/man/8/gpt.php

Hallo

Danke erstmal. So einen Link hatte ich gesucht (auf der instalaltion-DVD scheinen die man pages im Installations system zu fehlen und ein anders MacOS X hab ich gerade nicht zur Hand).

Die gut Nachricht ist nun, dass die Partitionen offenbar noch in der Tabelle stehen.
Aber offenbar erkennt er sie trotzdem nicht? Irgendwelche Ideen woran das liegt?

Zur Partitionstabelle fällt mir folgendes noch auf.
Jede Zeile besteht aus 6 Spalten:
1. Startzeile
2. Größe
3. Nummer
4. dem String "GPT part"
5. einem "-"
6. eine Zahl, die eine UUID sein könnte:
bei den Partitionen 1-4: C12A7328-F81F-11D2-BA4B-00A0C93EC93B
bei den Partition danach: EBD0A0A2-B9E5-4433-87C0-68B6B76299C7

Wenn ich die man-apge richtig verstehe, wir dbei gpt-Tabellen, der Partitiontyp in der UUID gespeichert. Könnte es sein, das Grub das was zerschossen hat?

Bis dann

R"udiger

ich denke mal da hat irgendwas den protective MBR zerschossen...

rEFIt hat doch eine util names gptsync, die macht dir einen MBR nach der GPT tabelle...
probier die doch mal...

Hallo,

Ins refit komm ich leider nicht rein, weil die das EFI schon die OSX-Partition, wo refit liegt nicht findet (sonst könnte er ja auch davon booten).
Das gptsync.efi ist leider auch nur ein EfI-binary und keine OSX-Binary, das ich vom Installationsystem aus starten könnte.

Im Übrigen, wozu braucht die EFI eigentlich den protective MBR? Ich dachte die würde direkt über die GPT-Tabelle gehen. Und der MBR den refit einrichtet würde nur von Linux-Boot-loader bzw. refit gebraucht?

Bis dann

R"udiger

den protective MBR gibt es für die rückwärts-kompabilität und halt zum schutz der GPT daten, die dich direkt dahinter befinden. daher der beiname protective.
steht auch im myths-artikel erläutert...

dann lies halt die GPT daten aus und bastel dir einen MBR damit...

Hallo,

Ich habs gelöst und ahne was am Anfang schiefgelaufen ist.

Zur Lösung:

Wie oben geschrieben waren die Partitiontypen/UUIDs der Partitionen 2-4 falsch. Wie einem der wikipedia Artikel dazu verrät, wird der Parttionstyp bei GPT in der UUID gespeichert. Die Partitionen 1-4 standen auf EFI-System-Partition (was nur für die 1. richtig sein dürfte). Insbesonderebei der Partition 2 mit OSX/hfs ist dies falsch. Dadurch hat das/die EFI kein bootbares (d.h. OSX) System finden und auch das refIt, das ebenfalls auf dieser Partition liegt, nicht finden.

Gefixt habe ich das indem ich mit im Terminal mit gpt zunächst die OSX Partition aus der GPT gelöscht habe:

gpt remove -i 2 /dev/disk0

Danach habe ich eine Partition mit genau denselben Größenparametern aber dem Type hfs neu angelegt:

gpt add -b STARTBLOCK -s LÄNGE -i 2 -t hfs /dev/disk0

Glücklicherweise darf man die UUIDs für hfs, ufs, efi, Linux und windows Partitionen bei dem tool gpt abkürzen (siehe die von dir genannte man page).


Wie ist es nun dazu gekommen?
Wenn ich mich richtig erinnere habe ich zwei Versuche gemacht, grub zu installeiren. Offenbar hat der erste (bei den Default-Paramter der oepnSuSE 10.3) den PMBR zerschossen (das hab ich schon früher erlebt) und bei zweiten Versuche (ohne zwischenzeitlichen reboot und gptsync) die GPT verändert.

Nun, nachdem ich weiss wo es hackt werde ich noch weitere Versuche unternehmen grub udn Xen zum Laufen zu bekommen.

Danke für deine Hilfe.

Bis dann

R"udiger

EDIT: hat sich erledigt

rgoetz:

konntest Du die Partitionen herstellen ohne Datenverlust zu erleiden? Habe das gleiche Problem allerdings mit Apple Partitionstabelle und 10 Partitionen. Konnte mit Testdisk die Partitionen ausmachen. Weiss nur nicht wie ich mit den Werten und dem pdisk Befehl weiterfortfahren soll. Einer eine Idee ???

habs gelöst. hat man ursprünglich eine hd mit guid partitionstabelle angelegt, erledigt testdisk das komplett von alleine ohne fehlermeldungen. erscheint die meldung "write_part_mac not implemented" heisst das, das es sich um eine hd mit apple partitions schema handelt. dann nimmt man sich pdisk (terminalbefehl) zur hilfe und schreibt mit hilfe der sektor informationen, die testdisk ausgegeben hat, die partitions tabelle neu und alle dateien sind wieder da als wäre nichts passiert. ich empfehle die zerstörte hd mit data rescue auf eine andere hd zu clonen(mit all ihren fehlern) und die oben beschriebene methode auf die neue hd anzuwenden. so habe ich es gemacht und konnte alles retten. hier der link
mit einer detaillierten beschreibung: http://www.cgsecurity.org/wiki/Merkmale_von_Betriebssystemen#MacOS