MacBook Pro wiederherstellen ?!

[LuckyOldMan]

Ich würde mal von gar nichts ausgehen

Es bleibt schwierig.

Ich habe kurz nachgerüstet und eine Sata-SSD reingeschoben, um auszutesten, was wie geht. Ich gehe ohne Stick & kopieren etwas anders vor und nutze die EC-App im Ordner Programme, um die Installation anzustoßen.
Melde mich wieder.

Zwischeninfo:

Die Installation läuft jetzt auf dem anderen Mac - dann wird sich zeigen, ob die dmg aus dem Mr. M.-Link porentief rein ist.
Die eingeschobene Sata-SSD habe ich vor Start im FPDP in zwei Partitionen aufgeteilt, stellvertretend für das vorhandene Lion und das neue EC. Ich halte nicht sonderlich viel vom Drüber-Installieren, ohne zu wissen, was wird, denn zickt etwas, sind beide OS verloren.

Also auf Nummer sicher gehen, zuerst aus der einen Partition zwei machen, deren Größe den OS-Bedürfnissen anpassen und wnen EC lauft, kann ma den Platz von Lion wieder an EC abgeben.
Kennen wir doch so in der Art von APFS.

 

[T-easy]

und wnen EC lauft, kann ma den Platz von Lion wieder an EC abgeben.
Kennen wir doch so in der Art von APFS.

Das wird aber schwierig. Aus dem macOS auf einer Partition an zweiter Stelle lässt sich die erste Partition nicht mehr vollständig löschen/assimilieren. Das geht nur anders herum. Sind aber Spielereien... Wenn das macOS an zweiter Stelle nachweislich funktioniert, dann kann man da heraus das Lion immer nochmal Drüberinstallieren und dann ist man auf Partition 1. Gleich drüber bügeln ist halt einfacher, auch wenn es dich als Alten Hasen berechtigt als nicht optimal erscheint.

 

[LuckyOldMan]

Das geht nur anders herum.

Ist mir inzwischen qua Erinnerung mit Partitionen vor langer Zeit und jetzt beim versuchten Löschen der ersten Partition auch aufgefallen. EC war recht flott installiert.
Was ist doch APFS für eine fortschrittliche Einrichtung - da ist wurscht, wer wo an welcher Stelle steht.
Dann muss es doch mein heißgeliebter Stick sein.

 

[LuckyOldMan]

Dann muss es doch mein heißgeliebter Stick sein.

Muss es u. U. doch nicht.

Gleich drüber bügeln ist halt einfacher,

aber eben ohne Stick.

Ich habe das eben installierte EC nebst Platzhalter Lion (Part. 1) komplett gelöscht und Lion auf die komplette Sata-SSD installiert (dauerte keine 10 Minuten).
Die El Capitan-App im Ordner Programme habe ich initiiert, als Ziel die Lion-Partition angegeben und nach 20 Sekunden bootete der Mac neu und setzte die EC-Installation fort.
In 20 Minuten wissen wir mehr.

 

[T-easy]

Muss es u. U. doch nicht.

aber eben ohne Stick.

Ich habe das eben installierte EC nebst Platzhalter Lion (Part. 1) komplett gelöscht und Lion auf die komplette Sata-SSD installiert (dauerte keine 10 Minuten).
Die El Capitan-App im Ordner Programme habe ich initiiert, als Ziel die Lion-Partition angegeben und nach 20 Sekunden bootete der Mac neu und setzte die EC-Installation fort.
In 20 Minuten wissen wir mehr.

und das ist der praktikabelste Weg für die TE. Dann nochmal das ähnliche aus EC heraus mit HS + alle Updates und 'Ziel erreicht'

 

[LuckyOldMan]

Und da ist EC schon (war eher fertig als ich mit dem Tomatensalat )
Alle Einstetlungen werden wie üblich übernommen.
Aus die Maus.

das ähnliche aus EC heraus mit HS

HS bleibt aber nach wie vor ein Problemfall, wie Du weißt. Mal sehen, ob die TE den Workaround im Terminal hinbekommt.

 

[T-easy]

Und da ist EC schon (war eher fertig als ich mit dem Tomatensalat )
Alle Einstetlungen werden wie üblich übernommen.
Aus die Maus.

warum aus die Maus? Wir bleiben doch nicht bei EC stehen.

HS bleibt aber nach wie vor ein Problemfall, wie Du weißt.

HS aus dem laufenden EC sollte kein Problem haben. Das Problem gibt es doch nur im Recovery.Modus.

Mal sehen, ob die TE den Workaround im Terminal hinbekommt.

...habe ich was verpasst? Ich meine, aus dem EC heraus kannst du jetzt genauso wie zuvor die HS-InstallationsApp starten und dann installieren. Danach, aus die Maus.

 

[LuckyOldMan]

warum aus die Maus?

Weil der erste Abschnit Lion->EC abgeschlossen ist.

HS aus dem laufenden EC sollte kein Problem haben

Grundsätzlich ja, aber: wo gibt es nicht-infiltrierte .dmg? Von diversen obskuren Seiten, die dann noch freundlicherweise ein paar Zusätze eingebaut haben?
"So, we have already prepared the file for you to download directly."
Da gehen bei mir die Alarmglocken an.

aus dem EC heraus kannst du jetzt genauso wie zuvor die HS-InstallationsApp starten

Das ist doch gar nicht der Punkt. Dass das geht, ist klar. Aber wo holst Du die HS-App mit einem installierten EC und ist die dann nicht korrupt?

 

[T-easy]

Weil der erste Abschnit Lion->EC abgeschlossen ist.

Haken dran

Grundsätzlich ja, aber: wo gibt es nicht-infiltrierte .dmg? Von diversen obscuren Seiten, die dann noch freundlicherweise ein paar Zusätze eingebaut haben?
"So, we have already prepared the file for you to download directly."
Da gehen bei mir die Alarmglocken an.

Natürlich nicht irgendwoher...versteht sich von selbst

Das ist doch gar nicht der Punkt. Dass das geht, ist klar. Aber wo holst Du die HS-App und ist die dann nicht korrupt?

Meines Erachtens ist die selbe .dmg, welche unter der Recovery "korrupt" ist im laufenden System, hier EC, eben lauffähig, da das Problem mit der https bei laufenden System nicht auftritt. Dieses "Zertifikatsproblem" ist IMHO ein isoliertes Recovery-Problem. Teste das doch bitte aus mit dem HS .dmg von Apple, wie es bei MrMactintosh auch verlinkt ist. So, oder so ähnlich habe ich schon häufig HS installiert, aus dem laufenden EC heraus.

 

[LuckyOldMan]

Teste das doch bitte aus

Ich habe für heute genug ausgetestet. Dürfen Andere mal machen.
Ich habe ja das Problem nicht, da mein Stick bestens funktioniert.

 

[T-easy]

Ich habe für heute genug ausgetestet. Dürfen Andere mal machen.
Ich habe ja das Problem nicht, da mein Stick bestens funktioniert.

Verstehe ich, aber du hast halt so ein EC macOS brach da liegen. Nur unter der Voraussetzung lässt sich das ja austesten. Du kannst ja auch einfach die App von deinem HS-Stick, den du ja eh hast (und der dir korrupt vorkommt) einfach starten. Meine Vermutung: In EC bekommst du keinen Fehler. Musst ja gar nicht durchinstallieren, nur sehen, ob du zum Lizenzfenster durchkommst. Der Rest ist ja dann easy

 

[LuckyOldMan]

von deinem HS-Stick, den du ja eh hast (und der dir korrupt vorkommt)

Wo ist der denn korrupt? Damit habe ich doch (vor-)gestern die HS-Installation durchgezogen. Und für den weiteren Eigenbedarf kann ich mich im Store bedienen.

 

[T-easy]

Aber wo holst Du die HS-App mit einem installierten EC und ist die dann nicht korrupt?

Waren jetzt deine Worte, aber vielleicht falsch gedeutet.


