Ich werde noch senil, ja, genau so gehts!! Danke!
OpenCore Sammelthread (Hilfe und Diskussion)
- derHackfan
- Unerledigt
-
-
LuckyOldMan wolltest du auf disk1s1 den MBR schreiben? Weil da disk10 steht, du jedoch disk1 gewählt hast
-
Habe ich jetzt nicht so sehr drauf geachtet - mir ging es mehr darum, Wolle62 zu zeigen, dass nicht zusammengesucht werden muss, sondern Alles im Paket zu finden ist und recht geschmeidig abläuft (wenn man weiß, wie es geht).
Ich habe mich nämlich letztes Jahr bei meinen Legacy-Versuchen anfänglich auch etwas abgemüht, bis ich den jetztigen Weg gefunden habe. Die Anleitung war schon damals kaum zu gebrauchen - deshalb musste der Selbstversuch her.
-
Jo das verstehe ich. Aber du hast jetzt den MBR von disk1s1 neu geschrieben. Dein angezeigtes Device war aber disk10.
-
en MBR von disk1s1 neu geschrieben
Offenbar blieb das ohne Auswirkung - zufällig war es die MS-Daten-HDD, die immer noch im GPT-Glanz erstrahlt und auch noch funktioniert. So schnell bekommt man eine MS-Platte nicht klein.
-
Bislang bootet der Stick noch nicht. Erst "Boot Mismatch" und danach
X64 Exception 0000000000! Error.
War klar, dass das nicht so einfach wird.
Ich las im Netz, dass der Legacy Boot nur für HDDs und SSDs ist und mit USB nicht läuft?
Stimmt das?
-
der Legacy Boot nur für HDDs und SSDs ist und mit USB nicht läuft
Wäre mir neu, zumal der Legacy-Stick von heute Nachmittag mit einer abgestimmten EFI meinen Rechner einwandfrei bootet.
Damit hast Du den Beweis, dass Deine Annahme nicht zutrifft.
Wie hast Du Deinen Stick vorbereitet?
-
Ich habe nun den Stick nochmal neu aufgesetzt FAT / Masterbootrecord.
Dann die Boot Install Routine drauf losgelassen und einen EFI Ordner erstellt.
Nun bootet das Ding schon mal.
Zeigt das Auswahlmenü, der zusätzlich angesteckte BS Install Stick ist leider nicht dabei.
Endet noch in einer KP, aber es geht voran.
Ich muss ein Bild von der KP machen, wenn ich nicht selbst drauf komme.
Irgendwas kann nicht gemountet werden... Ist so schnell nicht lesbar.
EDIT:
Ok der "Hfsplus.efi" Treiber verursacht die Panic. Ich habe nun den "OpenHfsPlus.efi"
genommen und bin schonmal mit voller Grafik im BS Installer!
Morgen versuche ich dann die Installation durchzuziehen und den OC auf die SSD zu bekommen.
-
die Installation durchzuziehen und den OC auf die SSD zu bekommen.
Den Install-Stick bitte nach Ende der Arbeiten ins Archiv legen - das ist Dein Backup-Notfall-Zugang.
Änderungen/Aktualisierungen nicht am Stick machen. Auf keinen Fall löschen, weil Du gerade mal einen Stick woanders brauchst, denn nach Murphys Gesetz geht meist in dem Moment was am Hackintosh schief.
-
Bei meiner Samsung 970 EVO benötigt der Trim-Prozess ziemlich lang, wenn der APFS-Treiber nicht mit dem Timeout aussteigt:
log show --debug --last boot --predicate "processID == 0" | grep spaceman
2021-02-07 10:27:25.127770+0100 0x1fc Default 0x0 0 0 kernel: (apfs) spaceman_trim_free_blocks:3327: scan took 67.082337 s, trims took 61.671375 s
-
wenn ich den Befehl so 1:1 im Terminal eingebe, dauert der ganze Prozess "spaceman" ca. 35 sec. Dabei wird ausgiebig die disk2 behandelt, ein APFS-Container der NVME 970 EVO (500 MB), eine stille Reserve mit Mojave, welche schon ewig nicht gebootet habe.
Was gar nicht auftaucht ist meine axdata SX8200PNP Media nvme (1TB), auf der Big Sur läuft.
-
Ich stecke mittlerweile hier fest:
https://github.com/acidanthera/bugtracker/issues/1278
Das identische Problem. Womöglich auch ein NVRAM Problem beim DH67VR von Intel?
Ich versuche Catalina zu installieren...
EDIT: Ja Catalina lies sich problemlos installieren. Aber auch hier: Startvolumen manuell wählen
-
Nach der Verschwendung des Mainboard-Logos dauert lange bei der Version 0.6.6 bis GUI gezeigt wird.
Probier mal ConnectDrivers auf false, damit geht bei mir das Laden von OC so schnell wie mit 0.6.5
-
-
-
Liegt daran, dass Teiber nicht geladen werden, welche nicht automatisch starten. AudioDxe.efi ist so einer.
ConnectDrivers auf No bringt bei mir keinen Vorsprung. Ist wohl nicht zwangsläufig so.
-
So der kleine läuft wieder.
Ich musste die Installation aber auf dem ASUS Board machen. Das Intel DH67VR hat das selbe NVRAM Problem wie das Z97 von ASUS vor dem Eingriff ins BIOS.
Eine Errormeldung liefert mir OC gleich zu Anfang:
"OCS: Failed to calculate size of false field containig <empty> as type integer,
context <PlayChime>!
Läuft aber trotzdem weiter und ohne Probleme...
Irgend ein Eintrag ist leer, der für das Abspielen des Startsounds da ist, den ich nicht nutze???
Verstehe ich das richtig?
-
Playchime musst Du das Format auf String ändern.
-
Genau das wars! Danke!!!
Habe ich wohl was bei den Änderungen von OC überlesen...
So nun muss ich mich um das NVRAM Problem bei dem Board kümmern,
sonst geht das nächst Update schief.
Jetzt hab ichs mit dem emuliertem NVRAM raus:
Das LogoutHook schreibt den jeweils geänderten Wert beim Shutdown in die nvram.plist.
OC vergleicht beim Start aber nur die Einträge, die in der config.plist bei "LegacySchema" stehen!
Ich habe mal aus "nvda_drv" > "TestVar" gemacht, da ich keine NVidia Karte habe.
Wenn ich nun im Terminal "sudo nvram TestVar="Test1" eingebe,
habe ich nach einem System-Neustart mit "nvram -p" den Wert "Test1" in der Ausgabe bei TestVar.
Das soll man wissen...
Heißt aber wohl auch, dass wenn BS bei der Installation "irgendwas" ins NVRAM schreibt,
dann wird das beim Start nicht übergeben, weil es nicht in der "config.plist" definiert war..
-
Liegt daran, dass Teiber nicht geladen werden, welche nicht automatisch starten. AudioDxe.efi ist so einer.
ConnectDrivers auf No bringt bei mir keinen Vorsprung. Ist wohl nicht zwangsläufig so.
Hab zum Test bei meinem T530 mal ConnectDrivers, den Chime und AudioDxe deaktiviert. Die Zeit, vom Lenovo Logo bis zum Apple Bootscreen beträgt jetzt nur noch ne Sekunde ungefähr - vorher waren es gefühlt 10. Von daher Bye Bye Boot Chime.
