• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

Zwei OSX-Partitionen und FileVault 2

Bananenbieger

Golden Noble
Registriert
14.08.05
Beiträge
25.515
Bin ich da etwas doof, oder halten auch kompetente Leute die Forderung nach einer eigenen Partition, einem extra System für ein Zeichen, daß die dortige IT-Abteilung nicht so wirklich toll kompetent ist?
Yepp. Allerdings bin ich schon überrascht, dass man in dem Unternehmen überhaupt ein Gerät zulässt, dass sowohl geschäftliche als auch private Daten enthält.

zumindest in 10.9.x funktioniert das noch
Zumindest meine fstab sagt folgendes:
Code:
IGNORE THIS FILE.
This file does nothing, contains no useful data, and might go away in
future releases.  Do not depend on this file or its contents.
 

sedna

Galloway Pepping
Registriert
22.10.08
Beiträge
1.359
Hallo,

zumindest in 10.9.x funktioniert das >> bei mir << noch.

Give it a try ! ˙±˙
 

Bananenbieger

Golden Noble
Registriert
14.08.05
Beiträge
25.515
Okay, auf meinem Testsetup hat es auch prima geklappt.

Zuerst Platte partitioniert, dann über den Recovery-Modus auf jede Partition ein OSX installiert. Dann ins jeweilige OSX gebootet und FileVault aktiviert. Beide Systeme sind bootbar und das ganze läuft dem Anschein nach stabil.

Das Mounten der jeweils anderen Partition konnte ich mittels vifs verhindern.
 

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
Zumindest meine fstab sagt folgendes
Das steht nicht in fstab, sondern in der (obsoleten) Musterdatei fstab.hd
fstab existiert noch gar nicht, die musst du erst selbst erzeugen (root/wheel, mode 644).
Syntax beachten. Dann funktioniert sie auch.

Beispieleintrag:
Code:
UUID=AAAABBBB-CCCC-DDDD-EEEE-FFFF00001234  none  hfs  noauto
...und schon wird dieses Volume nicht mehr automatisch aktiviert.
Die UUID des Volumes kann man zB der Info im FP-DP entnehmen.

Alternativ (weniger robust) geht auch der Volume-Name mit dem Schlüssel LABEL=....
(Nicht alle Dateisystemtypen besitzen überhaupt eine UUID, bzw nicht unbedingt.)
Leer- und Sonderzeichen im Namen sind nicht mit Quotes, sondern in shelltypischer Oktaldarstellung zu maskieren, also zB statt Mein Name ist Hase?? steht da LABEL=Mein\040Name\040ist\040Hase\077\077
Nach den Oktalcodes nicht fragen, einfach nachsehen--> man ascii

Von der dritten Option die in anderen OS immer noch zuhause ist, die gewöhnlichen Gerätebezeichner nach dem Schema /dev/diskXsY, kann man sich geistig verabschieden, die werden in OS X voll dynamisch ganz nach Bedarf und Verfügbarkeit zugeteilt. Untauglich.

Weiterführende Erklärungen:

Das "none" im Eintrag meint: Kein starrer Mountpoint, automatische Festlegung (in OS X ein obligatorisches "must have").

Das "hfs" steht fürs zu ladende Dateisystem und umfasst alle Varianten der HFS/HFS+/HFSX-Familie, das Kürzel steht für den Namen des zuständigen Filesystem-Moduls in /System/Library/Filesystems/
Für FAT Volumes wäre das also 'msdos', für NTFS ein simples 'ntfs' oder aber der Name eines externen Moduls vom Drittanbieter, also zB ein 'ufsd_NTFS' beim Paragon Treiber, für ExFAT ein 'exfat' usw
Theoretisch ist hier auch ein "auto" möglich, aber das führt verschiedentlich zu Komplikationen und sollte vermieden werden.

Die Mountoption "noauto" ist selbsterklärend, weitere Parameter können separiert durch Kommata hinzugefügt werden. Allgemein von Belang ist eigentlich nur noch das "ro" für die Aktivierung im schreibgeschützten Modus. Von den anderen Parametern sollte lieber die Finger lassen, wer diese Erklärung hier braucht.
(Fehlende Erwähnungen werden implzit als die typischen Defaults gewertet.)

Die danach in der Manpage noch erwähnten weiteren Felder für fsck- und dump-Priorität sind in OS X nicht mehr von Bedeutung und können (so wie im Beispiel) einfach weggelassen werden (das entspricht zwei Nullen).

Warnung zum Schluss:
Eine syntaktisch völlig unsinnige/falsche fstab, zB gespickt mit den Textformatierungs-Tags einer RTF Datei, kann u.U. das mounten jeglicher Volumes unmöglich machen, ggf sogar den Systemstart verhindern.
Das erzwungene mounten von normalerweise nur schreibgeschützt nutzbaren Volumes (ntfs) im beschreibbaren Modus, oder die erzwungene Verwendung eines falschen Dateisystemmoduls (zB exfat statt msdos) kann u.U. zur Kernelpanik und/oder massivem Datenverlust führen.
 
Zuletzt bearbeitet:

Bananenbieger

Golden Noble
Registriert
14.08.05
Beiträge
25.515
Danke für den mal wieder sehr wertvollen Beitrag.

Zum Glück hab ich das Weiterleben der fstab nach man vifs dann auch gemerkt. ;)
 

schlagi

Weisser Rosenapfel
Registriert
09.07.13
Beiträge
782
Vielen Dank Rastafari, das kommt in meine Sammlung der verständlich erklärten Komplexitäten!


Sent from my iPad using Apfeltalk mobile app
 

Bananenbieger

Golden Noble
Registriert
14.08.05
Beiträge
25.515
Tja, so einfach hat es dann doch nicht geklappt. CoreStorage-Volumes interessieren sich nicht für die fstab... Bislang habe ich keine Lösung dazu gefunden.
 

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
Normale CS Volumes (FusionDrive) akzeptieren den fstab-Eintrag sehr wohl.
Verschlüsselte dagegen werden durch ein Hilfsprogramm aktiviert, welches sich darum nicht schert. Du kannst dieses Programm kaltstellen (Ausführungsrecht entziehen), dann erscheint bei keinerlei (!) verschlüsselten Volumes mehr der Dialog zum Entsperren. Die Freischaltung/Aktivierung von Cryptvolumes geht dann immer noch übers Festplatten-DP.
Code:
sudo chmod a-x /System/Library/CoreServices/CSUserAgent
Mit einem a+x ist das geschmeidig wieder rückgängig gemacht - oder mit einer Reparatur der Zugriffsrechte des Startvolumes natürlich auch.
 

Bananenbieger

Golden Noble
Registriert
14.08.05
Beiträge
25.515
Ah, cool.

Da ich es allerdings mit zwei verschlüsselten Volumes zu tun habe, von denen jeweils eines aktiv sein soll, fällt diese Lösung wohl flach.