Beiträge von cobanramo

Zitat von karacho

Wie soll ich eine CMD Shell starten bei einer Fresh Installation

Kannst doch nach der installation immer noch mit "F8" optionen anwählen

Wenn du es noch tiefer eingreifen willst wie zbspl. vergessene Pw ändern usw. einfach per installations Stick starten und in den Terminal wechseln.

hier im installierten Windows Verzeichnis den

rename utilman.exe utilman.bak, copy cmd.exe utilman.exe;

Danach hast du den Terminal vor dir wenn du den "Erleichterte Bedienung" anwählst.

In dieser phase ist die Windows wie ne Schweizer Käse

Gruss Coban

Zitat von karacho

hab irgendwo gelesen, dass man es dann überspringen könnte

einfach den CMD Shell starten;

löst das problem

Gruss Coban

Zitat von Arkturus

„Die Installation konnte nicht abgeschlossen werden, die Änderungen am System werden nicht gespeichert.“

Wenn das meldung kommt konnte es installieren aber den bootloader nicht konfigurieren.

Das hat mehrere, verschiedene gründe, ein CDROM/DVD laufwerk zbspl der im Bios als "first" eingestellt ist löst so was auch gerne aus.
Bei gewissen konstellationen funktioniert die install script vom MS einfach unerklärlich nicht mehr.

lösung für das problem ist einfach;
Boote einfach den Installer nochmal vom USB Stick.

starte den CMD Shell und weise mit diskpart dem Efi partition einen Buchstaben, danach wie im ersten posting mit bcdedit den booteintrag erstellen;

bspl.

Zitat von Doctor Plagiat

Die EFI (vol 1) hat keinen LW-Buchstaben, wird aber benötigt, da der Windows-Boot-Manager da drauf muss.

sel vol 1

assign letter=z

bcdboot c:\windows /s z: /f all /l de-de

bcdboot X:\Windows /l de-de /f UEFI /s E:\

