Wechselnde Partitionsbezeichnung

[cobra]

Hallo zusammen,

Ich habe auf einem iMac 5K mit Fusiondrive mittels Bootcamp Windows 10 installiert. Jetzt beobachte ich ein für mich verwirrendes Verhalten. Wenn ich im Terminal mittels "diskutil list" die vorhanden Platten und Partitionen auflisten lasse, dann erscheint die Windows-Partition als disk0s4 (4. Partition auf dem 1. Disc). Wenn ich aber Windows boote und danach zu OSX zurückkehre, dann findet sich die Partition plötzlich auf disk1s4 (auf dem SSD-Teil des Fusiondrives). Das ist insofern ein Problem, als dass ich die Platte auch gerne als Raw-Disc in einer virtuellen Maschine nutzen möchte. Das geht aber nicht wenn die Zuordnung ständig ändert. Kennt jemand das Problem und weiss wie man es umgeht?

Danke!

 

[double_d]

Wenn ich aber Windows boote und danach zu OSX zurückkehre, dann findet sich die Partition plötzlich auf disk1s4

Dort wo sie bei einem Fusiondrive eigentlich auch hingehört meines Wissens nach.
Dies ist imho auch der HDD Teil. Disk0 ist der SSD Teil.

Poste doch mal die Screenshots der beiden Ansichten bei Dir.

 

[cobra]

Disk0 ist der SSD Teil.

So wie es aussieht ist aber disk0 der HDD Teil. Die SSD is disk1. Windows ist immer auf disk0s4 solange ich nur OSX boote. Sobald ich Win10 boote ist die Windows-Partition disk1s4. Im Moment behelfe ich nir noch so, dass ich nach Win10 zweimal OSX boote, aber das kann keine Dauerlösung sein.

 

[double_d]

Hast Du die Bootcamp Partition manuell umbenannt in "W10"?

So wie es jetzt aussieht, obwohl Disk0 tatsächlich die HDD bei Dir ist (könnte bei mir anders sein, da ich mein Fusiondrive selbst gebastelt habe), wäre es meiner Ansicht nach korrekt. Die Bootcamp Partition liegt auf dem HDD Teil und ist immer die letzte Partition auf dem Laufwerk.
Interessant wäre jetzt noch mal ein Bild, nachdem Windows gebootet war, denn dann müsste ja die Apple_CoreStorage (Macintosh HD) auf Disk1 um 109GB verkleinert sein in dem SSD Teil.
Windows kennt die CoreStorage aber überhaupt nicht und weiß auch gar nichts damit anzufangen.

Möglich, dass bei der Erstellung der Bootcamp-Partition irgendwas quer gelaufen ist, oder hast Du manuell eingegriffen um die Partition auf dem SSD Teil zu erstellen? Gibt ja da auch Anleitungen dazu, Bootcamp komplett auf der SSD laufen zu lassen.

Ansonsten kann ich mir nur vorstellen, dass die Disk1s4 Partition bei Dir, welche bei geladenem Windows erstellt wird um ein Vielfaches kleiner ist und nur temporär angelegt wird um Daten auf die SSD auszulagern.

 

[Rastafari]

Kennt jemand das Problem

Das ist vollkommen normal - auch wenn das nur manchmal zu beobachten ist.
Diese DevNodes werden vom Kernel dynamisch nach Verfügbarkeit zugeteilt, in der Reihenfolge der erkannten Geräte. Kann gelegentlich zu wechselnden Ergebnissen führen.

Welches Virtualisierungsprogramm soll es denn sein?
Zumindest bei VMware ist das Problem leicht lösbar, bei den anderen musste ich mich damit noch nicht rumschlagen.

 

[cobra]

Die Bootcamp-Partition habe ich nicht "manuell" erstellt, sondern Bootcamp-Assitent genutzt. Danach habe ich nur die Platte von Bootcamp in W10 umbenannt.

Ich denke auch, dass das Verhalten normal ist. Vermutlich wird beim Benutzen von Windows die entsprechende Partition auf die SSD gelegt.

Ich benutze VirtualBox zur Virtualisierung. Ich versuche mal, ob ich im raw_disk.vmdk die Partition durch die UUID ersetzen kann. Auf diese weise konnte ich schon das Mounten beim Start (in /etc/fstab) unterbinden. Dort hatte es mit der Partitionbezeichnung auch nicht geklappt (jetzt ist mir auch klar wieso).

 

[cobra]

Nachtrag: UUID kann scheinbar nicht für ein Raw-Disc genutzt werden!

 

[Rastafari]

Ich weiss nicht, ob diese Zusatzinformationen auch von VBox akzeptiert werden, aber zumindest in Fusion gibt es die Möglichkeit, dem DevNode noch weitere Metadaten hinzuzufügen um im Zweifelsfall eine Suche nach der betreffenden Partition anzustossen.
Dazu muss als Containerformat das VMware-typische VMDK benutzt werden (was in VBox ja problemlos geht, auch Konvertierung zwischen den verschiedenen Formaten ist mit dem CLI-Tool "VBoxManage" kein Drama.)

