1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen
  2. Unsere jährliche Weihnachts-Banner-Aktion hat begonnen! Wir freuen uns auf viele, viele kreative Vorschläge.
    Mehr dazu könnt Ihr hier nachlesen: Weihnachtsbanner 2016

    Information ausblenden

Problem beim Erstellen einer zweiten für Windows sichtbaren Partition

Dieses Thema im Forum "Windows auf dem Mac" wurde erstellt von silv2222, 19.01.08.

  1. silv2222

    silv2222 Idared

    Dabei seit:
    11.12.06
    Beiträge:
    29
    Hi,

    ich hab ein Problem und hoffe ich bin im richtigen Unterforum gelandet.


    Also...
    Ich hab ne externe Festplatte die ich mit dem FDP nach GUID partitioniert habe.
    1. Partition ist HFS mit bootbarem Abbild der internen Festplatte
    2. Partition ist eine FAT32 Partition, die ich in Windows auf NTFS umformatiert habe, wegen 4 GB Begrenzung
    3. Partition ist eine FAT32 Partition für Daten die auf beidene Betriebssystemen gebraucht werden.

    Das Problem ist, dass Windows nur die NTFS Partition sieht und die FAT32 Partition als nicht partitionierten Bereich ansieht. Das liegt, wie ich vermute daran, dass Windows nichts mit GUID Partitionstabellen anfangen kann.

    Wie kann ich jetzt die FAT32 Partition sichtbar machen? Darf ich mit dem Windows Partitionstool den nichtpartitonierten Bereich einfach in eine Partition umwandeln oder führt das zum Datengau?

    Hab leider nix passendes mit der Suche gefunden.

    Gruß,

    silv2222

    P.S.: Kann das FDP von Leopard zwei HFS Partitionen zusammenschmeißen, ohne das die restlichen Partitionen dabei gelöscht werden, weil unter Tiger geht das nicht.
     
  2. quarx

    quarx Hadelner Sommerprinz

    Dabei seit:
    17.04.05
    Beiträge:
    8.541
    Bingo. Ohne MBR-Partitionstabelle braucht man als Festplatte bei Windows gar nicht erst anzutanzen. Eine Mac-bootbare Partition und eine Windows-lesbare Partition auf der gleichen Platte schließen sich gegenseitig aus. Einzige Alternative, die ich da sehe: benutze unter Windows MacDrive.
     
    #2 quarx, 19.01.08
    Zuletzt bearbeitet: 19.01.08
  3. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    Die Vermutung ist richtig.
    Wenn du die Aufteilung aber wirklich mit dem FP-DP vorgenommen hast, sollten sich die ersten drei Datenpartitionen auch in der zusätzlich vorhanenen MBR-Tabelle wiederfinden.
    Du hast nicht vielleicht doch was anderes benutzt?

    Zuerst eine Gegenfrage: Wie fit fühlst du dich fürs Terminal?

    Letzteres. DatenGAU ist unausweichlich.
    Partitionierungstools aus der Windows- oder Linuxwelt sind ungeeignet.
     
  4. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    Nicht im geringsten. Es ist nur so, dass ein Mac sein Startvolume in HFS+ haben will, die Volumes im HFS+ Format für Windows aber nur "Bahnhof" sind. Weitere Partitionen im FAT-Format sind aber durchaus machbar.
     
  5. quarx

    quarx Hadelner Sommerprinz

    Dabei seit:
    17.04.05
    Beiträge:
    8.541
    Ok, über die MBR-Emulation geht's, stimmt. Das kommt davon, wenn man keinen Intel-Mac hat.
     
  6. silv2222

    silv2222 Idared

    Dabei seit:
    11.12.06
    Beiträge:
    29
    So, muss zugeben, dass ich etwas verschwiegen habe... habe natürlich nicht dran gedacht, dass es dieses Problem verursacht.

    ich hab die Partitionen wirklich mit dem FDP gemacht, aber ich hab hinterher nochmal neu partitioniert:
    1. Partition ist HFS mit bootbarem Abbild der internen Festplatte
    2. Partition für Time Machine
    3. Partition ist eine FAT32 Partition, die ich in Windows auf NTFS umformatiert habe, wegen 4 GB Begrenzung
    4. Partition ist eine FAT32 Partition für Daten die auf beidene Betriebssystemen gebraucht werden

    Die 4. wird vermutlich nicht angezeigt, da der MBR nicht mehr als 3 primäre Partitionen haben darf.

    Sorry!

    Ok, gibt es ne Möglichkeit, die erste und zweite Partition zusammenzuschmeißen und ohne das die ganze Partitionstabelle neu schreiben zu müssen? Is ja ehh überflüssig, wie ich jetzt gelesen habe, da man von einem Time Machine Volumen auch mit Leopard-CD Booten kann.

    Achja, Terminal zu verwenden geht schon.

    Grüße,

    silv
     
  7. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    Der MBR darf 4 davon haben, aber die erste wird bereits vom EFI Schutzbereich verwendet. Bleiben also 3 nutzbare für alle Betriebssysteme, die auf ein BIOS aufsetzen. Für EFI-konforme Systeme wie OS X liegt die Standardgrenze bei 128 Stück (minus eins für EFI, wer meint noch mehr zu brauchen kann sich auch 10000+x einrichten).
    Man kann auch -wie bei PCs üblich- mit sog. "erweiterten Partitionen" und "logischen Laufwerken" im MBR mehr einrichten, aber das geht nur in diffizilster Handarbeit, die gängigen Tools unterstützen das allesamt (noch) nicht.
    "Diffizil" bedeutet in diesem Kontext: Für Leute, die 0xBC und 0xAF mal eben schnell im Kopf addieren und die Frage nach der Uhrzeit in binär beantworten. Naja, fast... :)
     
  8. silv2222

    silv2222 Idared

    Dabei seit:
    11.12.06
    Beiträge:
    29
    Was heißt schnell? So nach nach 1-2 Minuten hät ich das schon, aber dann gibts keine Gewähr auf Richtigkeit :)

    Ok, is klar. Kann das FDP von Leopard die beiden Partitonen wieder zusammenführen ohne Tabula Rasa zu machen?

    Gruß,

    silv
     
  9. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    Na wenn das so ist...
    Ein:
    Code:
    diskutil list
    verrät dir etwas über die aktuell bestehende Zuordnung von /dev/disk Nodes zu physischen Geräten. Deine interne HD wird meistens mit der 0 bedient werden. (Verlass dich da aber nie drauf, das geht bei BSD dynamisch!)
    Ein:
    Code:
    sudo gpt -r show /dev/disk[I][COLOR="DarkRed"]n[/COLOR][/I]
    ...zeigt dir die GUID Tabelle, ein:
    Code:
    sudo fdisk /dev/rdisk[COLOR="DarkRed"][I]n[/I][/COLOR]
    # hier das kleine 'r' beachten!
    ...spuckt den dazugehörigen MBR-Kokolores aus. Lass doch mal sehen...?
     
  10. silv2222

    silv2222 Idared

    Dabei seit:
    11.12.06
    Beiträge:
    29
    Ok,

    hier ist die GUID Tabelle
    Code:
    gpt show: /dev/disk1: Suspicious MBR at sector 0
          start       size  index  contents
              0          1         MBR
              1          1         Pri GPT header
              2         32         Pri GPT table
             34          6         
             40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
         409640  125566976      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
      125976616     262144         
      126238760  398196736      3  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
      524435496     262144         
      524697640   73400320      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
      598097960  378413024      5  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
      976510984     262151         
      976773135         32         Sec GPT table
      976773167          1         Sec GPT header
    
    und hier ist er MBR
    Code:
    Disk: /dev/rdisk1       geometry: 60801/255/63 [976773168 sectors]
    Signature: 0xAA55
             Starting       Ending
     #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
    ------------------------------------------------------------------------
     1: EE 1023 254  63 - 1023 254  63 [         1 -     409639] <Unknown ID>
     2: AF 1023 254  63 - 1023 254  63 [    409640 -  125566976] HFS+        
     3: AF 1023 254  63 - 1023 254  63 [ 126238760 -  398196736] HFS+        
     4: 07 1023 254  63 - 1023 254  63 [ 524697640 -   73400320] HPFS/QNX/AUX
    
    Achja, auf den ersten beiden Partitionen mit HFS können die Daten flöten gehn. Nur die andren beiden wärn wichtig.
     
  11. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    Ich darf dir schmunzelnd mitteilen, dass deine FAT-Partition in Wirklichkeit eine HFS+ Partition ist.
    Da hast du dich wohl vertan. So kann das nicht klappen. :)

    Ich mach dir jetzt mal ein paar Vorschläge, such dir den aus der dir am besten gefällt:

    Möglichkeit A)
    Ich lasse dir beide Mac-Partitionen bestehen, also die mit dem System und auch die zweite. Diese werden aber so präpariert, dass sie unter Windows vollständig blockiert sind (also dort auch nicht gelöscht werden können). Sowohl die NTFS- als auch die (korrigierte) FAT-Schwarte werden in Windows wie ursprünglich erwartet voll verwendbar sein.

    Wenn du diese Option wählst, gibt es absolut keine Möglichkeit, von Windows aus auf deine Mac-Partitionen zuzugreifen, auch mit einer Zusatzsoftware wie zB "MacDrive" nicht. Unter einem beliebigen Linux ebenfalls nicht (auch wenn man dir da was anderes versichert, das darfst du nicht glauben).
    Es wird so sein, als gäbe es gar keine Mac-Partition, sondern an deren Stelle nur eine einzige riesige "verbotene Zone", die du in der Windows Datenträgerverwaltung nicht manipulieren kannst, weil sämtliche Menüs dort abgeblendet sind.

    Möglichkeit B)
    Du wirfst beide Mac Volumes zu einem zusammen und ersetzt beide durch ein neues, leeres Mac Volume.
    Die FAT Bunze wird korrigiert, so dass du sie nur noch im FP-DP mit "MS-DOS" zu formatieren brauchst. (Für eine FAT-Formatierung unter Windows ist sie erheblich zu gross. Dort ist FAT nur bis 32GB formatierbar.)
    Zugriff auf die Mac-Partition mit MacDrive oder einem Linux LiveCD-System bleiben weiterhin machbar - was ich dir aber unbedingt nur lesend empfehlen kann. Auf HFS unter Linux/Windows zu schreiben sollte nur im theoretischen Notfall praktiziert werden, der aber nie eintreten wird.

    Möglichkeit C)
    (würde ich unbedingt empfehlen, anstatt B, weil...)
    Im Prinzip wie B, nur dass anstatt einer einzigen riesigen FAT-Datenvernichtungsgrube zwei entstehen, mit jeweils der halben Grösse. Das würde ich dringend empfehlen, da auch schon FAT-Volumes mit "nur" etwa 90GB ein ziemlich gewagtes Unterfangen sind. Ein FAT-Volume mit etwa 180 GB, so wie du das einrichten wolltest ist aus Sicht der zukünftigen Betriebssicherheit in etwa das, was ein japanischer Samurai-Krieger mit "Seppuku" bezeichnet.
    Auf Deutsch: Du brauchst dich nicht zu fragen, ob es das irgendwann zerreisst, sondern nur wann.

    Ich kann dir diese Frage vorab beantworten: Wenn der Punkt erreicht ist, an dem du so viele Daten darauf abgelegt hast, dass du beim plötzlichen Verlust derselben am liebsten dein Keyboard wieder zwischen deinen Zähnen herausbekommen möchtest, es sich aber zu fest darin verkeilt hat. Deine Krankenkasse wird dich im Stich lassen, wenn es soweit ist.

    Möglichkeit D)
    Eine Kombination aus A und C.
    Also kein sichtbares Mac-Volume mehr, obwohl beide unter OS X weiterhin unverändert existieren. Die verunglückte FAT Partition wird aber in zwei Hälften geteilt. Unter Windows wirst du also eine Sperrzone, ein NTFS-Luder und zwei in vernünftiger Grösse angelegte FAT-Tanten sehen.

    Eins sollte dir in allen vier Fällen im klaren sein:
    Das Festplattendienstprogramm von Leopard wird NICHT mehr in der Lage sein, diese Partitionierung "verlustfrei" zu ändern. Versuchst du es, kracht es im Karton. Also musst du dich jetzt dauerhaft festlegen. (Weil das alles weit abseits der Möglichkeiten ist, die das Programm bis jetzt beherrscht. Da kannst du nur das erfolgreich bearbeiten, was das Programm selbst erschaffen hat, auf Handarbeit ist das mental nicht genügend vorbereitet.)

    So, lieber Karl-Heinz, wer soll nun dein Herzblatt sein?
    Oder hast du noch weitere Mädels am Start, die man jetzt noch ins Spiel bringen könnte?
     
  12. silv2222

    silv2222 Idared

    Dabei seit:
    11.12.06
    Beiträge:
    29
    hm man... ich bin heut vielleicht ne Trantüte.... natürlich ist das eine HFS+ Partition... hab mir gedacht, wenn Windows die FAT32 ehh net lesen kann, dann kann ich sie auch HFS+ formatieren.

    Ok, also ich hab jetzt meine Daten doch noch auslagern können. Hab mir ne externe von meiner Schwester geliehen.

    Ich könnte jetzt die Externe komplett löschen. Das Problem bleibt aber irgendwie... oder gibt es ne andre Möglichkeit für ne Platte mit ca. 200 GB die auf beiden Betriebssystemen laufen muss außer FAT32 oder NTFS mit dem 3G Treiber, der entweder langsam ist oder mit der ublio-Version eventuell Fehler produziert.
    MacDrive kommt nicht in Frage, da ich andren Leuten das nicht zumuten kann, das Ding zu installieren.

    Zu was würdest du mir raten? NTFS-3G oder FAT32 mit 2 x 90 GB?

    Also was ich gern haben würde, wär entweder:
    1. und 2. HFS+ Partition zu einer zusammen, NTFS Partition bestehn lassen und die 3. HFS+ zu 2 FAT32 Partitionen aufteilen.

    oder

    1. und 2. HFS+ Partition zu einer zusammen und dann eine große NTFS Partition. Das könnte ich dann wahrscheinlich auch recht einfach über das FDP machen.

    Auf jeden Fall erstmal herzlichen Dank für deine Hilfe!!!

    Grüße,

    silv
     
  13. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    Nein. Es sei denn du bist bereit ein wenig Geld in MacDrive zu investieren, dann kannst du HFS/HFS+ unter Windows (fast) normal benutzen. Im Gegensatz zu NTFS sind HFS und HFS+ nämlich voll dokumentiert und frei verwendbar. Also gibts dafür auch brauchbare Treiber für Fremdsysteme. Andersrum bleibts aber Essig, und zwar vermutlich so lange bis MS was neues benutzt, dann geht alles schon wieder von vorne los.... o_O

    NTFS-3G ist in einem Stadium, das ich als Maintainer bestenfalls grade mal aus dem Alpha-Stadium entlassen hätte. Ich hatte zuletzt die Versionen von ungefähr Anfang Dezember im Test und das Ergebnis war ein totales Desaster. Sowas für die Massen freizugeben grenzt IMHO an fahrlässige Sachbeschädigung. Die Soft läuft im reinen BSD-Betrieb rudimentär brauchbar, aber die nötigen Anpassungen an die HighLevel-Frameworks von OS X (v.a. Carbon) kann man bis jetzt eher als nicht existent betrachten.
    Das reicht von fehlerhafter Dateinamensumsetzung (keine Umlaute möglich) über eine Blockade des gesamten "diskarbitration"-Subsystems bis hin zur vollständigen Zerstörung der unverzichtbaren Metadatenstruktur von NTFS. Lass auf jeden Fall die Finger weg, wenn du kein aktiver Entwickler/Tester in diesem Bereich bist! Ein "early adopter" zu sein haben schon viele mit Tränen bezahlt.

    Ok, Ok, du willst die Stulle in der DoppelFATstufe.

    Aber vorher ein paar allgemeine Dinge:
    Während der folgenden Aktionen darf *kein* Volume von der HD gemountet sein. Nur solange *alle* Volumes auf der Disk entladen (grau hinterlegt) sind, kannst du Kommandos absetzen, die was an der Partitionierung ändern.
    Solange irgendwas auf der Disk geöffnet (sprich: gemountet) ist, bleibt die Partitionstabelle vom Kernel rigoros geschützt und kann nicht geändert werden. (Sicherheit rulez - das ist unter Linux nicht so, also nicht wundern wenns mal zu "klemmen" scheint.)

    Nach der einzelnen Ausführung der diversen Kommandos kann es sein, dass das System sich dazu berufen fühlt, sofort wieder alles zu mounten was irgendwie mountbar erscheint. (Das wird normalerweise ja auch so erwartet...)
    Das kann ziemlich nervig sein, aber bei den paar Änderungen wirst du es überleben, nach jedem Befehl ggf. kurz ins Dienstprogramm zu schalten und die aktiven Volumes erneut zu deaktivieren.
    Wirf aber dabei nicht aus Versehen die ganze Platte aus, sonst ist sie...ganz weg. Logo?

    Dann wäre noch zu sagen, dass du für Änderungen an internen HDs root-Rechte benötigst, also für jedes Kommando "sudo" benutzen musst. Bei externen Disks oder Imagedateien genügt es dagegen, derjenige User zu sein, der das Gerät gemountet hat bzw. gerade lokal angemeldet ist (sprich: "Konsolenbenutzer"). Ich schreibe das daher später nicht mit hin, du weisst Bescheid. (In manchen Sitationen kann es vorkommen, trotzdem sudo einsetzen zu müssen, zB bei gerade aktiver "schneller Benutzerumschaltung" usw...)

    Zur generellen Vorgehensweise, die du immer penibel einhalten musst, wenn du irgendwas mit diesen CLI-Tools an einer GPT-Tabelle machen möchtest (für später merken):

    - Zuerst musst du den MBR sichern (als Dateikopie UND in Form der Textausgabe der verwendeten Programme, so wie du das schon gemacht hast). Du wirst beides später noch brauchen. Das muss ich hoffentlich nicht erwähnen, dass du diese Dateien günstigerweise nicht ausgerechnet irgendwo auf der gleichen Platte speichern solltest, die du gleich beackern willst, oder?
    Ich wills nur mal gesagt haben...

    Ein Backup der GPT-Tabelle gleich mit zu sichern wäre eine ziemlich intelligente Sache.
    Wieviel du dabei sichern musst, kann variieren. Normalerweise sind es die ersten 34 Sektoren der Disk. Das "gpt -r show <device>" Kommando das du schon benutzt hast, verrät dir im Zweifelsfall wie weit die Partitionstabelle reicht.
    Die Backup-Tabelle am Ende der Disk ebenfalls zu sichern ist nicht doof, aber auch nicht unbedingt notwendig.

    - Anschliessend musst du den MBR der Disk beseitigen, und zwar am besten wirklich vollständig.
    Solange der existiert, verhält sich das "gpt" Programm nämlich wie eine Glucke und hindert dich an deinem Tatendrang, indem es unbedingt alles "noch richtiger" machen will als du. Das Resultat wäre eine GPT Tabelle die zwar EFI-konform ist, aber irgendwie trotzdem nicht brauchbar.
    Also: Hau wech' den Sch...

    - Dann nimmst du nacheinander alle gewünschten Änderungen an der GPT vor (mit "gpt"). Diese Änderungen geschehen "in Echtzeit" - kein "Undo". Be careful.

    - Anschliessend ist die MBR Partitionstabelle neu aufzubauen - mit "fdisk".
    fdisk besitzt im Gegensatz zu gpt einen interaktiven Modus, bei dem Änderungen erst auf Wunsch geschrieben werden. Hier kannst du also bei Fehlern oder galoppierender Ratlosigkeit noch mal abbrechen und neu beginnen.

    - Dann ist es Zeit, einen evtl. vorhandenen Bootloader im MBR zu reanimieren. fdisk kann zwar einen für dich installieren (aus dem Darwin-Paket), aber für ein Windows solltest du grundsätzlich den Windows-eigenen Code verwenden. (Sogenannte "Virenscanner" könnten sonst ausflippen)
    Hier ist das Backup gefragt.

    - Zuletzt musst du prüfen, ob die Disk schon einen "Drive Identifier" für WinNT besass. Wenn nicht, erfindest du einen. Wenn ja solltest du ihn übernehmen, sonst verwürfelt Windows seine zugeordneten Laufwerksbuchstaben. Zu beachten ist, das Windows NIEMALS zwei verschiedene Platten mit dem gleichen Identifier sehen darf, sonst passiert... "verwirrendes". Milde formuliert. Und Windows MERKT sich diese Nummern wie ein sturer Elefant. Hat Windows erst ein mal zwei "gleiche" Disks verortet, fühlt sich die Windows Aktivierung durch einen Klon hintergangen und reagiert evtl. entsprechend. Und das nicht nur ein mal, sondern zur allgemeinen Erheiterung zwischendurch immer wieder mal... einfach toll, sowas. Noch feiner ist es wenn die Platte Windows-bootfähig ist und du änderst nur diese unscheinbare Nummer - das mit dem Booten kannst du vergessen und neu installieren... suuuuuper! :)

    - Dann solltest du die Daten von GPT und MBR nochmals sehr sorgfältig vergleichen. Eine auch nur minimale Diskrepanz hätte böööööse Folgen. Du weisst sicher, wie schnell mal eben ein Zahlendreher übersehen ist?

    - Stimmt alles, kannst du die Volumes jetzt wie gewünscht einzeln formatieren und benutzen.

    Also, los gehts.
    Platte ran und Terminal auf, aber zuerst ins Festplatten-DP, alle Volumes deaktivieren.
    Hier kannst du in den Informationen zur Festplatte sehen, welche Nummer zugewiesen ist - du kennst das schon. Der Wert findet sich gleich in der ersten Zeile unter "Medien-Identifikation".
    Die Ziffer am Ende musst du einfach nur dort eintragen, wo ich ein x setze.
    Code:
    [COLOR="Sienna"]# Etwas Vorbereitung[/COLOR]
    blockdev=/dev/disk[COLOR="Blue"]x[/COLOR] 
    rawdev=/dev/rdisk[COLOR="Blue"]x[/COLOR] 
    fldr="${HOME}/Desktop/Festplattendaten"
    mkdir -pm 755 "$fldr"
    cd "$fldr"
    
    [COLOR="Sienna"]# MBR und GPT sichern
    ## in Textform[/COLOR]
    fdisk $rawdev >> fdisk_out.txt
    gpt -r show $blockdev >> gpt_out.txt
    [COLOR="Sienna"]## und als Dateikopie[/COLOR]
    dd if=$rawdev count=34 of=dump.data
    
    [COLOR="Sienna"]# Tod allen MBRs dieser Welt
    # Hölle, Hölle, Hölle[/COLOR]
    dd if=/dev/zero count=1 of=$rawdev
    sync
    
    [COLOR="Sienna"]# BONUSTRACK
    # Alte HFS Partitionen "entwerten"
    # da wird nichts mehr automatisch mounten
    # und nerven... bestimmt NIE wieder
    # OBACHT:
    # Nicht daneben feuern,
    # das macht DICKE Brandflecken im Teppich[/COLOR]
    dd if=/dev/zero bs=4096 count=4096 of=${rawdev}s2
    dd if=/dev/zero bs=4096 count=4096 of=${rawdev}s3
    dd if=/dev/zero bs=4096 count=4096 of=${rawdev}s5
    [COLOR="Sienna"]# Schweigeminute bitte, X ist tot
    # Schon wieder ist ein Apfel vom Baum gefallen :-)
    
    # GPT korrigieren
    ## alte Tabelle komplett entfernen und leer neu erschaffen[/COLOR]
    gpt destroy $blockdev
    gpt create $blockdev
    [COLOR="Sienna"]# EFI Systempartition an alter Position wiederbeleben[/COLOR]
    gpt add -t efi -i 1 -b 40 -s 409600 $blockdev
    [COLOR="Sienna"]# eine neue HFS
    ## Tip: Startaddresse und Länge sollten immer durch 8 teilbar sein[/COLOR]
    gpt add -t hfs -i 2 -b 440000 -s 524238000 $blockdev
    [COLOR="Sienna"]# zwei neue FATs[/COLOR]
    gpt add -t windows -i 4 -b 598116015 -s 189309960 $blockdev
    gpt add -t windows -i 5 -b 787442040 -s 189309960 $blockdev
    [COLOR="Sienna"]# NTFS wiederbeleben[/COLOR]
    gpt add -t windows -i 3 -b 524697640 -s 73400320 $blockdev
    [COLOR="Sienna"]# GPT fertig
    # Kontrolle:[/COLOR]
    gpt -r show $blockdev
    
    [COLOR="Sienna"]# [I]hier versucht das FP-DP wohl die NTFS neu zu laden[/I]
    # [I]also - rüberwechseln und wieder deaktivieren[/I]
    
    # jetzt einen neuen MBR bauen mit fdisk
    # Die in[/COLOR] [COLOR="Red"]rot[/COLOR] [COLOR="Sienna"]geschriebenen Befehle
    # sind Anweisungen [I]innerhalb[/I] von fdisk,
    # also keine normalen Shellkommandos.
    # Das Programm fragt, du antwortest. Unter Eid. :-)
    # (yes und no kann mit y n abgkrzt wrdn usw)
    # das Programm abbrechen geht mit:[/COLOR] [COLOR="Red"]abort[/COLOR]
    
    fdisk -e $rawdev
    
    [COLOR="Sienna"]# Kommt hier eine Warnung wie:
    # ...could not open MBR file blabla...
    # ...einfach ignorieren. Wir wollen gar keinen Bootloader.[/COLOR]
    
    [COLOR="DarkGreen"]# ...like to initialize MBR ?[/COLOR]
    [COLOR="Red"]yes[/COLOR]
    
    [COLOR="Sienna"]# mal gucken[/COLOR]
    [COLOR="Red"]print[/COLOR]
    [COLOR="Sienna"]# ans Werk[/COLOR]
    [COLOR="Red"]edit 1[/COLOR]
    [COLOR="DarkGreen"]# Partition ID ?[/COLOR]
    [COLOR="Red"]EE[/COLOR]
    [COLOR="DarkGreen"]# edit in CHS mode ?[/COLOR]
    [COLOR="Red"]no[/COLOR]
    [COLOR="DarkGreen"]# Offset ?[/COLOR]
    [COLOR="Red"]1[/COLOR]
    [COLOR="DarkGreen"]# Size ?[/COLOR]
    [COLOR="Red"]524677999[/COLOR]
    
    [COLOR="Sienna"]# die Fragen wiederholen sich, daher
    # ab hier nur noch die Antworten... [/COLOR]
    
    [COLOR="Red"]edit 2
    07
    no
    524697640
    73400320
    
    edit 3
    0C
    no
    598116015
    189309960
    
    edit 4
    0C
    no
    787442040
    189309960
    
    flag 2
    print[/COLOR]
    
    [COLOR="Sienna"]# Start- und Längenwerte
    # im rechten Tabellenbereich
    # für die Slots 2, 3 und 4 nochmal mit dem vergleichen,
    # was bei der GPT eingetragen wurde.
    # Die Numerierung ist dort um eins verschoben,
    # aber das macht überhaupt nichts.
    # [B]Wichtig[/B], nicht wundern:
    # Die Werte im Slot 1 (EE, unknown) sind
    # [I][U]absichtlich nicht[/U][/I] identisch mit den GPT-Daten
    # Wenns passt, dann...[/COLOR]
    
    [COLOR="Red"]write
    exit[/COLOR]
    
    [COLOR="Sienna"]# MBR-Tabelle fertig
    # Kontrolle mit:[/COLOR]
    fdisk $rawdev
    
    [COLOR="Sienna"]# Jetzt noch den Bootloader kopieren.
    # Schaden tuts nicht, auch wenn gar keiner da war.
    # Das nächste Kommando geht nur, wenn das getan wurde.
    # also einfach mal machen...[/COLOR]
    dd if=dump.data bs=1 count=446 of=$rawdev
    sync
    [COLOR="Sienna"]# Jetzt die Kontrolle, ob Windows diese Disk schon "kennt"[/COLOR]
    dd if=$rawdev bs=1 count=4 skip=440 | xxd -p
    [COLOR="Sienna"]# Eine Anzeige von nur Nullen besagt: noch unbekannt.
    # Du [I]kannst[/I] dir einen ausdenken, wenn du willst.
    # ansonsten sollte eine sich einfach wiederholende
    # Abfolge von 4 Zeichen (2x16bit Hexcode) kommen.
    # Kommt statt einer Wiederholung ein anderer Salat,
    # [I]muss[/I] ein neuer Wert "erfunden" werden, denn dieser 
    # wurde von Software ?? generiert und ist unter XP vermutl. ungültig.
    # Faustregel für gültige Codes, die 100%ig funzen:
    # Erstes Zeichen ein Grossbuchstabe,
    # zweites Zeichen beliebiger Buchstabe oder Ziffer.
    # Das ganze zwei mal. Beispielsweise so:
    # PePe, G4G4, V1V1, MaMa, RoRo, DUDU .....
    # Deiner Fantasie sei freier Lauf gelassen.
    # Das Applizieren geht so:[/COLOR]
    echo -n "POPO" | dd bs=1 count=4 seek=440 of=$rawdev
    sync
     
    
    
    Du bist fettig. Platte auswerfen, trennen, neu anstecken und das formatieren im FP-DP kann beginnen. Sollte dort irgendwas "merkwürdig" sein, nicht weitermachen, dann muss erst das Backup zurück und alles nochmal versuchen.
    :)
    Happy Plattenverbeuling.
     
  14. silv2222

    silv2222 Idared

    Dabei seit:
    11.12.06
    Beiträge:
    29
    so, bis zum Zeitpunkt, an dem ich den Boatloader wieder reinkopieren soll, geht's eigentlich prima durch. Passt soweit ich das beurteilen kann auch alles.

    Das Problem ist, dass er mir bei
    Code:
    dd if=dump.data bs=1 count=446 of=$rawdev
    ein Invalid Argument ausgibt. Und zwar soll /dev/rdisk1 ungültig sein.

    Schlau wie ich war, wollte ich die Variable rawdev durch /dev/rdisk1 ersetzen. Natürlich hab ich prompt das r vergessen... dann gings zwar... aber ich hab keine Ahnung, ob ich jetzt irgendwas kaputt gemacht habe. Hab ich jetzt teile von der GPT zerschossen?

    Achja, hier noch die Ergebnisse:
    Code:
    gpt show: /dev/disk1: Suspicious MBR at sector 0
          start       size  index  contents
              0          1         MBR
              1          1         Pri GPT header
              2         32         Pri GPT table
             34          6         
             40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
         409640      30360         
         440000  524238000      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
      524678000      19640         
      524697640   73400320      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
      598097960      18055         
      598116015  189309960      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
      787425975      16065         
      787442040  189309960      5  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
      976752000      21135         
      976773135         32         Sec GPT table
      976773167          1         Sec GPT header
    
    Code:
    Disk: /dev/rdisk1       geometry: 60801/255/63 [976773168 sectors]
    Signature: 0xAA55
             Starting       Ending
     #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
    ------------------------------------------------------------------------
     1: EE    0   0   2 - 1023 254  63 [         1 -  524677999] <Unknown ID>
    *2: 07 1023 254  63 - 1023 254  63 [ 524697640 -   73400320] HPFS/QNX/AUX
     3: 0C 1023 254  63 - 1023 254  63 [ 598116015 -  189309960] Win95 FAT32L
     4: 0C 1023 254  63 - 1023 254  63 [ 787442040 -  189309960] Win95 FAT32L
    
    Gruß,

    silv
     
  15. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    Oh nein, nichts passiert.
    Das System hat wohl nur etwas träge aktualisiert, da hätte ich ein "sync" einschieben sollen. Macht aber in dem Fall exakt gar keinen Unterschied.
    Sonst haut alles hin, ja?
     
  16. silv2222

    silv2222 Idared

    Dabei seit:
    11.12.06
    Beiträge:
    29
    Hab jetzt noch den Drive Identifier geändert. Die Befehle gingen aber alle nur mit /dev/disk1.
    Soweit ich das beurteilen kann schaut das Ganze jetzt sehr gut aus. Es werden alle Laufwerke so erkannt, wie sie es sollten.

    Eine letzte Frage hab ich noch: Der Abstand zwischen den Partitionen... ist irgendwie in der Spez. vorgegeben, oder ist der beliebig? das FDP macht den Abstand ja grundsätzlich 128 MB groß. Du hast ihn jetzt jeweils so 9 MB groß gemacht. Was ist der Sinn dahinter?

    Ok...nochmals herzlichen Dank für deine Hilfe. Ohne dich würde ich wahrscheinlich meine Daten irgendwann ins digitale Nirwana schicken.

    Gruß,

    silv
     
  17. Rastafari

    Rastafari Golden Noble

    Dabei seit:
    10.03.05
    Beiträge:
    17.896
    Na sieh mal an. Apple renoviert seine Treiber ja doch ab und an mal. Diese kleine Schnippigkeit ist mir neu. Taucht wohl nur auf, wenn man Sektoren teilweise beschreiben will. Mal ein Auge drauf klemmen.

    Genau, das entspricht Apples *Empfehlungen*. Pflicht ist das nicht. Apple geht hier mal wieder nach der Methode "nicht kleckern sondern gleich klotzen" ans Werk und reserviert so viel Platz, dass er bis ins Jahr 2500+x genügen dürfte.

    Zwischen den Partitionen sollte so viel Freiraum bleiben, dass man ggf. eine zusätzliche kleine "Bootstrap" Partition dazwischenklemmen kann, ohne andere Bereiche dazu anrühren zu müssen.
    So eine direkt vor das Startvolume anzubringende Bootpartition wird benötigt, wenn man sein Startvolume mit irgendwas anderem formatieren möchte als "Mac OS Extended" oder "Mac OS Extended (Journaled)".
    Für HFS+ mit Gross/Kleinschreibung (also HFSX), UFS oder evtl zukünftig eingesetzte andere Formate muss man eine kleine HFS+ Partition davorschmuggeln, weil die Mac-Firmware nur von HFS+ die erforderlichen Dateien und Ordner ohne fremde Hilfe lesen kann. Dort kann man dann die Bootloaderdateien (BootX bzw boot.efi) und erforderliche Zusatzresourcen so ablegen, dass sie für die Hardware sichtbar und greifbar sind.
    Auch PPC Linux macht zB sowas mit einer "yaboot"-Partition, die dabei helfen soll, ein anderes Dateisystem als HFS+ (in diesem Fall ext3, ReiserFS o.ä.) durch zusätzlichen Code nach Ordnern und Dateien durchsuchbar und diese dadurch erst ladbar zu machen.

    Nur, 128 MB sind ...ähem... doch etwas Overkill dafür. Das grösste aller vorbereiteten Loadersets, die sich im MediaKit (in den Systemframeworks) als fix und fertig vorkonfektioniertes Image befindet, hat gerade mal etwa 1 MB Datenmenge, und das ist schon üppig ausgestattet. Werte um die 10 MB sind definitiv so zukunftssicher wie der Atlantik nie ganz zufrieren wird.
    (Dort kann man übrigens auch die Standardgrösse der EFI Sytempartition kleiner drehen, die mit obligatorischen 200 MB ebenfalls ein wenig wirkt wie ein Pferd, das vielleicht irgendwann mal von einem Floh geritten werden soll.)

    Das geht ziemlich einfach. Möchtest du eine Festplatte die sich mit 100 PetaByte Platz meldet? Da hast du dann sicherlich genug "Nirwana-Zone" zum runterladen des gesamten Internet frei. Da macht die Flatrate richtig Lust auf noch mehr Video: "Titanic 2, StarWars Episode 7 und sämtliche Akte X-Folgen jetzt downsyndromloaden!".
    Und der Bundestrojaner darf sich dort auch ruhig umsehen. Da hat er was zu tun und ist von der Strasse weg. :)
     
  18. silv2222

    silv2222 Idared

    Dabei seit:
    11.12.06
    Beiträge:
    29
    Nochmals Danke für deine ausführlichen Erklärungen. Jetzt weiß ich wenigstens auch, was ich da genau gemacht habe und bin nun etwas schlauer :)

    Grüße,

    silv
     

Diese Seite empfehlen