In meiner „mei Sicht“-Reihe geht es heute um einen dieser Momente, die man eigentlich kommen sieht und man weiß schon in der Sekunde des Tastendrucks: Das war gerade ein monumentaler Fehler.
Dieser vermeidbare Fehler führte mich zu einer unfreiwilligen Zeitreise in meine Studienzeit, in der mein Professor uns von den Vorzügen des vi Texteditors überzeugen wollte und bei mir und weiteren kläglich scheiterte.
Nun saß ich da und sah mich schmerzlich daran erinnert, meine Favoriten nano und cat konnte ich hierbei nicht verwenden.
Eine kaputt konfigurierte config.plist, eine gute Stunde Schwitzen und Recherchieren und die Erkenntnis:
Vielleicht sollte man nicht jeden Vorschlag der KI blind übernehmen und verdammt noch mal, ein Backup machen.
Die Falle schnappt zu
Nach langen und verzweifelten Webrecherchen zum „Sleep Wake failure in EFI“ meines MacBook Pro (early 2013) kam ich auf die glorreiche Idee „frag doch mal die KI“, soll diese sich doch mit all den Lösungsansätzen rumplagen und mir diese zusammenfassen und ich sag ihr dann einfach, ob ich das schon probiert hab und ob es funktioniert oder weiterhin zum Fehler kommt. So war mein glorreicher Plan!
So kam es, dass ein paar Parameter in der config.plist (meiner Bootloader-Konfigurationsdatei für OpenCore) angepasst werden mussten.
Anstatt kurz innezuhalten und eine schnelle Kopie der Datei anzulegen (config_backup.plist dauert schließlich stolze fünf Sekunden), tippte ich die Werte direkt ein, was soll schon passieren, speicherte und klickte auf Neustart.
Mein Lohn, ein schwarzer Bildschirm. Kein macOS-Logo. Stattdessen der gefürchtete EFI-Shell-Error:
Initialization was not successful. Edit in EFI Shell failed…
Nichts ging mehr. Der Bootloader war zerschossen, weil die Syntax der Plist-Datei fehlerhaft war. Und ich hatte keine Sicherung.
Die Rettung macOS-Recovery
Da der normale Bootvorgang blockiert war, führte mein Weg über die macOS-Wiederherstellung (Recovery).
- Den Mac mit gedrückter Recovery-Tastenkombination starten.
- Eine externe Maus anschließen, weil mein Trackpad nicht erkannt wurde und die initialen Konfigurationen sowie das WLAN mühsam neu angeben (weil in der Recovery-Umgebung natürlich nichts automatisch verbunden ist).
- Oben im Menü über die Dienstprogramme das Terminal öffnen.
Da saß ich nun. Kein schickes Xcode, kein iA Writer, keine Maussteuerung. Nur ich, eine blinkende Kommandozeile und der nackte Code auf der versteckten EFI-Partition.
Der Endgegner: „vi“ und der Fehler E949
Um die Datei zu retten, musste ich die EFI-Partition mounten (wie das geht, habe ich ja kürzlich in kürz & fix beschrieben) und die config.plist bearbeiten. Klingt easy, doch meine Verzweiflung stieg an als ich nano eingab… nichts, bis auf die Meldung, dass dieser Befehl unbekannt sei.
Unter macOS-Recovery gibt es dafür nur einen Editor, der standardmäßig an Bord ist: vi (bzw. vim).
vi config.plist
Wer noch nie mit vi gearbeitet hat: Es ist der Endgegner unter den Texteditoren. Man kann nicht einfach lostippen. Man muss erst i für den Einfügemodus drücken. Und wehe, man drückt die falschen Tasten. Ich suchte im Keller meine alten Notizen, in dem ich den Lebenszyklus und die entsprechenden Tastenkombinationen notiert hatte. Glücklicherweise fand ich diesen auch. Nichtsdestotrotz musste ich die Bearbeitung ein paarmal abbrechen, da ich die falschen Tasten drückte.
Ich suchte die Zeile mit den fehlerhaften Parametern im NVRAM-Bereich und änderte die Werte mühsam auf den alten Stand zurück. Doch als ich den Editor mit dem klassischen Befehl :wq (write & quit / speichern und beenden) verlassen wollte, spuckte mir das System ein eiskaltes:
E949: File changed while writing entgegen.
Ein Schreibfehler! In der Recovery-Umgebung war die Datei blockiert.
Der vi-Workaround
Nach kurzem Fluchen erinnerte ich mich an die alten Unix-Tricks. Wenn vi die Originaldatei beim direkten Überschreiben blockiert, weicht man auf eine neue Datei aus.
- Im vi-Befehlsmodus eingeben: :w config_neu.plist (Das speichert den korrigierten Text in eine neue, unblockierte Datei).
- Den Editor mit :q! (beenden, ohne Speichern der Originaldatei) verlassen.
- Im normalen Terminal die alte Datei mit der neuen, reparierten Datei überschreiben:
cp config_neu.plist config.plist
Das Happy End
Ein Stoßgebet, ein beherzter Druck auf den Power-Button – und siehe da: Mein macOS bootete wieder, als wäre nie etwas gewesen.