Heute wurde ich am DKF zu einem älteren PowerMac G4 gerufen, dessen Applikationen in letzter Zeit häufig abstürzten. Ende letzter Woche klagten die Benutzer auch (temporär) über eine komische Bildschirmanzeige, wobei ich damals aber eher auf einen defekten Flachbildschirm tippte (Die untere Hälfte des Schirms sei nur noch grau gewesen).
Da insbesondere Safari häufig das Zeitliche segnete, entschied ich mich als allererstes für die Installation aller anstehenden Software-Updates. Dies stellte sich rückblickend aber als folgenschwerer Fehler heraus. Denn während also die Updates heruntergeladen, entpackt und installiert wurden, kam es ausgerechnet beim Security Update 2005-008 zum Super-GAU. Die Installation blieb mit dem „Spinning Beach Ball“ hängen. Und da dieses Security-Update tief in das System eingriff, kam die Kiste nach dem erzwungenen Kaltstart nicht mehr hoch. Der graue Bildschirm mit dem Apfel und den „rotierenden Stäbchen“ funkelte minutenlang vor sich hin, ohne dass sich Besserung einstellte.
Beim nächsten Neustart presste ich deshalb Apfel-V, um in den „Verbose Mode“ zu gelangen. Diesen Modus werden Unixer und DOS-User gut kennen – anstelle der gewohnten Apple-Oberfläche, die solche Informationen vor den Benutzern versteckt, werden hier in hässlicher Terminalschrift die verschiedenen Statusmeldungen während des Bootens angezeigt. Beim defekten Gerät blieben diese Meldungen bei
BSD root: disk0s10, major 14, minor 9
stehen.
Autsch. In meiner Mac-Karriere hatte ich bis zu diesem Tag noch nie mit solch tiefliegenden Probleme zu kämpfen gehabt.
Welche Möglichkeiten bestanden nun? Das Security Update hätte nur mit Zugang zum GUI – oder zumindest zum Terminal – deinstalliert werden können. Diese Chance bestand hier vorerst einmal nicht.
Eine Neuinstallation des Systems wollte ich auf jeden Fall vermeiden, da dieses mit stundenlanger Arbeit verbunden gewesen wäre. Zuerst mal hiess es also, den Zustand des Datenträgers zu prüfen.
Hierzu nahm ich die Panther-Installations-CDs zu Hilfe, brach die Installation aber ab und gelangte in das Disk Utility, um „Repair Permissions“ sowie „Verify Disk“ auszuführen. Zu meiner Erleichterung hatte der Datenträger keinen Schaden genommen, das Problem musste auf Software-Ebene liegen.
Mit Hilfe der Beschreibung des Security Updates versuchte ich nun, das den Fehler verursachende Teilupdate einzugrenzen. Nach der Durchsicht tippte ich auf
LibSystem
(Vorneweg: Ich sollte richtig gelegen haben.) Doch was genau war nun dieses LibSystem? Eine „Library“, und wohl eine ganz grundlegende, da „System“ im Namen. Mit etwas Googeln fand ich die betreffende Datei:
/usr/lib/libSystem.B.dylib
Mein Ziel: Diese Datei mit der Version vor dem Update ersetzen.
Das Glück war mir Hold, da ich erst vor wenigen Wochen die Festplatte genau dieses Rechners ersetzt und mit Carbon Copy Cloner den Inhalt der alten Platte auf die neue geklont hatte. Ich baute die vorbildlich archivierte Platte also wieder in den PowerMac ein, bootete von der Installations-CD und wählte die alte Platte als Startvolume aus. Nun hatte ich wieder ein GUI, um die Änderungen vorzunehmen.
Zu diesem Zeitpunkt war ich noch etwas unsicher, ob libSystem.B.dylib wirklich der Übeltäter war. Es hätte ja sein können, dass wie bei einem von Microsoft für Windows veröffentlichten Update hunderte von DLLs ersetzt würden. Wie konnte ich auf Nummer sicher gehen?
Pacifist! Mit diesem Tool lassen sich .pkg-Dateien „öffnen“ und deren Inhalt betrachten. Deshalb lud ich von Apple.com das Security Update manuell als eigenständiger Installer herunter und öffnete es in Pacifist. Und siehe da: Eben auch in solchen Belangen zeigt sich, wieso die Ingenieure bei Apple ihr Geld wert sind: Eine schöne Ordnerstruktur tat sich auf, und zwar so gegliedert, wie die Dateien auch in das Wirtssystem installiert werden sollten. Und: Nur ganz wenige Dateien! Und mittendrin tatsächlich die libSystem.B.dylib. Wunderbar. Meine Hoffnung auf Erfolg stieg.
Mit dem Terminal und sudo kopierte ich die Datei von der funktionierenden Mac OS X-Installation auf die defekte – natürlich überschrieb ich diese aber nicht, sondern fertigte vorher von der suspekten Datei eine Sicherheitskopie an.
Unglaublich! Aber es funktionierte tatsächlich, Mac OS X kam wieder hoch …
Fazit
Der Entscheid Steve Jobs, Ende der 90er auf ein Unix-Derivat zu setzen, war einer der klügsten Schritte in Apples Firmengeschichte. Nicht nur eröffnete man sich so neue Märkte (Geeks), sondern erleichterte so den PC-Supportern auch das Arbeitsleben. „everything is a file“ ist schlichtweg genial. *winke* Windows-Registry …
Nachtrag: Während den ganzen Abklärungen bemerkte ich häufige Hänger und Abstürze. Sehr schnell tippte ich auf ein defektes RAM-Modul und entschied mich, die unteren 128MB aus dem System zu entfernen. Danach traten – bis heute Abend jedenfalls – keine solchen Probleme mehr auf.