Mit X = Windows (ist die wirkliche installationspfad vom Windows gemeint, das kann mal anders lauten bei mehreren Installationen; ergo guck es im diskpart nach.

Mit E:\ = ESP (ist die laufwerkzuweisung für die zuletzt zuwewiesene EFI gemeint.

Nach einem neustart sollte dein fehlgeschlagener Windows installtion auch starten können.

Gruss Coban

Du kanns dein Lan & Wlan aktiviert haben, lies einfach diesem thread mal durch...

Sonoma Intel I225-V

Gruss Coban

Zitat von Arkturus

Vielleicht stimmt die Syntax nicht, denn am KBL-Desktop ist die acpi.txt auch leer.

Das Command funktioniert schon, hast vermutlich nur nichts zu anzeigen da dein Rechner schon ne weile läuft und die dmesg keine "ACPI" einträge mehr im Log buffer findet. Du solltest den Command unmittelbar nach einem Boot ausführen oder noch viel besser den "DebugEnhancer.kext" einbinden.

Da hast du dann auch genügend informationen in deinem Log.

Wenn du erweiterte informationen zu einer bstimmten Thema im log suchst solltest du auch den Debug version von diesem Kext drin haben.

Bspl.

Whatevergreen --> Debug Version

bootarg = -wegdbg

sudo dmesg | grep "whatever" > $HOME/Desktop/whatevergreen.txt

Da siehst du mal was alles so Weg macht...

sudo dmesg | grep "ACPI" > $HOME/Desktop/acpi.txt

So kannst du dann auch geziehl nach informationen herausfiltern und auf den Desktop legen, Alles ">" muss natürlich nicht sein wenn du die info nur im Terminal sehen willst.

Gruss Coban


PS: Hackintool macht ja auch nichts anderes, dort kannst du auch dein Log checken...

Bin ja auch nicht ganz der ASL Fritz und kenne mich nicht mit deinem Laptop aus aber ich würd jetzt behaupten das das nicht ganz gut klappen kann...

In deinem ORIGINAL DSDT hast du schon einen Device HDEF...

Du kannst jetzt nicht noch einmal mit einem SSDT-HDEF.aml kommen und den gleichen Device verändern wollen.

Das endet mit einem Fehler, ganz klar.

Meiner meinung nach müsstest du um sowas zu erreichen eben den vorhandenen Hdef deaktivieren und einen anderen Device anstelle der original mit veränderten Daten kommen, dafür sind ja die SSDT`s da, SSDT = Secondary System Description Table.

Während du sollche änderungen vornimmst musst du eben auch darauf achten und wissen was du da machst, denn sollche änderungen gelten eben für alle Betriebsysteme, das heisst deine HDEF Device ist dann auch für den Windows genau so, wenn die Treiber die Windows dafür lädt nicht mitspielt crasht es, ganz einfach.

Hier kommt dann eben diese _OSI weiche die du ins SSDT einbaust ins spiel, der guckt dann was sache ist, wenn "Darwin" gestartet wird heisst das für ihn das diese table gilt und die Device HDEF so wie es da steht geladen wird, ansonsten wenn Windows kommt schaltet es aus und es gilt die HDEF Device im originalen DSDT, ergo ist das dann so wie der Hersteller vorgesehen hat für Windows.

Ausserdem bin ich der meinung das das alles mit DSDT veränderungen zu lösen veraltet und unnötig ist.
Das ist dann stures System der immer das gleich gute oder fehlerhafte ladet, daher weg mit DSDT und arbeite nur mit SSDT`s.
Am besten jedes modifizierte Ding ein eigenes SSDT, weil da weisst du dann auch was funktioniert/geladen wurde und wo es fehler gab und nicht geladen wurde. Klar, man kann alles in einem DSDT packen, oder gar auch alles in einem einzigen SSDT usw. nur bringt das gar nix ausser eben unerfahrenene oder besser gesagt die leute die das nicht beherschen ins grübeln zu bringen und das Handtuch werfen.
Alles in einem wird dann eben auch entweder geladen oder auch nicht, auch wenn darin 99% korrekt war, bei einem Fehler wird die Table nicht geladen.

Checken kannst du immer mit diesem Command was der zustand deiner ACPI Table`s auswirft.

sudo dmesg | grep "ACPI" > $HOME/Desktop/acpi.txt

Ergo, weg mit DSDT, benutze das Original DSDT vom Bios selber, patche einfach nur das was für MacOS nicht passt per SSDT einzeln, löse ein problem nach dem anderen, baue immer ein SSDT mit OSI weiche die dann auch NUR für Darwin gilt und das rest IMMER das original benutzt.
Nur so wirst du auch pö a pö zum ziel kommen, ansonsten sieht man ja das manche leute an einem Gerät jahrelang basteln aber nie zum ziel kommen

Hier ist auch ein SEHR guter anlaufpunkt für SSDT`s und einzelne probleme, die euch erlauben zu verstehen wie es zu lösen gilt.

Gruss Coban

Zitat von Arkturus

oder genügt es die SSDT-OC-XOSI.dsl zu compilieren?

Das hängt von deiner DSDT strucktur ab, normalerweise sind diese Rechner eben vorgesehen für Windows und höchstens noch für Linux.
Wenn der Hersteller vorgesehen hat das da bei Linux Einsatz oder verschiedenen Windows versionen Hardware verschiedene konfigurationen laden soll usw. wirst du auch im DSDT sollche Weichen finden.
Wir hingegen erweitern dies noch zu "Darwin" ergo MacOS.

Damit wird einfach eine weitere entscheidung zugefügt wie zbspl. wenn Windows geladen wird starte diesen Device ansonsten nicht oder auch umgekehrt usw.

Schädlich ist es nicht, wenn es keinen ansprechpunkt findet passiert ja auch nichts.
Die SSDT wird in kombination mit dem _OSI to XOSI patch verwendet.

Gruss Coban

Gehört zwar nicht hierher aber da es hier darüber diskutiert wurde schreibe ich es mal hierhin...

Zitat von al6042

Ist das der Grund warum ich meinen Realtek-USB vom Philips Monitor in "System Settings -> Network" deaktivieren musste?

Dieses Kext aus dem OCLP Paket löst unser problem mit dem Monitor USB Lan Controller

mit dem "com.apple.DriverKit.AppleUserECM" kext der Crasht wenn man OCLP Modern Wifi patch installiert hat.

Gruss Coban

Einer/einige deiner SSDT`s sind nicht mit Darwin weiche ausgestattet, korrigiere das oder nimm aktuelle SSDT`s vom OpenCore Pkg.

OSI Patch

Gruss Coban

ManuelW

Deine einstellungen im Config haben nichts mit all dem verhalten zu tun.

Höchstens das hier, die beiden renames braucht OpenCore nicht, das kommt vom Clover welt.

Stelle sicher das du im Bios auch den Sata Controller auf AHCI eingestellt hast.
Lösch all die Partitionen auf diesem Medium, erstelle oder lösche mal diesen Medium mit dem Festplattendienstprogram auf MacOS;

Teste es mal so aus.

Gruss Coban

PS: hattest du mal mit dem "/etc/fstab" rumgespielt? Sind da vielleicht nocht irgendwelche einträge drinne?

Ich würde dir wärmstens empfehlen das du ein normales und für dein System auch passendes Smbios zu fahren.

Ein 10900k braucht man auch nicht faken, dein Igpu läuft auch so nicht auf diesem Board mit MacOS, mit einem 6900xt brauchst du auch kein igpu.

Dein System ist sehr leicht handzuhaben mit einem Smbios iMac20,2, alles andere ist ein unnötiges gebastel bei dem du auch sollche probleme hast.

Mehr leistung bekommst du auch nicht wenn du Ihn als Xeon vorgaukelst, höchstens eben ne optik und jede menge unkompatibilitäten.

Geh einfach in dein Bios stelle sie auf default.

1. Schalte dein Bios auf die reine UEFI Modus

2. Stelle den Secureboot aus

3. stelle den CFG Lock aus

4. schalte den VT-d ein

5. Stelle den Sata auf die AHCI

6. kannst du den rest auf dein geschmack und bedürfnisse einstellen.

Schon kannst du den Efi im Anhang starten, als erstes tipst du im OpenCore Menü auf die Leertaste und machst einen Nvram Reset.

Danach startest du dein MacOS und passt den Config.plist mit gültigen Smbios iMac20,2 Daten für Apple Services unter Platforminfo/Generic an.

Mac adresse nicht vergessen. Später optimierst du deine Graphic, Audio Einstellungen.

Mit diesem Efi solltest du ab Catalina bis Sonoma deinen System betreiben können.

Bei Sonoma müsste man Oclp patch noch anwenden falls du Broadcom Wifi hast.

Ansonsten kannst du die beiden IO80211FamilyLegacy.kext, IOSkywalkFamily.kext plus den com.apple.iokit.IOSkywalkFamily blokierung entfernen.

Ich hab den Sip für die Oclp angepasst, wenn nicht benötigt den auch auf die standard stellen damit es wieder eingeschaltet wird.

Probiers mal aus.

Gruss Coban

Zitat von bluebyte

Ich stehe hier gerade voll auf dem Schlauch.

Kannst auch direkt im Terminal den folgenden Command abgeben wenns nur um den Label geht, muss also nicht unbedingt im recovery sein.

sudo bless --folder /Volumes/MacOSNameOld --label "MacOSNameNew"

bspl. sudo bless --folder /Volumes/SonomaTest --label "Sonoma"

Gruss Coban

Anleitung für Intel 82574L Lan karte die OOB in allen MacOS Versionen vom Sierra zu Sonoma funktioniert.

Ab Monterey wurden hier die Treiber auch entfernt aber das lässt sich ziemlich einfach korrigieren, man nimmt einfach den Monterey Treiber mit ins Efi und somit ist das auch obsoled.

Zunächst besorgt Ihr euch ein NIC mit Intel 82574L Chip und baut es in eurem Rechner ein.

Mögliche such optionen beim kauf; Intel-CT-Desktop NIC (EXPI9301CT) oder (EXPI9301CTBLK)

Die obige Amazon link liefert auch wirklich den richtige Karte.

Es ist hier wichtig das Ihr eins mit einem Device ID 10D3 bekommt damit man den schnell patcht und OOB einsetzt, ansonsten muss man es halt über OpenCore gehen was ich persönlich nicht bevorzuge, je weniger Software patch desto mehr Vanilla ist hier das Motto.

Wir patchen die Karte über den OpenCore OpenShell, also muss bei euch die Efi Shell im OC eingerichtet und startbar sein.

Zunächst bereitet Ihr euch einen leeren Fat32 formatierten USB Stick.

1.

Laden der Intel Preboot-Dateien:

Entpackt die PREBOOT.zip, darin ist nochmal ein PREBOOT.exe, startet den einfach, man kann dort auswählen ob man installieren oder Auspacken will, Ich lege jedenfalls einen funktionierenden Ordner bei.

Schlussendlich habt Ihr hier ein Verzeichnisbaum und darin sind die Dateien.

Vom Verzeichnis PREBOOT\APPS\BootUtil/ kopieren wir den BOOTIMG.FLB in das USB Stick.

Vom Verzeichnis PREBOOT\APPS\BootUtil\EFI2_x64/ kopieren wir den BOOTUTIL64E.EFI in das USB Stick.

Vom Verzeichnis PREBOOT\APPS\BootUtil\EFI2_x64/ kopieren wir den BOOTUTIL64E.MAN in das USB Stick.

2.

Mit diesen 3 Dateien auf dem USB Stick starten wir den Rechner ins OpenCore Efi Shell.

Im Shell mussen wir unseren USB Stick zunächst finden; gehe die Commands folgend durch bis du den richtigen USB Stick inhalt vor dir hast;

gib einfach fs0: ein und enter, danach gibst du ls ein um den inhalt zu listen usw. einfach weiter arbeiten bis die richtige Laufwerk vor dir ist.

fs0: ---> ls

fs1: ---> ls

fs2: ---> ls

fs3: ---> ls

fs4: ---> ls

fs5: ---> ls

usw.

angekommen auf dem richtigen Medium mit den 3 Dateien gehen wir den nächsten schritt.

3.

Hiermit sichern und flashen wir den NIC.

gib einfach hier den command bootutil64e ein um zu sehen was du alles an NIC`s aufgelistet bekommst.

Wenn du mehrere hast oder eben den Onboard Nic nicht deaktiviert hast wirst du alles aufgelistet bekommen.

Wenn du mehrere Nic`s hast ist bei dem folgenden Command WICHTIG das du mit -nic=01 oder -nic=02 den richtigen Nic aufgewählt hast.

Sichern des ursprünglichen ROMs, achte auf die NIC nummer !

bootutil64e -nic=01 -saveimage -file=Backupi82574L.flb

Aktivieren der Flash-Enable funktion für NIC;

bootutil64e -fe -nic=01

Update NIC mit EFI-ROM;

bootutil64e -up=EFI -nic=01 -file=BootIMG.FLB

Die Intel NIC ist jetzt UEFI-kompatibel geflasht und sollte bereits in deinem UEFI erscheinen können.

Rechner ausschalten und 30s ohne Strom sollte die Nic auch resetten.

4.

Jetzt ändern wir die Geräte-ID von der NIC;

Boote einfach von einer Linux Live Boot-Umgebung (zbspl. Ubuntu, Knoppix usw.)

ändere die PCI-Geräte-ID von 10D3 auf 10F6 mit ethtool.

Bitte stelle sicher die NIC bezeichnung unter deinem Linux auch übereinstimmt;

bei Knoppix ist da zbspl. passend eth0, bei Ubuntu ist heist das anders.,

Wir möchten ja keine anderen NICs aus Versehen patchen.

Im Netz kursieren immer falsche befehle, also vorsicht hier, bei ethtool sollte die length 1 dabei sein!

Starte einfach im Linux den Terminal und gib folgendes ein;

Schon ist alles durch; Man könnte auch den MAC adresse der Karte zu Apple MAC Adresse ändern aber das ist wirklich überflüssig und nicht notwendig, Apple prüft sowas nicht, ansonsten dürften all die Hackintoshe auch nicht funktionieren.

Starte den MacOS und gehe in das Verzeichnis /Library/Preferences/SystemConfiguration/

die folgende 2 Dateien löschen;

Networkinterfaces.plist

preferences.plist

Damit korrigierst du du den en0, en1, en2... falls das bei dir nicht mehr passen sollte.

Die Karte wird bis Monterey OOB laufen, bei Ventura und Sonoma muss man die Intel82574L.kext vom Monterey ins Config.plist vom OpenCore einbinden.

Schon hast du ein sorgenfreies Lan karte die auch wirklich zuverlässig überall in jedem macOS & Windows & Linux funktioniert.

Mehr braucht kein normal sterblicher.

Gruss Coban

Wenn der "ältere Herr" kein Ehemaliger Schreiner mit nur 2 Fingern in beiden Händen ist sollte das locker zu bewerkstellen sein..

Gruss Coban

Zitat von al6042

Ist das der Grund warum ich meinen Realtek-USB vom Philips Monitor in "System Settings -> Network" deaktivieren musste?

bei mir ist es wirklich genau das, mit Modern Wifi patch funktioniert die "com.apple.DriverKit.AppleUserECM" kext auch nicht mehr.

Gruss Coban

Ich weiss zwar nicht was für version i225V Chip in z690 von al6042 verbaut ist aber generell sind im z490 i225V v2, in z590 i225V v3 verbaut.
Geladen wird der AppleIntelI210Ethernet.kext erst mit den nötigen Bootargs;

dk.e1000=0 --> für BigSur, e1000=0 --> für Monterey, Ventura und Sonoma um die "com.apple.DriverKit-AppleEthernetE1000" zu unterdrücken.

Meine persönliche meinung zu diesem Chip ist leider nicht so positiv seit Ventura, davor war sie bei mir stabil und zuverlässig.
Seit Ventura kämpfe ich damit immer wieder mal und schlussendlich war es mir leid die Zeit zu investieren.
Hab mir ein Intel 82574L für 20€ zugelegt und die ID gepatcht (bei bedarf kann ich ne anleitung durchgeben), seit dem ist das ding bei mir OOB in allen MacOS varianten und zuverlässig im einsatz.

Gruss Coban

Zitat von CrazyHeinke

USB Verbindung zu meinem QNAP

lädt deine USB für diese verbindung zufällig auch den "com.apple.DriverKit.AppleUserECM" Driver?

Wenn ja ist das genau dasselbe problem wie oben schon geschildert.
Dieses Treiber benutz auch das gepatchte Networkstack und crasht ab.
Ist leider bei meinem Dell Monitor USB Lan unter Sonoma dasselbes problem.

Gruss Coban

Zitat von CrazyHeinke

Hierbei ist mir aufgefallen, dass der oben genannte WiFi Patch in Kombination mit dem "AppleIntel210Ethernet.kext" nicht funktioniert.

Diesen Kext gab es zuletzt unter Monterey, danach wurde umgebaut und entfernt,

die Intel i225V v3 vom Z590 wird seit dem nur noch von Dext Driver "com.apple.DriverKit-AppleEthernetE1000" bedient.

Das funktioniert auch wunderbar unter Ventura und Sonoma.

Wenn du unter Ventura oder Sonoma den "AppleIntel210Ethernet.kext" vom Monterey einsetzen willst musst du auch den bootarg mitbenutzen damit die Dext Driver "com.apple.DriverKit-AppleEthernetE1000" von dem es normal startet unterdrückt wird.

dk.e1000=0 --> Bootarg für BigSur

e1000=0 --> Bootarg für Monterey, Ventura und Sonoma

Das problem hier unter Sonoma ist das die Intel i225V v3 mit dem standardmässigen Dext Driver "com.apple.DriverKit-AppleEthernetE1000"  IOSkywalkFamily.kext mitbenützt.

Ohne OCLP Modern Wifi patch startet das ganze auch normal und tut seine sache.

Mit OCLP Modern Wifi patch wird die IOSkywalkFamily.kext ersetzt und gepatscht, daher passt irgendwas nicht mehr.

Bei mir wirkt sich das so aus das Wifi funktioniert aber LAN Chip keine DHCP adressen beziehen kann usw.

Ergo müssten die OCLP Dev`s das weiter stricken damit das ganze Netzwerkstack die den Skywalk Kext mitbenutzt auch mitpatchen.

Da sie vermutlich nur den Wifi Teil anpassen ist es für Desktop Benutzer halbgar. bei Laptops ohne Lan Port mag das gut klappen.

Ich vermute hier sogar das all die Lan Chips die den Skywalk Kext mitbenötigen probleme haben.

Anders sieht es mit dem alten Intel Treibern wie vom Monterey "AppleIntel210Ethernet.kext" aus.

Hier wird die IOSkywalkFamily.kext nicht mitbenötigt und daher wirkt sich das eben nicht auf die Intel i225V v3 aus.

Wie schon oben erwähnt muss man daher die Dext Driver mit Bootarg unterdrücken damit die AppleIntel210Ethernet.kext" geladen wird.

Zitat von CrazyHeinke

Also habe ich den Kext entfernt und durch den "AppleIGC.kext" ersetzt. Jetzt funktioniert sowohl WiFi als auch Ethernet.

Die AppleIGC.kext ist ein umgebauter Linux Driver der bei mir vom Catalina bis Sonoma durchgehend den Intel Chip startet.
Starten heisst eben noch lange nicht das es sauber funktioniert, die Kext bringt leider mehr probleme als nutzen.
Sie verursacht konfikte mit AHCI, bricht bei mir den Sleep und kann keine Recovery`s mehr starten.
Ansonsten wäre das die beste lösung gewesen.

Gruss Coban

Zitat von a1k0n

Vom Anschalten bis zur Passwortabfrage (FileVault2) 13,8sec

Zitat von Maulwurf

Die Bootzeit von a1k0n ist sehr kurz und er meinte das er das 512GB Modell hat

Das hat gar nichts mit Model oder Speicher zutun, mit FileVault ist die Passwortabfrage so schnell da, da ist aber die MacOS noch lange nicht geladen.

Gruss Coban

Du brauchst diese Dateien auch nicht wenn man es korrekt einrichtet.
Die .contentFlavour definiert mit seinem Inhalt die Bezeichnung der Volume.

Die .contentVisibility definiert mit seinem Inhalt die Sichtbarkeit.

Beide gehören immer dort hin wo der Bootloader selber steht, hier in diesem beispiel wo der "OpenCore.efi" steht.

Sauber und korrekt würde es immer funktionieren wenn du dein "ScanPolicy" einrichtest.

bspl;

Scanpolicy = 32513

danach 1x NvramReset.

Gruss Coban