...zurück zum Thema

Ich habe für heute genug ausgetestet. Dürfen Andere mal machen.

...ich bin mal der Andere und ...

... habe mir kurz die Arbeit gemacht und das ganze durchgespielt auf meinem MBP8,1

1. High Sierra Internet-Recovery > Zertifikatsfehler (siehe Seite)
2. High Sierra Installerstick aus Fundus > Zertifikatsfehler
3. El Capitan installiert mit Installerstick aus Fundus > Installation läuft ohne Fehler, da Zertifikat noch nicht online abgefragt wird
(Was gleichbedeutend ist mit EC Installer App in Lion ausführen)
4. Unter El Capitan den HS- Installerstick genommen und Installer App vom Stick direkt ausgeführt > Installation läuft ohne Fehler, man muss dafür aber im EC online sein, Zertifikat wird geholt und funktioniert

Also...Beweis erbracht:
Erkenntnis1: Der Weg geht so und ein laufendes macOS (hier EC) hat kein Problem mit dem Zertifikat. Funktioniert mit dem .dmg von der Apple-Seite
Erkenntnis2: Der Zertifikatsfehler ist ein isoliertes Problem der High Sierra-Recovery und tritt nur dort auf. Das läßt sich dort nur knifflig mit dem https zu http Terminal-Hack lösen

 

[bobesch]

Leute, merkt Ihr eigentlich noch was?
Da gibt man der TE die Info, dass, wo nun glücklicherweise als Basis OSX-Lion installiert ist, in einem 3-Schritt-Verfahren per dosdude1-Patcher sowohl Download, als auch InstallerStick-Erstellung für HighSierra, Mojave und Catalina auch einfach und GUi-geführt ohne Terminal etc funktionieren,
und schon geht das Bashing (wie auch in diversen anderen Threads) wieder los ...
(Erhellend ist im Gegenzug dann das anschliessende komplizierte Fachsimpeln, das sich daraufhin über zwanzig Postings hinzieht. ️ - Was nicht heissen soll, dass ich das nicht persönlich interessant finde, welche alternativen Lösungsoptionen von anderen vorgeschlagen werden ...)

Das hier diskutierte MBP hat mit Sicherheit schonmal HighSierra gesehen - sonst wäre das Formatieren in GUID/APFS wohl nicht möglich gewesen.
Und falls man daran Zweifel hat, kann man immer noch über dd1/HighSierraPatcher einen Installationsschritt mit HighSierra machen.
Und dabei einmal die SSD auf der obersten Ebene vor der Installation formatieren, um die potentielle Melange von vllt versteckten Recoveries zu löschen.

Dass die von den dd1-Patcher erstellten Installer-Sticks bei unterstützten Macs einfach nur eine simple macOS-Installation ohne Ausführen von Patches macht, hat auf meine Nachfrage der Entwickler hinlänglich bestätigt:
https://forums.macrumors.com/threads/dosdude1-installer-bootstick-on-supported-late-early-intels.2457918/post-33931148
Aber sowas wird hier weiterhin penetrant ignoriert und die daraus resultierenden Lösungsvorschläge werden (ganz speziell von einer Person auf verschwurbelte Art, manipulativ und sich permanent selbst widersprechend) runtergemacht.
Schönen Dank auch!

 

[LuckyOldMan]

Waren jetzt deine Worte, aber vielleicht falsch gedeutet.

Bezog sich mehr darauf, dass kein Stick vorliegt, wenn sich der zugesandte HS-Stick als tatsächlich auch auf diesem Weg nicht einsetzbar erweisen würde.

..ich bin mal der Andere und ... ... habe mir kurz die Arbeit gemacht und das ganze durchgespielt auf meinem MBP8,1

