Ein leerer, dunkelgrauer Screen ... - keinerlei Logos...
der Window-Server ist also bereits gestartet
Nein. Sobald der läuft, wirds blau.
Grau, noch ganz ohne Logo-Einblendung bedeutet:
Bootloader nicht gefunden oder FBdev nicht bereit. Startvolume nicht vorhanden oder nicht korrekt vorbereitet, oder Festplattencontroller/Grafikkarte inkompatibel. Möglicherweise auch ein inkompatibler Ethernet-Chipsatz.
Alternativen dazu:
Dauerhaft weiss (oder ggf auch dauerhaft schwarz) bedeutet:
Hardware-POST nicht bestanden (übelst)
Grau mit Apfellogo bedeutet:
Kernellader (boot.efi) gefunden und aktiviert (Framebuffer für Grafik ist konfiguriert, Kernel wird gesucht und dann geladen).
Der Kreisel darunter rotiert:
Mach-Kernel ist geladen, auf Integrität geprüft und wird initialisiert, Extensions bzw Extension-Caches werden geladen.
Stopschild bedeutet:
Kernel nicht gefunden, nicht ladbar oder Initialisierung vorzeitig abgebrochen.
Hintergrund in "Französisch Blau" bedeutet:
Mehrbenutzermodus erreicht (launchd läuft, Kernel-Sicherheitslevel 1 ist eingerastet).
"CoreGraphics Framework" ist geladen und aktiv (aka "WindowManager is up and running").
Nächste Haltestelle: Loginwindow
Unter VB auf dem echten Mac wurde genau dieser graue Screen angezeigt, kurz bevor die Sprachauswahl kam.
Hmmm. Nur ein Wort: BETA
"Mehra sog i net"
Der Systemprofiler des Gastes gab mir die gleichen Daten an, wie der des Wirtes.
Ääääh. Was nu? Läuft oder läuft nicht???
Mac OS X nutzt nunmal verschiedene Schutzmechanismen, die die Installation auf herkömmlichen PCs verhindern sollen
Seit SnowLeopard extrem gelockert. Eigentlich nur noch aus rein formellen Gründen vorhanden.
Das Installationsskript allein schon zeigt glasklar, dass man gnädigst beide Augen zudrückt. (Das "Drei Affen" Prinzip)
Bei Nicht-Macs fällt sogar die sonst durchgeführte Prüfung auf eine vorhandene Leopard-installation (der "Update"-Check) unter den Tisch.
Offenkundig will man lieber ein paar gnädig geduldeten Hackintoshes da draussen zusehen, als "Heckmeckintoshes" die mit ihren teilweise furchtbar kaputtgefrickelten Systemen einen evtl ziemlich schlechten Eindruck hinterlassen.
(abgesehen davon, dass es ohne EFI nicht bootet).
Das täuscht. OS X ist auch via BIOS bootbar.
Alles was von EFI wirklich gebraucht wird, sind dessen Informationstabellen, die dem Kernel übergeben werden. Diese Tabellen sind von rein passiver, informativer Natur und können auch von anderer Software sehr einfach generiert werden.
Die wenigen aktiven Programmroutinen ("Services") aus EFI, die von OS X genutzt werden, lassen sich damit auch relativ problemlos auf entsprechende BIOS Calls umbiegen. Solange noch irgendein funktionierendes BIOS für Rechner der betreffenden Gerätelinie existiert, kann man es auch verwenden, denn diese BIOS Aufrufe sind nur rudimentärer Natur und allesamt standardisiert.
Es fehlt dann nur viel von Apple Rechnern gewohnter Komfort (zB die einfache Startvolume-Auswahl, eine dauerhaft einstellbare Gerätelautstärke etc), einige "Zuckerl"-Features wie der FireWire-TargetMode oder der selbstkonfigurierende NetBoot fehlen komplett und die Installationsprozedur verläuft insgesamt erheblich komplizierter (vieles muss dann u.U. "von Hand" vorbereitet werden, weil das Installationsskript das nicht so vorsieht).
Das technische Rüstzeug dafür hat Darwin schon seit seiner allerersten Prototypenversion ("Rhapsody") mit dabei.
Zweifel?
OS X in VMware Fusion virtualisiert läuft bereits zu 100% via BIOS. Keinerlei EFI nötig.
(Eine experimentelle EFI-Firmware könnte man dort zwar auch aktivieren, die funktioniert aber bisher noch gar nicht. Wesentlichstes Manko ist dort bisher der fehlende HFS+ Parser der es erforderlich machen würde über die EFI Systempartition in den Bootprozess einzusteigen. Frickeljob. "Sun" hatte sowas schon vor 15 Jahren irgendwo für Solaris rumliegen.)
Alles was man für einen BIOS-basierten Start an "magischem" Kram benötigt ist entweder bei Apple im Darwin Quellcode, oder bei freien Entwicklern wie
www.tgwbd.org für jedermann verfügbar. Den entsprechenden Kernellader für BIOS/MBR hat VMware im ISO-Image mit den "VMware Tools" versteckt. Dieses Diskimage dient hier gleichzeitig als "temporäre Boot-DVD" mit einer hilfreichen RAMdisk darauf (bei Lunix ist sowas als "initrd" bekannt).
Parallels nutzt ebenfalls das OpenSource-Angebot bei Apple, hat die gleichen Dateien aber in seine eigenen Binaries integriert und diese durch Signatur gesichert, um die Startmöglichkeit zuverlässiger auf die Serverversion von OS X limitieren zu können.
(Bei VMware Fusion dagegen ist der entsprechende Hack zur Freischaltung aller Gastsysteme extrem simpel. Die Absicherung mittels digitaler Signatur hat dort nur einen rein dekorativen FUD-Faktor.)
Dazu gehört auch eine Copyright-geschützte Kennzahl die in den Tiefen des Chips für die Lüftersteuerung verbaut ist.
Der SMC kontrolliert weit mehr als nur den/die Lüfter. Der kümmert sich um
nahezu alle Aufgaben rund um die Energieversorgung, Stromsparfunktionen und das ACPI-Management. Bei "echten" PCs auch noch um die altertümlichen PS/2 Ports für Maus und Keyboard.
weshalb VirtualBox diese vom echten Mac ausliest und an das Mac OS X in der VM weitergibt.
Das schöne an VirtualBox ist, dass man so herrlich frank und frei konfigurieren kann, wie die VM "von innen aussehen" soll.
Das patchen eines einzigen VendorStrings von "Innotek GmbH" in "Apple Computer, Inc." sollte keine allzu grosse Herausforderung sein.
Jedenfalls schon gar nicht, wenn es dazu lediglich eine einzige Zeile im Terminal bzw im Befehlszeilenfenster braucht.
Wie man das für Festplatten/controller, CDROMs oder auch andere simulierte Komponenten machen kann, steht im VirtualBox Handbuch bereits beschrieben, den entsprechend anzupassenden String für den SMC sucht man sich einfach in der als Quelltext verfügbaren "Light-Version" von VBox raus.
Mac OS X kann die Maus eines Wirt-Systems "fangen". Während des grauen Screens funktioniert das auch schon.
I know.
Windows *könnte* das ja auch - wenn es sich nicht dummerweise darauf verlassen würde, dass es irgendwo schon gaaaaanz bestimmt eine PS/2-kompatible Maus geben wird - so wie das schon unter MS-DOS 5/Windows 3.0 ...
Upps! Habs ganz vergessen: In Windows ist ja üüüüüüberhaupt keine Spur von DOS mehr drinne. Sagt Steve Ballmer. Sagt das MSDN. Sagt die "PC-Welt". Sagen
www.gulli.com, die Bäckerblume und die Apotheken-Rundschau.
Dann muss das ja wohl auch so sein. Versprochen. Doppelschwör.
Ein deppertes BIOS mag halt nicht ganz so gern reden mit den als "nativ" erscheinenden USB-Devices. Die EFI Simulation kann das ganze doch etwas besser. EFI beinhaltet ja schliesslich auch einige ziemlich spezielle Dinge zur direkten Virtualisierungsunterstützung. Merkt man.