Eine VMDK Beschreibung für ein RawDevice besteht aus einer Textdatei, sowie optional dazu ein oder mehrere kleine Abbildfragmente derjenigen Disksektoren, die zur Einbindung in die VM gerigfügig modifiziert werden müssen - typischerweise der MBR und die GPT Partitionstabelle(n). Die Textdatei sieht zB folgendermassen aus und kann wie hier gezeigt ergänzt werden.
Dieses Beispiel zeigt zur Illustration eine handgearbeitete BootCamp-Konfiguration mit deutlich mehr Partitionen und OS als gewöhnlich, das Prinzip sollte damit klarer werden.
Jede dieser zusätzlichen Eigenschaften (Der Text in grün) ist optional und jede Kombination daraus kann verwendet werden, um die Identifikation so zweckmässig und zuverlässig zu gestalten wie erforderlich.
Dh nicht alle Werte müssen verwendet werden, einer davon genügt. Meist wird das treffsicherste die Partition-UUID sein (Obacht: Das ist *nicht* die Volume-UUID des Dateisystems, wie sie zB vom Festplatten-DiProg angezeigt wird.)
Zur Verdeutlichung findest du hier einige vollständige, sowie einige aufs wesentliche beschränkte Hints (die letzten zwei).

Wie du sehen kannst, können so sowohl regulär definierte Partitionen, als auch frei definierbare Plattensektoren ohne jede Partitionszugehörigkeit (hier der erste manipulierte Eintrag) in die VM umgelenkt werden - sie dürfen im Host-OS aber keinesfalls gemountet sein beim Start der VM, und die Abschnitte dürfen einander keinesfalls überschneiden.
Du musst unbedingt korrekt angeben, ob die Hints sich auf eine ganze Disk, oder nur für eine Partition darauf beziehen.

Die Zeilenumbrüche (rot) dürfen *nicht* mit in die Datei!
Der blaue Text ist Pflicht, der grüne Teil die optionale Wahl.
Die reguläre Längenbeschreibung eines jeden Extents wird in Sektoren gezählt (die erste Zahl in jeder Zeile), in den zusätzlich hinzugefügten Hints aber wird in Bytes gezählt.
Das Diskmodell ist anzugeben im Format "Hersteller | Modellkennung" (nicht Seriennummer!), davon rate ich aber ohnehin ab.

Die hier verwendete Partitions-UUID (empfohlen) ist die ansonsten nirgends sichtbare eindeutige Seriennummer in der GPT-Tabelle, welche zwar bei der Partitionierung, aber nicht mehr danach beim simplen formatieren des Volumes verändert wird (im Gegensatz zur Volume-UUID, welche dem Volume-Inhalt selbst entnommen wird, und bei jeder Löschung neu generiert).
Nicht zu verwechseln ist das auch mit der Typkennung, welche in der GPT ebenfalls in Form einer weiteren UUID gespeichert wird.
Die Partition-UUID (oder Media-UUID) lässt sich auslesen zB mit der "Info"-Funktion des "gdisk" Programms (aka "GPT-fdisk", erhältlich für lau beim Entwickler desselben: http://www.rodsbooks.com/ )

# Disk DescriptorFile
...
# Extent description
RW 34 FLAT "Example-pt.vmdk" 0
RDONLY 6 FLAT "/dev/disk1" 34 \
partitionUUID @disk:diskModel=TOSHIBA|20MD04ACA400,diskSize=4000787030016
RW 409600 ZERO
RW 4025864152 ZERO
RW 262144 ZERO
RW 100661248 FLAT "/dev/disk1s3" 0 \
partitionUUID @partition:diskModel=TOSHIBA|20MD04ACA400,\
diskSize=4000787030016,partSize=51538558976,partOffset=2061586399232,\
partMediaUUID=3430444D-4341-3441-3030-000000000003
RW 167770112 ZERO
RW 3288072192 ZERO
RW 262144 ZERO
RW 56360960 ZERO
RW 262144 ZERO
RW 55353560 ZERO
RW 1269544 ZERO
RW 33554432 FLAT "/dev/disk1s9" 0 \
partitionUUID @partition:diskModel=TOSHIBA|20MD04ACA400,\
diskSize=4000787030016,partSize=17179869184,partOffset=3940632494080,\
partMediaUUID=3430444D-4341-3441-3030-000000000009
RW 33554432 FLAT "/dev/disk1s10" 0 partitionUUID @partition:\
partMediaUUID=3430444D-4341-3441-3030-00000000000A
RW 50380424 FLAT "/dev/disk1s11" 0 partitionUUID @partition:\
partMediaUUID=3430444D-4341-3441-3030-00000000000B
RW 7 ZERO
RW 33 FLAT "Example-pt.vmdk" 34

# The Disk Data Base
...

Irgendwas noch unklar, oder gar unklarer als zuvor?

 

[cobra]

Ich muss mich erst mal in diese Antwort vertiefen und sehen, ob ich überhaupt verstehe was man mir hier mitzuteilen versucht.
:rolleyes: