Beiträge von cobanramo

    Hab es schon damit probiert, kam aber kein neues Apple Setup nach dem Starten:

    rm “/Volumes/Macintosh HD/var/db/.AppleSetupDone” offline

    Falscher Weg, wenn du diesen weg gehst löscht du die bestehende DB, somit wirst du andere probleme haben, hoffe mal das du dies nicht geschaft hast...

    Dieser Weg hier fügt dir ein neues User in deine bestehende DB ein...

    Hier in meinem beispiel ist es eine Ventura, mit der Disklabel auch Ventura, ergo heist es bei mir "Ventura - Daten", bei dir müsste es "Macintosh HD - Daten" sein.

    Es gilt zuerst herauszufinden wie es richtig heisst.

    Die korrekte Command lautet dann so in etwa....


    Recovery starten, oben im Menü den Terminal starten und folgendes durchtippen...

    Code
    1. dscl -f "/Volumes/Ventura - Daten/private/var/db/dslocal/nodes/Default" localonly -create /Local/Target/Users/TestAdmin
    2. dscl -f "/Volumes/Ventura - Daten/private/var/db/dslocal/nodes/Default" localonly -create /Local/Target/Users/TestAdmin UserShell /bin/bash
    3. dscl -f "/Volumes/Ventura - Daten/private/var/db/dslocal/nodes/Default" localonly -create /Local/Target/Users/TestAdmin RealName "TestAdmin"
    4. dscl -f "/Volumes/Ventura - Daten/private/var/db/dslocal/nodes/Default" localonly -create /Local/Target/Users/TestAdmin UniqueID "1050"
    5. dscl -f "/Volumes/Ventura - Daten/private/var/db/dslocal/nodes/Default" localonly -create /Local/Target/Users/TestAdmin PrimaryGroupID 80
    6. dscl -f "/Volumes/Ventura - Daten/private/var/db/dslocal/nodes/Default" localonly -create /Local/Target/Users/TestAdmin NFSHomeDirectory /Users/TestAdmin
    7. dscl -f "/Volumes/Ventura - Daten/private/var/db/dslocal/nodes/Default" localonly -passwd /Local/Target/Users/TestAdmin 12345
    8. reboot

    Jetzt nach dem reboot solltest du auch ein Administrator Account mit der Name "TestAdmin" bekommen und mit 12345 anmelden können...

    Hoffe mal das auf deinem Rechner keine 50 User eingerichtet worden sind, daher UniqueID "1050" dieser 1050 darf nicht schon mal vergeben worden sein.


    Gruss Coban

    Wenn du zugang zum System selber hast kann ja nichts sicher sein, daher...
    Bei MacOS kannst du sogar das Admin Password selber über Recovery schön sauber überschreiben, das ist nur ne scheinschicherheit.

    Bei einem "sicheren" System ist das relevante Sache auf dem Firmen recourcen und über einen sicheren kanal zu erreichen, man vergibt auf die lokale Rechner keinen Administrator rechte um die lokalen änderungen und anpassungen sagen wir mal grenzen zu setzen um die Support zu erleichtern, natürlich auch "Kontamination" einzudämmen. Jedenfalls sollte ne sichere architektur so aufgebaut sein, mit einem lokalen Konto kann das nie gut ausgehen.
    Naja vielleicht mit einem 5 Mann Betrieb wenn 4 davon DAU sind... :-)


    Gruss Coban

    mobodick


    Es ist eagl in wlehcer rienhnelfoge die Bcuhtsbaen in eniem Wrot sethen, das enizg wcihitge dbaei ist, dsas der estre und lzete Bcuhtsbae am rcihgiten Paltz snid.

    Bei dnieem poitrsg hbae ich rhciig mhüe...


    Gruss Coban

    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

    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

    Klingeldraht

    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

    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

    Ich unternehme morgen einen letzten Versuch

    Ich gehe mal davon aus das du das ganze nicht auf einem Windows versuchst :-P

    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... :-D


    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? :-D
    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 abzunehmen ;)


    Gruss Coban