Hätte ich gestern eh mangels MBP8.1, das exakt bis HS nativ arbeitet, nicht machen können, denn der Mac, den ich für den ersten Teil bis EC genommen habe, ist leider auch nur bis EC befähigt und ich wollte die reale Situation bei der TE jetzt hier nicht durch einen dd-modifizierten HS-Stick "verfälschen", sondern auch wie bei der TE möglich einen normalen HS-Stick nehmen. Alle anderen Macs hier entsprechen nicht den HW- SW-Bedingungen wie beim MBP Late 2011.
Aber hast Du ja mit Deinem MBP prima hinbekommen.

Jetzt wäre interessant zu erfahren, ob die TE @neuhier86 schon weiter als Lion gekommen ist, um dann letztlich zum bis dato angestrebten Ziel High Sierra zu kommen.

 

[T-easy]

Leute, merkt Ihr eigentlich noch was?

Hast eine PN

 

[T-easy]

@LuckyOldMan
Habe 'nur' einen mid2011, exakt gleich also nicht.

Spoiler: btw

PS: Das Rumexperimentieren ist Hobby am Bastelrechner, da geht sowas schon mal, selbst wenn es dabei wie gestern die bestehenden OS (HS+OCLP-Sonoma) zerschossen hat. Nutzt man nämlich unter EC das FPDP die 2.Partition in Extended zu formatieren, dann zerschießt er das APFS auf der eigentlich isolierten(bzw. eben doch nicht isolierten) 1.Partition.

 

[thon]

PS: Das Rumexperimentieren ist Hobby am Bastelrechner, da geht sowas schon mal, selbst wenn es dabei wie gestern die bestehenden OS (HS+OCLP-Sonoma) zerschossen hat. Nutzt man nämlich unter EC das FPDP die 2.Partition in Extended zu formatieren, dann zerschießt er das APFS auf der eigentlich isolierten(bzw. eben doch nicht isolierten) 1.Partition.

Leute habt ihr euch mal mit den Unterschieden in den APFS Versionen beschäftigt?
https://eclecticlight.co/2023/09/02/apfs-versions-updates-and-compatibility/
Da sind einige Fallstricke verborgen
Kompatibilität
Das grundlegende Sicherheitsprinzip bei APFS besteht darin, die neueste verfügbare Version seiner Werkzeuge zu verwenden, wenn Sie mit dem Dateisystem arbeiten. Wenn Ihr Mac sowohl in Ventura (APFS Version 2142.140.9) als auch in Catalina (1412.141.1) booten kann, dann sollten Sie die Werkzeuge der Version 2142.140.9 bevorzugen, wenn Sie mit seinen APFS-Volumes und -Containern arbeiten. Obwohl APFS so konzipiert und implementiert ist, dass es so viel Vorwärtskompatibilität wie möglich bietet, ist Abwärtskompatibilität vorzuziehe
Es gibt einige Kombinationen, die Probleme verursachen. Versionen von APFS vor 1412.11.7 (Catalina) verstehen weder System-Volume-Gruppen noch Firmlinks, noch die SSV von macOS 11 und später. Die Verwendung von fsck_apfs aus einer solch alten Version auf einer macOS 13 System-Volume-Group ist keine gute Idee.
Dies erfordert bei der Verwendung von Dual-Boot-Systemen besondere Aufmerksamkeit, ist aber am anspruchsvollsten beim Booten in die Wiederherstellung. Normalerweise gibt ein Mac das gepaarte Wiederherstellungsvolume für die Systemvolumegruppe ein, von der er gerade gestartet wurde, aber einige Kombinationen von macOS und Hardware tun das nicht immer, und der Benutzer kann leicht verwirrt werden. Virtuelle APFS-Dateisysteme in Disk-Images und Sparse-Bundles sind ebenfalls mit Vorsicht zu genießen, wenn von älteren Versionen von macOS darauf zugegriffen wird.

Übersetzt mit DeepL.com (kostenlose Version)

 

[bobesch]

Bei Dual/MultiBoot Systemen nehme ich für Festplatten-Operationen, wenn ich diszipliniert genug bin, das FPDP der aktuellsten macOS-Version, die installiert ist.

