Beiträge von cobanramo

    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

    Denke das das vom unterschiedlichen funktion builds vom jeweiligen MacOS kommt,

    ist ja auch verständlich, vorhin hat sich jemand mit der gleichen Icloud & gleichen Smbios angemeldet,

    jetzt meldet die gleiche Konto mit der gleichen smbios aber ne andere MacOS version.
    Wenn das paarmal passiert muss ich ja fast checken ob da alles mit den richtigen dingen zugeht, es geht vermutlich um die informationen vom "Wo ist? & Tracking"
    denke ich mal...

    Gruss Coban

    Denke schon das der script funktioniert, aber denke einige sind von der Anleitung bissl irritiert, da erstens das problem mit der bestehenden Efi zum anderen der vergrösserung der bestehenden Efi usw. missverstehen.

    Guck es gibt grundlegend 2 sachen, "diskutil" selber erlaubt dir NICHT einen EFi Partition mit anderer Grösse zu erstellen, der kann nur Typ "Efi" erstellen, der ist dann fix 200MB, alles was du noch danach mitgibst erstellt es eben als Fat32 Partition.


    Guck dir mal den Command genauer an, wirst auch erkennen das man da kein Typ Efi mitgeben kann, das ist genau das was Apple will.

    Anderseits bedient sich auch Apple den "gpt" Tool, der wiederum kann dann benutzerdefinierte typen.


    Wenn man einen wirklich benutzerdefinierten Partition schema haben will, und das ganze sagen wir mal unbedingt unter MacOS Terminal passieren muss, keine alternativen Tools in frage kommen kann man das im folgendem beispiel erledigen.


    Angenommen du hast ein Rechner, mit 2 SSD Laufwerke drin, sagen wir mal das eine ist System, das andere Daten, jetzt hängen wir noch ein drittes "LEERES" Laufwerk ins System.

    /dev/disk0 --> MacOS
    /dev/disk1 --> Daten

    /dev/disk2 --> "Leer, hier werden wir einen benutzerdefinierten Partitionschema erstellen und den System vom disk0 klonen..."

    Diskgrössen sind ja nicht relevant, musst halt die commands anpassen je nachdem was man hat oder was man braucht usw..

    starte einfach den Terminal, sei es unter MacOS oder Recovery...

    diskutil list, guck dir die identifier mal genau an was wirklich wo angehängt ist.


    diskutil info /dev/disk2 | grep "Block Size"

    Device Block Size: 512 Bytes sollte es normalerweise ausgeben...


    1. diskutil unmountdisk disk2

    2. gpt destroy /dev/disk2

    3. gpt create -f /dev/disk2

    4. gpt add -i 1 -b 40 -s 6291456 -t efi /dev/disk2

    hier erstelle ich auf index 1, beginning sector 40, count 6291456 (das sind 3gb), typ Efi auf disk2.....

    wie wird das gerechnet? LBA`s ;-) rechnen ist angesagt, oben wissen wir das eine Block Size 512 Bytes sind, ich will 3gb Partition haben, 3GB = (3221225472 Bytes ÷ 512 Bytes) = 6291456 LBA, soweit verständlich?


    5. gpt add -i 2 -b 6291496 -s 190000000 -t apfs /dev/disk2

    hier erstelle ich auf index 2, beginning 6291496 (40 blöcke hab ich dazu gezählt für den sauberen abstand), count bspl. 190000000 (das sind ca 90 Gb), typ apfs auf disk2...

    Hier auch die grössen halt nachrechen oder sich halt im Netz mit LBA Calculator bedienen usw..


    6. diskutil list --> jetzt siehst du das du ein 3gb Efi & 90gb apfs partition erstellt hast...

    musst nur noch diese partitionen halt formatieren oder auch im Festplattenmanager im Recovery "löschen" usw. usf..

    bspl.

    newfs_msdos -F 32 -v EFI /dev/disk2s1
    newfs_apfs /dev/disk2s2


    7. jetzt kannst du ganz einfach deinen script oder auch mit einem Command das ganze rüber Clonen..

    sudo asr restore --source "/dev/$SOURCE_DEVICE" --target "/dev/$TARGET_DEVICE" --erase --noprompt --noverify


    bootfähigkeit ist ja klar in dem sinne...

    sudo bless --folder "/Volumes/Klon-Ziel/System/Library/CoreServices" --bootefi --setBoot


    Kannst evtl. sogar deine Script eben auch so erweitern usw.


    Anderseit erkennst du jetzt sicher auch warum das ganze so ungern gemacht wird und am besten gleich zu einem Linux Gpart ausgewichen wird, es ist einfach unkomfortabler weil Apple eben das so haben will...

    Gruss Coban

    EDIT:
    HIer ist vielleicht ein idee entstanden womit du dein Tool erweitern könntest Noir0SX :-D
    ein LBA Calculator ? :-)

    auch auf dem laufenden System möglich

    Das dachte ich auch mal aber leider ist dies mit Hauseigenen "Diskutil" & "gpt" tools nicht ganz möglich.

    Man kann mit Diskutil "apfs" mergen, shrinken, vergrössern aber eben nicht verschieben, dachte auch mal das gibts doch ned da übersehen wir ein command aber den gibts wirklich ned. Bei einem bestehendem Apfs Container kommst du nicht drum herum, lässt nicht zu, musst linux gpart zugreifen um zu verschieben, wenn du schon dort bist kannst auch den rest dort erledigen bin ich der meinung. :-)


    Gruss Coban


    EDIT: hier nochmal ausdrücklich mit vorsicht, mit gpart verschieben, ja nicht in den versuchung fallen zu verändern, einmal was dran gebastelt ist es vorbei, könnt grad das ganze formatieren, gpart kann keine apfs Partitionen bearbeiten !

    Das "Forum" und meiner wenigkeit ging zwar aus irgendeinem grund davon aus, das du das ganze bei einem "bestehendem" System über Terminal machst.. :-D


    Spass bei seite, klar kann man auch so machen, viele wege führen nach Rom, am einfachsten finde ich immer noch über Linux, ist schnell und unproblematisch so wie man es haben möchte erledigt... :-)

    bootfähige Kopie (Clone) einer macOS Sequoia-Partition mithilfe von Terminal-Befehlen

    Why not, irgendjemandem wird es bestimmt mal weiterhelfen, immer her damit..

    Gruss Coban

    Eine EFI aus dem Linuxuniversum geht das n.m.K. nicht.

    Eine Efi (oder korrekter ausgedrückt eine ESP Partition) ist eine Efi, egal von welchem Universum es stammt, und das ausschlaggebende unterschied zu einem stinknormalem Fat32 partition ist nur die "ESP/EFI Flag".

    Kann beliebig wo oder gross sein und hat kein einfluss auf das startverhalten der System selber, ausser eben wie bei bestimmten Betriebsystemen (bspl. Apple) die das an einem bstimmten ort oder grösse in ihren installationsscripts erwarten.

    Undzwar geht es hier nicht mal um die installation des Betriebsystems sondern um die Firmware update des Mac`s (stichpunkt Apple Ordner).


    Wenn man die gpt command von der Unix Welt beherscht kann man wohl auch ein eigenes zugeschnittenes Partitionsschema unter MacOS Terminal zusammenschustern.


    Wenn man unbedingt ne grössere Efi Partition braucht, warum auch immer, gründe gibts genug, ist es am einfachsten für otto normal verbraucher das man seine Container mit "sudo diskutil apfs resizeContainer" den gebrauchten "freien" platz verkleinert; einfach den Linux Gpart startet und den Apfs partition nach hinten verschiebt (nicht ändern, verschieben) danach den Efi auf die gewünschte grösse vergrössert. Wenn es gelöscht wird oder neu erstellt wird sollte man einfach drauf achten das die ESP Flag gesetzt ist.


    Bei Dualboot Systemen ist es immer von vorteil den Efi partition auf erster stelle zu haben, somit befriedigt man direkt Apple, Microsoft und die Linux Welt, ist halt nur Apple der sich drüber aufregt wenns nicht so ist, der rest schert sich ein dreck drum. :-)

    Gruss Coban

    Mit FileVault verschlüsselt hat du da keine Chance, da musst du die Nvme schon an eine „echte“ ( da bin ich mir ned so sicher, evtl. geht das auch an einem Hackintosh) Mac anschliessen und entschlüsseln lassen.

    Dazu brauchst du natürlich den Key dazu, evtl. geht da auch die iCloud Identifizierung des Keys.


    Gruss Coban


    Edit:

    Wenn du ne ähnliche Macbook von jemand ausleihen könntest wäre das sicher in ein paar stunden entschlüsselt und übertragungsbereit denke ich mal.

    Die fehlnden Einträge im NVRAM (Delete bluetoothExternalDongleFailed + bluetoothInternalControllerInfo)

    Warum sollten sie auch was bringen wenn du das in NVRAM/Delete hinzufügst?

    Du musst das so vorstellen;
    Alles was du unter NVRAM/Add dazu gehörigen Container hinzufügst wird beim Boot gelesen und angewendet.

    Alles was du unter NVRAM/Delete dazu gehörigen Container hinzufügst wird beim neustarten herausgelöscht um vom ADD wieder frisch hinzugefügt zu werden.

    Das erspart dir einfach einen NVRAM Reset und beugt zbspl. vor veraltete Nvram Einträgen die das Ergebnis fälschen könnten usw...


    Gruss Coban

    EFIs die geladen werden im Mainboard (MSI Z590) via EFI Key Enrollment autorisiert.

    Das wäre das eine...

    anfängliches bemängeln bestimmter .efi's kommen nun nicht mehr. Ich sehe den macOS Boot Selection screen (macOS, macOS Recovery Image, NVRAM Reset), wo er automatisch in "macOS" bootet

    Hier wird eben vom OpenCore beim laden der MacOS auch ein boot.efi aufgerufen...

    bspl. vom OC Debug log ; \F05C2F61-2AA0-4D07-88DB-9E3ABDF55967\System\Library\CoreServices\boot.efi


    Den müsste man eben auch im Bios "enrollen", weil das aber vom Bios aus nicht gelesen werden kann (apfs) musst du auch im Config.plist den Apple SecureBoot aktivieren,

    Default oder halt je nach Smbios Model den du einsetzst.


    Erst jetzt wird MacOS starten, aber du landest natürlich im ersten moment in den Recovery modus.

    Hier im Recovery musst du noch den Terminal anwerfen und mit dem command "bless" "Personalisieren"

    bspl:

    bless --folder "/Volumes/<MeinMacOS>/System/Library/CoreServices" --bootefi --personalize

    Hier ist auch zuvor zu beachten das man einen funktionierenden Netzwerk & Internetzugang im recovery modus hat.

    keine Arbeit vor einem OC Update SecureBoot auf disabled zu setzen

    Oh doch, das kann je nach wieviel Efi Driver du lädst mühsam sein,

    nach jedem Update der Efi, auch MacOS update`s oder auch upgrade`s muss man dann auch diesen theater nochmals durchspielen.

    Ob sich das für dich lohnt muss du halt selber entscheiden, ich habs aufgegeben und abgeschaltet, so wichtig ist diese funktion für privat Anwender doch nicht.


    Gruss Coban