• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Es regnet, ist neblig und kalt, alle sind krank und der Chef wird zunehmend cholerisch. Das Thema des Monats ist also folgerichtig --> Das Grau(en)
    Wir sind gespannt, war Euch dazu einfällt! Zum Wettbewerb --> Klick
  • Auch in diesem Jahr möchten wir auf unserer Webseite mit einem passenden Banner etwas weihnachtliche Stimmung verbreiten. Jeder Apfeltalker kann, darf und sollte uns einen Banner-Entwurf zusenden, wie und wo das geht, könnt Ihr hier nachlesen --> Klick

[10.13 High Sierra] VMWare Fusion - Bootschleife

Wuchtbrumme

Golden Noble
Registriert
03.05.10
Beiträge
22.035
Hi,

habe den tollen Tip gefunden, wenn man in die Recovery booten möchte in der VM, dann die dazugehörige vmx bearbeiten und die Zeile

macosguest.forceRecoveryModeInstall = "TRUE"
hinzufügen.

Soweit, so gut. Die Zeile ist auch schon lange wieder raus.

Nur: es bootet immer noch nur in die Recovery. Und zwar selbst dann, wenn ich vom USB-Stick booten wollen würde.

Kennt das jemand?
 

Wuchtbrumme

Golden Noble
Registriert
03.05.10
Beiträge
22.035
Leid und Elend.
Der Vollständigkeit halber: es wurde auch das Laufwerk defragmentiert mittels der Anleitung von VMWare und danach „geshrinkt“. Dann partitioniert und den APFS-Container auf das Doppelte des belegten Speicherplatzes gesetzt und eine HFS+-Partition als Platzhalter hinzugefügt - mit dem macOS-Festplattendienstprogramm.

Nach einem Neustart hatte ich immer noch dasselbe Verhalten. Wenn ständig die Recovery Partition bootet, dann kann man ja zumindest die Erste Hilfe starten - aber natürlich ist das die OS-Version (wobei ich dachte, das sei 10.12 gewesen?), die zu dumm ist, ein Laufwerk unmounten zu können, um es dann zu reparieren.

Dann dachte ich, würde ich eine neue VM anlegen, dort die alte Disk mounten und dann einfach mittels des Systems auf dem USB-Stick kopieren (es handelt sich um ein 10.13).

Jetziger Stand: weder alte noch neue VM starten überhaupt noch. Ich habe die alte VM ausgehabt, aber die Disk im neuen System verbunden. Die GUI hat das nicht verhindert, nur darauf hingewiesen, dass es natürlich Änderungen geben kann. Kann nichts passieren, hätte ich gesagt - der Verdacht, dass Fusion intern nicht damit klarkam, dass beide virtuellen Disk Virtual Disk.vmdk hießen, drängt sich auf.

Was für ein Haufen gequirlter Mist. Man stolpert von einem Bug zum nächsten.
 
Zuletzt bearbeitet:

Wuchtbrumme

Golden Noble
Registriert
03.05.10
Beiträge
22.035
Update:
Ich habe das alte System jetzt wieder in funktionsfähigem Zustand. Zwischendrin war ich noch halbwegs entspannt, da Kopien existieren, aber da fiel mir ein, wieviel ich die letzte Zeit gemacht habe - alleine die Umstellung weg vom Mailserver auf der macOS 10.13-Server-VM, war schon was. Da rein fällt auch noch DNS und vielleicht auch noch ein paar Änderungen im Kalender oder Kontakten. Da hätte ich bestimmt Dinge vergessen.

Lange Rede, kurzer Sinn: mittels der Taktik, in Fusion eine neue VM mit gleichen Einstellungen zu erstellen und ein paar Laufwerke mehr (damit sich die Namen inkrementieren), die dann später gelöscht werden, sowie der Option, eine Kopie des Laufwerks der alten VM anzulegen und direkt in der neuen zu speichern, konnte ich quasi das "PRAM" der VM löschen, sie kam ohne weiteres Zutun sofort hoch.

Leider hatte ich, ungeduldig wie ich bin, irgendwann auch in der Bootschleife auf macOS erneut installieren gedrückt - und das holte das System dann erst einmal nach ;) Das dauerte dann ewig und der Build ging zurück auf 17G2208, was ich überhaupt nicht erklären kann, das war nämlich eine extra Veröffentlichung von macOS High Sierra extra für den Launch vom MacBook Pro 2018. Das ist hundertprozentig nie installiert gewesen. Der AppStore zeigte auch nach Warten keine Updates an. Auch das Herunterladen von High Sierra aus dem AppStore und Drüberinstalieren half nicht - der Build blieb zunächst der gleiche. Da könnte man fast vermuten, das es das ist, was derzeit noch verfügbar ist. Aber nachdem ich Schlaf nachgeholt habe, die Nacht war trotzdem kurz, wurde mir erst das Sicherheitsupdate 2020-005 und Safari 13.1.2 angezeigt, die ich installieren ließ. Danach erschien das ergänzende Update für das MacBook Pro 2018 2, wo ich schon auf Installieren und Neustart geklickt habe, als sich der AppStore noch eines Besseren besonn, meinte, die verfügbaren Updates hätten sich geändert und ob ich die ansehen wolle. Da kam dann 2020-006 (was auch vorher installiert war). Das installiert und seitdem ist der Build wieder auf 17G14042 oder so. Passt.
Daraufhin traute ich mich, die Server.app wieder anzuschmeißen. Sie aktualisierte laut eigener Aussage alles mögliche und läuft seitdem wieder.

Puh, gleich noch eine Kopie der VM fürs Backup gezogen.

Als nächstes müsste ich irgendwann noch Kalender und Kontakte umziehen. Es gefällt mir nicht, dass die Nutzdaten da so völlig versteckt und im wesentlichen nicht praktikabel rücksicherbar sind. Auch dafür wird es eine Linux-VM geben. Den Luxus gönne ich mir.


(Das ist mein Rat: Bitte nicht meinen Blödsinn nachmachen. Da war etliches undurchdacht.
Als allererstes wie immer bei Änderungen sicherstellen, dass man ein aktuelles Backup hat.
Und konkret für Fusion: Wenn sich die VM komisch verhält, neue anlegen, Laufwerke mit "existierendes Laufwerk hinzufügen" und der Option, Konflikte zu vermeiden und eine extra Kopie anzulegen und in der neuen VM separat zu speichern kopieren.)

Und Recovery: Boot to Firmware in Fusion auswählen, Setup, Boot from File, zur Recovery herunterscrollen und solange Enter drücken, bis man das boot.efi hat. Nur für den Fall, dass einige meiner Probleme an der Bearbeitung der vmx-Datei lagen.
 
Zuletzt bearbeitet:

Wuchtbrumme

Golden Noble
Registriert
03.05.10
Beiträge
22.035
Einen Hinweis habe ich noch, hat aber nichts mehr mit der Bootschleife in die Recovery zu tun, sondern mit der Überprüfung von Zertifikaten in iOS:
Zwischendrin ist das Backup vom alten Mailserver hochgekommen - und mit ihm der geänderte MX-Record im lokalen DNS.
Das führte zu einer Fehlermeldung im macOS, dass sich das Zertifikat geändert habe (ohne Folgen) und zum Verlust der Funktionsfähigkeit des Mailversands auf iOS. Das iPhone hatte wohl zu dem Zeitpunkt auch den Empfang probiert, stieß auf das gleiche Problem und ließ mich ab dem Zeitpunkt nicht mehr dem selbst signierten Zertifikat vertrauen.
Ich musste das iPhone erneut "enrollen" im MDM. Bei dem iPad hatte ich wohl Glück...