Beiträge von cobanramo
-
-
Blödsin, warum sollte ein CometLake nicht funktionieren? Apple selber liefert auch CometLake IGPU`s.EDIT:
Halt dich einfach an die folgende Link;
https://dortania.github.io/Ope…-lake.html#starting-point
das ganze funktioniert auch mit Igpu (HeadLess) auf einem RoketLake Chipsatz oder eben ganz normal auf einem CometLake Chipsatz.
natürlich ist ein rx580 wesentlich besser und auch einfacher handzuhaben.Hab tatsächlich glatt übersehen das Ihr das auf einem Z590 (RocketLake) mit Igpu anfeuern wollt.
11. Gen. Das ist RocketLake. Der hat ne UHD Graphics 750 und dafür gibt es kein MacOS Treiber.
Z490 ist eben ein reiner CometLake, der kann das ganz normal sowie vom Apple selber.Hab das bissl schnell überflogen und falsch verstanden.
Gruss Coban
-
10th Gen Intel Core iGPUs
https://www.intel.de/content/w…0-ghz/specifications.html
iGPUs in Kombination mit den neueren Z590 Chipsets funktionieren unter macOS nicht.
-
Steuerung freigegeben
Bildschirm Aufzeichnung freigegeben
Festplatte Freigegeben
Remote Desktop freigegeben ( wird aber in der Teamviewer Prüfung nicht mit Blauen Hacken bestätigt)
Wenn das alles freigegeben und die app neugestartet wurde und immer noch nicht bestätigt wurde hast du so ziemlich sicher ne Firewall oder ähnliches die das blokiert.
Bspl.
Oder ne drittanbietersoftware die das verhindert...
Das hat alles nichts mit Kexten oder Efi zu tun, wenn dein macOS gestartet ist ist das mit EFI & Kexten schon längst geschichte...
OCLP ist nicht OpenCore oder Clover Bootloader, OCLP ist eine patchsammlung die deinen Recher präpariert um eine aktuellere macOS zu installieren.Gruss Coban
EDIT: oder teste mal den alternative dazu ob das gleiche probleme zeigt..
https://rustdesk.com/de/ -
Resultat: Ein paar Minuten Beachball
Die haben beide den gleichen Namen. Kann das die Ursache für das Problem des Auswurfs sein?
Kaum, neu installiert hat zu 100% auch ne neue UUID bekommen, es spielt keine rolle ob die Namen gleich sind.
Mögliche oder die wahrscheinlichere ursache ist bestimmt die nicht mehr lesbaren sektoren oder falsch gelieferte Datensegmente denke ich mal.
Du musst schon sicher sein wovon du startest, nicht das du ne alte Mojave Sicherung mit einem alten Efi startest...
Oder auch ne neue aktuellere Efi könnte evtl. nicht für den alten Mojave konform sein usw..
je nach dem halt..
Gruss Coban -
Es scheint das die "AirportBrcmFixup" nicht sauber funktioniert, du hast erstens ne ältere version installiert, 2. könnte sein das du die Treiber falsch lädst...
https://github.com/acidanthera/AirportBrcmFixup
Welcher Broadcom Chip ist es den überhaupt, der originale oder ausgetauscht? je nachdem musst du das angehen ob du ne Modern Wifi patch benötigst, es hat nichts mit m.2 SSD zu tun...
1. Deaktiviere komplet Wlan relevantes und teste aus ob du immernoch probleme hast, je nach dem weisst du ja dann wo du anpacken musst.
Gruss Coban
-
Mit soviel offenem Wissen sollte doch der auch ne level besser sein...
-
Boot-Argumente -wegnoegpu und -igfxvesa hinzuzufügen
i9 14900kf
https://www.intel.de/content/w…0-ghz/specifications.html
Gruss Coban
-
Frage: Bist du 100% sicher, dass du auch Yosemite gebootet hast als du das Video gemacht hast?
Da steht das mit --applicationpath zuletzt bei El Capitän, und alle Systeme die danach kommen sind ohne --applicationpath.
Dein Denkfehler ist das wir hier unter Yosemite keinen Yosemite installer erstellen wollen, wir wollen unter Yosemite BigSur installer erstellen, so war die ausgangslage beim schreiben dort, die attribute --applicationpath bezieht sich auf die installer App und nicht auf die ausgeführte MacOS selbst.
Gruss Coban
Edit: obwohl da unten auch sowas steht dachte ich zuerst das kann evtl. ne übersetzung fehler sein aber anscheinend ist das nicht so, auch im englishen steht das so, irgendwie sinnfrei...
Auf jedenfall stimmt die Command vom Bigsur wie auch auf dieser Support Doc und die BigSur Stick wird auch unter Yosemite erstellt.
Gruss Coban
-
unter Mojave ist der Terminal Befehl von cobanramo weiter oben korrekt.
Fred, hast du den Video auch angeguckt?, das hab ich unter Yosemite erstellt..
Gruss Coban
-
Ich unternehme morgen einen letzten Versuch
Ich gehe mal davon aus das du das ganze nicht auf einem Windows versuchst
Mit den Tools kannst das ziemlich einfach lösen, falls du auch probleme damit hast einfach den folgenden Video mal angucken...
1. auf deinem alten MacBook mit Yosemite einen USB Stick einstecken und dessen Name mal merken...
2. muss die geladene BigSur Installations app im Programme Ordner sein, erkennst du in dem du im Launchpad den Symbol siehst.
3. Terminal starten den folgenden Command einfügen..
sudo /Applications/Install\ macOS\ Big\ Sur.app/Contents/Resources/createinstallmedia --volume /Volumes/MyVolume
Die MyVolume am schluss der Command MUSS deinem USB Stick Name entsprechen, siehe Video.
4. Enter und durchlaufen lassen, fertich...
5. Du startest deinem Desktop rechner mit dem OpenCore Stick und im Menü angekommen wartest du jetzt, nichts anwählen.6. Steckst jetzt diesen NEU erstellten BigSur Stick in ein Usb Port dazu rein und auf dem tastatur 1x ESC taste wählen.
7 Jetzt siehst du den "BigSur installer" dort im Menü, startest diesen.
8. Angekommen im BigSur installer startest du dort den Festplatten Manager und "löschst" den neuen Nvme den du eingebaut hast mit Guid & Apfs..
bspl..
9. Jetzt beendest du den Festplatten Manager und fährst ganz normal mit der installation fort, als ziel gibst du diesen frisch formatierten "BigSur" als Disk an, fertich...
10. Du startest IMMER bei jeder neustart der Rechner mit der OpenCore Stick, bis das ganze abgeschlossen ist, beachte einfach das du noch keine OpenCore EFI auf dem Rechner hast, daher immer mit diesem Stick starten bis das rüberkopiert und von dort gestartet wurde.
Der rest sollte im grunde klar sein...
[Externes Medium: https://youtu.be/WDgzcOj-zgY]
Gruss Coban -
Einen guten sagen wir mal "beigeschmack" hat dieses problem doch gezeigt, man liest in theorie viel drüber aber zum erten mal in action gesehen.
Western Digital Nvme´s (hier in diesem Fall ein WD SN570) haben ne Sicherheits Modus eingebaut die tatsächlich auch funktioniert.
Man kennt oder liest ja das die SSD´s & Nvme`s bei defekten Sectoren "reserve Sectoren" haben die dann bei ausfall einspringen.
Wenn genug fehler vorhanden sind und die reserve Sectoren ausgegangen sind schaltet das ding komplett nur noch auf Read Only modus um, damit soll verhindert werden das weitere fehler beim beim schreiben dazukommen und zu Datenverlust kommt.
Ergebnis ist dann halt Kernel panic da das System nichts mehr schreiben kann.
Ergo; Smart Monitor "Kritisch"
In diesem Modus kann man noch seine Daten lesend retten...
Gruss Coban
-
Kann ich bestätigen, ursache? So ziemlich sicher OCLP...
eindeutig "IOSkywalkFamily.kext", müsste man mal ohne den OCLP patch testen aber dann hapert an der Wlan....
Ist aber seit 15.2 & Oclp 2.2.0 so bei mir, kann mangels test nicht sagen ob an MacOS oder direkt vom Oclp selber kommt, eher vom Oclp da "altes" IOSkywalkFamily.kext denke ich, mit Kabel geht es ja...
Gruss Coban
-
-
Du hast ACPI probleme, du lädst möglicherweise falsche ACPI Tabellen...
Das ganze endet mit einem Kernel Panic...
EDIT: Den Panic löst die NVME Controller aus...!
Du lädst vermutlich mal falsche oder fehlende Acpi Tabellen...
Auch möglich das du flsche Quirks gesetzt hast...
Hat diese EFi den du gestartet hast schon mal funktioniert?
https://dortania.github.io/Ope…-lake.html#starting-point
Wie gesagt, mehr kann ich am Samstag, meine Hausdrache guckt mich schon schief an...
Gruss Coban
-
Die einzige Fehlermeldung (roter Punkt), die ich noch in OCAT bekomme, ist die mit dem memtest86
das ist auch nicht relevant zu deinem problem, OpenCore startet ja oder? ignoriere das einfach mal.
memtest86 (Path in OCAT: memtest86/BOOTX64.efi), in dem angeblich meine BOOTX64.efi liegt
Wie gesagt, das ist ne andere geschichte und hat nichts mit deinem OpenCore start oder MacOS start zu tun, diese fehlende "BOOTX64.efi" dort hat was mit dem start vom memtest86 zu tun und hat mit dem start von OpenCore oder Betriebstytem nicts am Hut. Ignoriere das mal bis du ein gestartetes BigSur hast, danach kannst du das mit memtest angehen wenn du das unbedingt haben musst.
kommen schonmal ein paar der obligatorischen weißen Zeilen aber dann lande ich doch wieder im Motherboard Startscreen. Die Frage, die ich mir Stelle ist, liegt das an der EFI oder BigSur?
Zeige mal Bilder von diesem verhalten, da steht doch was in diesen Zeilen, auf das kommt es an....
PS: Falls jemand Willens ist mir gegen Bezahlung etwas mehr "Tech Support" zu geben, schreibt mich gerne mit einem Preis an!
Das ist jetzt nicht dein ernst oder?
Also wenn du zuviel zaster hast .. was soll ich da noch sagen? vieviel wärst du den bereit abzugeben?, dann wär ich bereit am Samstag dein Geld abzunehmenGruss Coban
-
Wenn ich normal, so wie immer boote, bekomme ich folgenden Screen:
Mit normal verstehe ich das das mit normalen EFI Partition Efi dieser fehler kommt, oder?
Dieser fehler bedeutet das du in diesem Ordner den "OpenUsbKbDxe.efi" rausgelöscht hast, ergänze diesen oder deaktiviere es im Config.plist, dann kommst du dort weiter.
Beim ergänzen solltest du möglichst den passenden version von diesem Treiber zu Opencore version haben, sonnst kann es möglicherweise auch nicht laden.Und wenn ich von meinem EFI-Backup-Stick boote, kommt das ganz schnell und oft hintereinander und bleibt dann stehen:
Das deutet darauf hin das dein Backup eher defekt ist und das da viel mehr nichts mehr passt...
Würd ich auch nicht mehr verwenden....Kannst du unter Windows deinen EFI ordner zugreifen? Wenn ja ergänze einfach den "OpenUsbKbDxe.efi" im Drivers Ordner oder öffne den Config.plist mit einem text editor und
finde diesen eintrag und ändere zu false wie auf dem Bild, speichern und neustarten, schon sollte es weitergehen...
Gruss Coban
-
Hat meine USBToolBox.kext automatisch einen ausführbaren Pfad wenn ich die in den EFI-Ordner kopiert habe? Weiß das jemand?
Wenn du den Kext bei geöffneter OCAT Tool in den Kext Ordner kopierst oder auch auf den App ziehst wird es ein ausführbaren Pfad bekommen, ohne gestartetem Tool wird es keins haben und müsstest nachtragen oder eben nochmal reinkopieren...
bspl. auf dem Bild siehst du es ob es ein bekommen hat oder nicht...Das andere fehler ist ja eigentlich selbsterklärend oder?
Ergo: must have LoadEarly set to FALSE!
Kann ich die BOOT- und OC-Order einfach per Strg+C/V im Datei-Manager einfügen oder gibt es ein bestimmtes Procedere, das ich einhalten muss?
Wenn du ein "Boot & OC" Ordner hast von dem du sicher bist das Sie läuft, bspl. von einem Backup usw. kannst du das natürlich reinkopieren und den alten überschreiben.
Beachte aber die Ordnerstrucktur, Die beiden Ordner sind in einem EFI Ordner drinne auf dem Efi Partition, dementsprechend auch Ordner & Dateien ersetzen...
bspl.as eventuell zur Demystifizierung des Crashes beitragen kann
Was hast du da für ein Crash? Hast du mal Bilder davon?
Ist es möglich, daß ein solches Programm etwas löscht, das von meinem Hacky benötigt wird?
Normal sollte es nicht, wenn aber was Systemrelevantes gelöscht wurde und daher dein System nicht startet hat das alles aber nichts mit der Efi zu tun
Gruss Coban -
Vielleicht sollte man hier mal erwähnen das man nicht pauschal eben diese Tools vertrauen und für diese werbung treiben sollte.
OCAT aktualisiert den OpenCore & die Kexte zumteil über die "Dortania Builds", vor allem wenn es aktuelle Dev Builds sein sollen.
Interessanterweise funktioniert diese "Dortania Builds" seit Wochen gar Monate nicht !, dementsprechend liefert das Tool eben auch nur alte Kexte & OpenCore Versionen aus.
Entweder merkt das noch niemand oder glaubt updatet zu haben, guckt euch mal den stand vom Acidanthera an und vergleicht mal den Dortania Build stand.Das da immernoch niemand darüber gemeckert hat ist auch so ne indikator...
Wer auf und mit sollchen Tools sein Hack aufbaut der wird garantiert auf der strecke bleiben und auf andere angewiesen sein.
Es ist mittlerweile wieder soweit das man wie am anfang manuel das ganze auf vordermann bringt.
Gruss Coban
-
sollte eigentlich selbsverständlich sein oder?
15.3 Beta --> -lilubetaallGruss Coban