Edit: heute abend den (unter Lion mit dd1-HS-Patcher erstellten) HighSierra-Installer BootStick auf meinem 11" MBA (Monterey/Ventura/Sequoia) ausprobiert bis hin zum Starten des FPDP.
Erstellen eines zusätzlichen Volumes war ausgegraut. Also alles stante pede wieder runtergefahren.
Der nächste Boot des 11"MBA nach OCLP/Ventura dauerte furchtbar lange und die Grafik ruckelte furchtbar.
Nach erneutem "Post-Install Root Patch" und Reboot läuft alles wieder flüssig.
Also obacht und nicht mit einem alten FPDP in einer aktuelleren Festplatten-Konfiguration rumwerkeln ...

 

[T-easy]

Leute habt ihr euch mal mit den Unterschieden in den APFS Versionen beschäftigt?
https://eclecticlight.co/2023/09/02/apfs-versions-updates-and-compatibility/
Da sind einige Fallstricke verborgen
Kompatibilität
Das grundlegende Sicherheitsprinzip bei APFS besteht darin, die neueste verfügbare Version seiner Werkzeuge zu verwenden, wenn Sie mit dem Dateisystem arbeiten. Wenn Ihr Mac sowohl in Ventura (APFS Version 2142.140.9) als auch in Catalina (1412.141.1) booten kann, dann sollten Sie die Werkzeuge der Version 2142.140.9 bevorzugen, wenn Sie mit seinen APFS-Volumes und -Containern arbeiten. Obwohl APFS so konzipiert und implementiert ist, dass es so viel Vorwärtskompatibilität wie möglich bietet, ist Abwärtskompatibilität vorzuziehe
Es gibt einige Kombinationen, die Probleme verursachen. Versionen von APFS vor 1412.11.7 (Catalina) verstehen weder System-Volume-Gruppen noch Firmlinks, noch die SSV von macOS 11 und später. Die Verwendung von fsck_apfs aus einer solch alten Version auf einer macOS 13 System-Volume-Group ist keine gute Idee.
Dies erfordert bei der Verwendung von Dual-Boot-Systemen besondere Aufmerksamkeit, ist aber am anspruchsvollsten beim Booten in die Wiederherstellung. Normalerweise gibt ein Mac das gepaarte Wiederherstellungsvolume für die Systemvolumegruppe ein, von der er gerade gestartet wurde, aber einige Kombinationen von macOS und Hardware tun das nicht immer, und der Benutzer kann leicht verwirrt werden. Virtuelle APFS-Dateisysteme in Disk-Images und Sparse-Bundles sind ebenfalls mit Vorsicht zu genießen, wenn von älteren Versionen von macOS darauf zugegriffen wird.

Übersetzt mit DeepL.com (kostenlose Version)

Gute Informationen, trifft aber nicht wirklich auf die Situation in meinem Spoiler zu. eher am schon das was Bobesch schrieb.

Spoiler: Partitionstabelle in EC zerstört

Das APFS hatte ich dabei nicht angefasst. Ich habe die Planspiele auf zusätzlichen Partitionen durchgeführt, dass einzig APFS war auf Partition 1 isoliert. Die Partition 2 wurde in Sonoma erstellt und in Extended formatiert. Damit hat das gar keine Schnittmenge mehr mit APFS.

Mein Fehler war ein anderer. Ich hatte aus EC heraus ja HS installiert und das ging nicht in einen APFS Container,>Volumen herein, weil ja unter EC unbekannt(und auch im simulierten Ablauf nicht umsetzbar). Und EC 'drüber bügeln' wollte ich nicht. Dann der Fehler: ich habe die Partition2 in EC geteilt(...hätte ich das mal lieber in Sonoma gemacht) und damit Partition3(Extended) erzeugt und darauf das HS installiert.

Bei Neustart war dann das APFS der eigentlich unbetroffen Partition1(APFS) nur noch ein undefinierter Bereich der SSD.
Ich gehe mal davon aus, dass unter EC die Partitionstabelle global neu geschrieben wurde und damit der Eintrag der Partition1 verfälscht wurde. Das ist aber tatsächlich ein Sonderbastelfall und daher im Spoiler.