gibt es ne andre Möglichkeit für ne Platte mit ca. 200 GB die auf beiden Betriebssystemen laufen muss außer FAT32
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....
Zu was würdest du mir raten? NTFS-3G oder FAT32 mit 2 x 90 GB?
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.
Also was ich gern haben würde, wär entweder:...oder ...
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.