Clover r5125 ff. und die Quirks

  • ein Bild in scharf währe mir lieber

    Hmmm - mag ich an sich auch lieber. ;)


    Dann sag mir mal, wie Du das mit einem Handy bewerkstelligen würdest, wenn die Textzeilen so vorbeibrettern, dass der Autofokus nicht mehr hinterherkommt.

  • Vielleicht einmal durch eine Videobearbeitung jagen und die Geschwindigkeit verringern. Ich bin da unbedarft und kenn mich nicht wirklich aus....


    Handy vielleicht auf ein kleines Stativ?

  • Mit einer Slow-Motion Video Aufnahme vielleicht. Irgendwie habe ich es immer hinbekommen das man was lesen kann. Aktuell kann ich auch nichts lesen.

  • Slow-Motion Video Aufnahme

    Gibt es eine solche Funktion bei Smartphones (hier Lumia 650)?

    Bietet Clover nicht eine Möglichkeit, das im V-Modus gezeigte als Text-Protokoll zu speichern?

  • Kenne keine Möglichkeit die Verbose Ausgabe in eine Log zu speichern.


    Was jedoch funktioniert hat bei funktionierendem NVRam ist das die Kernelpanik in einem anderem funktionierendem System angezeigt wird.

    Als Beispiel BigSur Kernelpanik > dann anschließender Start Catalina > Catalina startet mit der Anzeige vom Fehlerprotokoll von BigSur.

  • BigSur Kernelpanik > dann anschließender Start Catalina > Catalina startet mit der Anzeige vom Fehlerprotokoll von BigSur

    Na - das wäre doch was, nur halt umgekehrt. Wo liegt das Fehlerprotokoll bzw. wann genau wird es angezeigt? Ich habe das noch nie mitbekommen.

  • Das hier meine ich



    Wenn NVRAM zuverlässig funktioniert sollte das nach einer Kernelpanik beim dem direkten Neustart kommen.

    (Ergänzung: Verbose Mode muss dazu glaube ich an sein. Ist er ja bei dir.)

  • Das hier meine ich

    Damit kann ich nicht dienen - das hier gab es nach dem Login bei BS und bezieht sich auf Banales.


    Bestätigt das auch, dass NVRAM einwandfrei funktioniert?


    Ich werde von anderen OS aus auch nochmal testen.

  • Genau das meine ich und bestätigt das NVRAM geht. Und was steht da wenn du auf öffnen gehst?

  • Gut zu wissen, dass das NVRAM funktioniert.

    Meine Meldung bezieht sich lediglich auf das Wiederöffnen der zuvor beim Herunterfahren geöffneten Fenster, wie es der Text auch ausweist.


    Aber ich habe vorhin auf meinem OC-Stick drei Panic-Protokolle beim Catalina-Boot aus dem Januar gefunden. Ich hatte ja bzgl. Catalina das "Verbose-muss-aktiviert-sein"-Problem sowohl beim OC- als auch beim Clover-BL, bei Clover 5128 kam die generelle Bootverweigerung hinzu.

    Wenn da keine sensiblen Daten enthalten sind, kann ich sie mal hochladen - eventuell geben sie was Brauchbares her.

  • Neuer Tag - neuer Anlauf - neues Glück?


    Es hat sich in den Jahrzehnten meiner Bastlertätigkeit bei der Fehlersuche immer wieder bewährt, Vergleichsoperationen vorzunehmen.


    Also habe ich heute Morgen eine noch leere HDD in meinem All-OS-Rechner hergenommen und via Clover 5127 dort Catalina 10.15.7 (19H2) installiert. Ging einwandfrei durch.

    Dann das Supplement-Update nachgeschoben: auch bestens. Mehrmals gebootet - kein Zucken.

    Also legte Clover zumindest hier keine Steine in den Weg, auch wenn der Zugang bei der benachbarten SSD mit 10.15.7 nach wie vor nicht möglich war.

    Mutig-euphorisch den Verbode-Mode deaktiviert - änderte nichts und lief auch durch. Bisher zig-mal gebootet: Mojave-HHD, Big Sur-SSD & Catalina HHD booten ohne Verbose-Mode durch, wie man es erwarten darf. Auch das vollständige Abschalten des Rechners änderte nichts daran.

    Das freut Einen dann doch. :)


    Bei dem Ganzen habe ich auch ein paar für mich neue Ecken an Clover kennengelernt, die ich bislang nie genutzt habe: es gibt die Abteilung boot.log und die Abteilung NVRAM.

    Vor ca. 2 Jahren hatte ich irgendwo bzgl. meines GA-Z87M-D3H-Rechners thematisiert, dass der Verbose-Node nicht abzuschalten war, obwohl der Eintrag -V bei den bootargs entfernt wurde. Ein temporäres Entfernen via Leertaste half auch nicht.

    Heute habe ich die Ursache gefunden: bei NVRAM/Kernel-Boot-Argumente war -v ebenso eingetragen. Wie es dahingekommen ist, weiß ich nicht. Aber jetzt ist der Punkt auch abgearbeitet - der Rechner startet mit Apfel & Balken.

    Manchmal dauert es halt. ;)


    Nachdem es also mit diesem Clover sehr wohl möglich ist, Catalina überhaupt und auch ohne V-Mode auf diesem Rechner zu booten, werde ich eine Neu-Installation auf der SSD machen (wäre dann schon die dritte).

    Wäre doch gelacht: irgendwie muss die Fehlerquelle doch einzugrenzen sein. ;)


    OC werde ich bis auf Weiteres nicht mehr in der Urform an das Asus Z87 Deluxe ranlassen. Beim MB-Bios zeigen sich leichte Seltsamkeiten: wenn ich z. Bsp. die Bootquellen mit der Maus verändere/verschiebe und das dann abspeichere und der Rechner dann neu booten sollte, friert er ein. Dann braucht es einen HW-Reset.

    Bin noch nicht exakt dahinter gekommen, woran es liegt, habe aber so ein paar Ideen. :rolleyes:

    Einmal editiert, zuletzt von LuckyOldMan ()

  • werde ich eine Neu-Installation auf der SSD machen

    Da habe ich doch noch einen kleinen Zwischenschritt eingelegt und mit 10.15.7 (19H4) über die bestehende 19H524 installiert (erspart mir das Neu-Einrichten: ein ganz entscheidender Vorteil gegenüber Windows): lief ohne Mucken durch.

    Gleich wie bei der HDD das Supplement-Update nachgeschoben und jetzt ist der Status wie zuvor 10.15.7 (19H524), allerdings mit dem Unterschied gegenüber zuvor, dass jetzt ein Booten möglich ist und das ohne aktiviertem V-Mode.

    Auftrag erfüllt! :)

    Mal sehen, wie lange das anhält. ;)

  • Interessant, wie seltsam manchmal das Verhalten der Bootloader ist. Ich folge weiterhin gespannt den Berichten.

  • Ich folge weiterhin gespannt den Berichten.

    ... und spannend bleibt es - dafür sorgen schon die Gegebenheiten! :rolleyes:


    Gestern Morgen hätte ich sagen können "Neuer Tag - altes Pech!", denn das Asus zeigte sich beim Start von Catalina-SSD unwillig: Catalina endet wie viele Male nach positivem ersten Ansatz am nächsten Tag im KP.

    Also prüfte ich in eine andere Richtung: Hardware-Problem entweder seitens Asus Z87 oder seitens SSD. Zuerst einen anderen SATA-Port genommen: keine Besserung.

    Dann die SSD in den GA-Z87M-Rechner eingehangen (in dem ja schon Catalina mit Clover 5112 auf einer HDD seinen Dienst tut): startet wie schon früher getestet ohne Probleme (auch heute Morgen noch ;) ).


    Jetzt sind ja meine Installationen von Catalina & BigSur auf der Test-HDD immer erst als Basis-OS vom Stick her kommend dann via Migrationsassistenten (ausgesprochen hilfreiche Funktion) in den Ursprungsstatus wie auf der SSD versetzt worden (deren alte Container-Konstellation auf der SSD ich zuvor auch aufgelöst habe, um andere Test-Bedingungen zu schaffen).

    Nebenbei: bei solchen Problemlösungsoperationen, die ich Keinem wünsche, lernt man auch, mal rechts & links zu schauen, was das OS denn sonst noch so bietet. Lehrreich allemal!

    Um auszuschließen, dass hinter dem Vorhang irgendwas mitgenommen wird, was den Bootverlauf stören könnte (eher unwahrscheinlich, aber sicher ist sicher), habe ich erneut zwei aktuelle Installationen bis auf FF & TB ohne jegliche Zusätze auf der Test-HDD gemacht und die sind heute Morgen auch wieder gestartet, als wäre nichts.

    Eines habe ich mir jedenfalls vorgenommen: solange bei mir Haswell-MBs im Einsatz sind, bleiben OC als Bootloader als auch irgendwelche Betas außen vor.

    Die paar Wochen Wartezeit bis zum macOS-Final-Release (oder was auch immer) bringen mich nicht um, aber ich habe festgestellt, dass mit überlappenden Updates von Beta & Bootloader vielfach bei Widrigkeiten zu häufig vorschnell ein NVRAM-Reset als Problemlöser verwendet (bzw. empfohlen wird und das mögen manche MBs eben nicht auf Dauer. Andere Anwender haben ähnliche Erfahrungen machen müssen.


    Wie ich schon weiter oben schrieb, hat mein Asus Z87 die "Angewohnheit" bekommen, nach BIOS-Einstellungsänderungen beim Abspeichern/Neustarten einzufrieren. Ich habe das zwar mit einem neuen BIOS-Flash wieder beheben können, was allerdings (auch wegen weiterem OC-Einsatz?) nur von kurzer Dauer war. Eventuell versuche ich mal einen vollständigen Flash des herausgenommenen Chips via Programmer - der über EZ-Flash ist ja nur ein eingeschränkter.


    Ja - ich weiß, dass Clover 5123 ff. OC-Bestandteile mit sich führt, um den Boot von BS zu ermöglichen. Aber es drängt sich mir mehr & mehr das Gefühl auf, dass OC noch einen Zacken tiefer wirkt.

    Was da genau mit was bei bestimmten Konstellationen miteinander kollidiert, dürften die emsigen OC-Devs besser erkennen können. Ich als Anwender jedenfalls muss mit möglichen Folgen leben und diese Auswirkungen gefallen mir nicht.

  • Bootstrap?

    Nicht dass ich wüsste. In der config.plist von Clover 5127 ff. habe ich den Punkt trotz mehrfachem Sichten noch gar nicht gefunden.


    Das Thema Bootstrap hatten wir ja schon vor ein paar Monaten debattiert, als ich noch unter voller OC-Flagge segelte. Da gab es ja reichlich Meldungen & Kommentare in https://github.com/acidanthera/bugtracker/issues/1222.

    Zudem wurde ja das danach in der OC-config-plist standardmäßig auf None gestellt. Ich habe das im Nachgang zur Sicherheit immer kontrolliert.

  • LuckyOldMan Ab welcher Version von OC ist Bootstrap standardisiert abgeschaltet?

    Hacken ⛏️⛏️
    Haken ✔️

    .

    anscheinend: es sieht so aus als ob, und wird wohl stimmen

    scheinbar: es sieht so aus als ob, stimmt aber nicht

  • Wolfe

    Das weiß ich bei besten Willen nicht mehr genau, würde aber vom Zeitraster her (monatlicher Wechsel) auf 063 tippen.

    Ich hatte damals in einer Diskussion mit mhaeuser im OC-Thread den Vorschlag gemacht, die Default-Einstellung auf None zu setzen - zuvor war Bootstrap ja aktiviert - und das wurde auch recht zeitnah umgesetzt, weil da auch die obigen Diskussionen aufkamen.

  • LuckyOldMan Acidantheras changelog ist in Bezug auf bootstrap nicht wirklich explizit, aber ich habe dafür bei Dortania das hier gefunden:

    • „Note: With OpenCore 0.6.6, Bootstrap.efi has been replaced with LauncherOption. See here for more info on updating: Updating Bootstrap in 0.6.6

    With OpenCore 0.6.6 and newer, we are now able to launch OpenCore directly from our firmwares without needing a launcher (Bootstrap.efi or BOOTx64.efi) as an intermediary. This allows us to add OpenCore to our motherboard's boot menu and prevent issues where either Windows or Linux try to overwrite the EFI/BOOT/BOOTx64.efi path, which can happen when installing or updating Windows and therefore breaking OpenCore's ability to boot.“


    Das finde ich sehr spannend

    Hacken ⛏️⛏️
    Haken ✔️

    .

    anscheinend: es sieht so aus als ob, und wird wohl stimmen

    scheinbar: es sieht so aus als ob, stimmt aber nicht

  • Wolfe


    Das von Dir Gefundene ist eine andere Geschichte, die eher der Strukturänderung Rechnung trägt. Ist ja auch so beschrieben: "OpenCore is now a UEFI application instead of a driver.", weshalb Bootstrap wegfiel.


    Meine erwähnte Veränderung war einfach eine Änderung in der Sample-plist, was jetzt voreingestellt ist. In der Nightly und in der Release danach war Bootstrap immer noch enthalten, aber eben nicht mehr voreingestellt aktiv.

    Das war defintiv früher - entweder 063 oder 064.