Beiträge von griven

Nun ggf. ist das mit dem RAM wirklich ein Thema denn wie al6042 ja auch schreibt die "Probleme" gibt es ja tatsächlich gelesen habe ich davon auch schon und diskutiert worden ist es hier an anderer Stelle ja auch bereits...

Der Einfachheit halber würde ich das mit dem RAM auf alle Fälle testen die Riegel sind ja gut zugänglich und zwei davon sind leicht gezogen wäre ja schon krass verrückt wenn das wirklich des Rätsels Lösung wäre und gleichzeitig auch irgendwie komisch denn es kann ja eigentlich auch nicht angehen das man bei so einer Plattform den Speicher nicht maximal ausbauen kann/darf, oder?

Kann es denn ein RAM Problem sein wenn der Rechner im SafeMode zuverlässig startet bzw. auch in die Installer und "nur" im normalen Boot nicht? Müssten die Probleme im Falle vom RAM nicht generell bestehen?

Aber ja einen Versuch ist es natürlich wert...

Man sollte vielleicht dazu sagen das Installationen auf dem System ohne Murren durchlaufen und ein Start in den Save Mode (-x) möglich ist (inkl. Einrichtung eines Benutzer etc.) nur einen "normalen" Systemstart verweigert der Rechner hartnäckig...

Ich bin ehrlich gesagt bei dem System ziemlich ratlos einfach weil man kaum bis gar nicht diagnostizieren kann woran es letztlich hakt. Der Rechner startet bleibt dann aber im Prozess stehen wobei die letzten Meldungen (USB, Netzwerk) hier mit Vorsicht zu genießen sind denn dem voran gehen immer ein Haufen Meldungen die sich auf APFS/Trim beziehen (APFTrimTimeout ist auf 0 gestellt) bzw. die irgendwas mit AHCI zu tun haben. Irgendwas muss also im SaveMode unterdrückt werden was im "normalen" Betrieb eben nicht unterdrückt ist und zu Problemen führen...

Der Rechner hat, wenn ich das richtig gesehen habe, eine NVME von WD verbaut wir haben in die Richtung nicht weiter geforscht aber zumindest denkbar wäre ja auch das die NVME im Zusammenspiel mit macOS Probleme hat/macht vielleicht auch "nur" in Kombination mit dem speziellen Board/Bios Version? Ich wäre echt dankbar wenn hier vielleicht noch jemand einen evtl. zündenden Gedanken hat denn es ist schon reichlich frustrierend quasi den ganzen Tag an so einer Box zu werkeln ohne auch nur einen entscheidenden Millimeter weiter zu kommen....

MacGrummel nur aus Neugierde und um es als Fehlerquelle ausschließen zu können kannst Du die WD NVME mal ausbauen und gegen eine andere ersetzen?

Ich wäre allen Beteiligten wirklich dankbar wenn Ihr jetzt aber auch künftig darauf verzichten würdet solche Dinge öffentlich und auf einer persönlichen Ebene zu diskutieren denn das bringt nichts ausser bösem Blut und unnötiger Konflikte...

Für mich ist es immer wieder aufs Neue bemerkenswert wie es angehen kann das eine eigentlich komplett belanglose Meldung wie eben die zu BUHUNTFS zu solchen Diskussionen führt naja wie auch immer bevor hier die Sache noch komplett abgleitet mache ich den Thread zu

Versuch mal im Bereich Booter-> Quirks wie folgt zu setzen:

In Kernel -> Quirks:

Und in den Bios Einstellungen:

Dass war bei mir gestern ein eher wilder Ritt sowohl am M1 als auch am iPhone (die IOS Beta kam zeitgleich)...

Entweder hatte Apple da gestern massive Probleme mit der Erreichbarkeit der Server oder mit den Updates lag sonst was im argen denn beide Geräte haben diverse Anläufe gebraucht bis sich die Updates schlussendlich installieren ließen. In Beiden Fällen ist die Installation mehrfach mit einem Fehler abgebrochen wobei es am MacBook hieß das Update könne nicht personalisiert werden und am iPhone hat sich die "Update überprüfen" Phase mehrfach totgelaufen....

Genau so sieht das aus bzw. gibt es diese Möglichkeit halt unter macOS nicht (ob das mit Windows geht weiß ich ehrlich gesagt nicht habe ich nicht getestet obwohl meine Kiste ein Windows11 parallel installiert hat)...

Die Drehzahlen die ausgespuckt werden sind meiner Meinung nach aber schon plausibel 255 hört sich eher nach einem Zufallswert an wobei die Werte da auch nicht als String rein gehören sondern als Data...

So sieht der Eintrag bei mir aus (PlistEdit Pro, ProperTree):

oder so halt in OCAT:

Wenn keine größeren Katastrophen passieren werde ich wohl auch anwesend sein

Lüfter steuern über VirtualSMC geht zumindest in der Theorie in der Praxis ist es jedoch so eine Sache da es dabei doch einige Einschränkungen gibt was insbesondere der Art und Weise geschuldet ist wie macOS die Quirle verwaltet. Generell kann man mit VirtualSMC und dessen Plugin SMCSuperIO.kext die Drehzahl der Lüfter auslesen und in manchen Fällen (ITE EC, Intel NUC) auch steuern. Beim Elitebook funktioniert aus dem Stand beides nicht denn der verwendete EC wird von SMCSuperIO ohne Hilfe nicht erkannt und somit werden auch keinen Werte ausgelesen ich bin auch nur durch Zufall darüber gestolpert und auf der gleichen Dokumentation gelandet wie Du PeterListig und ich gebe Dir recht so richtig verständlich ist das nicht insbesondere nicht weil es diverse Fragen einfach auch unbeantwortet lässt unter anderem nämlich die wie man die Adresse des Lüfters rausfindet aber anyway wenn man in der Doku ein wenig weiter liest ist die Rede davon das neben den bereits implementierten Treibern für die NUC's auch generische Profile möglich sind die man dann halt mittels DeviceProperties in die config.plist einfügen kann und genau hier liegt der Schlüssel zum zumindest teilweisen Erfolg denn unter der Liste der "Supported Devices" befindet sich auch ein Eintrag für das Probook 430 und der passt zufälligerweise auch genau auf das Elitebook 840...

Mit dem Eintrag kann man nun zumindest die Drehzahl des Quirls auslesen allerdings eben leider auch nur das eine eigene Lüfterkuve definieren oder die Drehzahl manuell ändern geht damit nicht was aber wohl an dem verwendeten Embedded Controller in dem Gerät liegt der es eben einfach nicht zulässt das man die entsprechenden Register manipuliert.

Schon richtig und gut so dennoch kann es ja sein das Apple hier mit Sequoia die Zügel angezogen hat und nun FileVault verweigert wenn der T-Chip fehlt? Hau Dir testweise mal den RestrictEvents.kext mit rein und das BootArg revpatch=sbvmm wenn die Maßnahme dazu führt das FileVault anschließend läuft liegt es am SMBIOS wenn nicht liegt der Fehler an anderer Stelle...

Nur so eine Idee aber mag das vielleicht (auch) am verwendeten SMBIOS liegen?

ich meine es könnte ja durchaus sein das ein SMBIOS von einer Maschine die einen T-Chip hat hier problematisch ist weil der T-Chip bei den echten Mac's die SecureEnclave enthält die unter anderem ja auch bei der FileVault Verschlüsselung einen Rolle spielt? Am Elitebook habe ich RestrictEvents im Einsatz mit dem revpatch=sbvmm ARG was ja am langen Ende dafür sorgt das macOS denkt es würde in einer virtuellen Maschine laufen interessant wäre es nun also zu wissen ob ihr den auch am Start habt (zumindest die beiden bei denen es funktioniert) bzw. ob hier ein SMBIOS mit T-Chip im Einsatz ist oder nicht zudem natürlich auch ob Du ozw00d ein T-Chip SMBIOS nutzt und ob Du RestrictEvents verwendest oder nicht...

irgendwas mit dem Audio Controller würde ich meinen

Warum sich das da meldet weiß ich allerdings nicht...

Wichtig zu erwähnen wäre noch das ich natürlich die Kernel Patches am Start haben eben wegen des OCLP Einsatzes denn andernfalls würde das natürlich aufgrund des gebrochenen Sigels auf dem Snapshot nicht funktionieren...

Im Wesentlichen aktiv sind:

1. Force FileVault on Broken Seal (_apfs_filevault_allowed)
2. Disable Root Hash Validation (_authenticate_root_hash)

Hab das jetzt schon ne Weile am Elitebook nicht mehr aktiv eben weil ich da auf den OCLP angewiesen bin (FENVI) und der Patcher den Dienst verweigert wenn die Platte verschlüsselt ist aber wenn ich es denn aktivieren wollen würde dann könnte ich das (eben getestet)...

Laufen habe ich auf der Kiste die letzte Beta von 15.1 mit dem OCLP WIFI Patch und sonst allem Bums den es dazu braucht.

EDIT: Eben getestet ist gut die Kiste ist nun unbeirrt dabei die Platte zu verschlüsseln ein riesen Spaß aber nun gut dann werden die nächsten Betas halt geskipped und erst bei Release wieder entschlüsselt und geupdated *humpf*

Sofern das Bios bei der Kiste die Möglichkeit des Flashbacks (Ist ja ein ASUS Board hat also CraschFree an Bord) ermöglicht ist das Risiko doch überschaubar will meinen wenn es nicht geht das alte wieder drauf und fertig? Wenn man das vorhandene Bios zudem vor dem Flashen noch sichern kann wäre das natürlich premium weil dann ist ein Sprung zurück auf den Status Quo ja leicht erledigt. Ich würde es versuchen an Deiner Stelle auch und gerade weil es ja auch einige Microcode Updates in der Zwischenzeit gegeben hat die relevant sein könnten...

Die crashes passieren offensichtlich aber bei unterschiedlichen Dingen hier jetzt beim mediaanalysisd vorher war es ein anderer Thread kommt also bunt durch den Garten vor was es nicht einfacher macht dem ganzen auf die Spur zu kommen...

Ich glaube aber immer weniger das es sich hierbei um ein TSCSync bezogenes Problem und denke der Fehler liegt an anderer Stelle...

Nö die App allein reicht natürlich nicht

Du musst schon für jeden Installer den Du auf dem Medium haben möchtest eine Partition erzeugen (wie MacGrummel ja schon schrieb vorzugsweise HFS+) und diese dann Jeweils als Ziel für das CreateInstallMedia Script bzw. eben das Tool Deiner Wahl verwenden. Die App allein taugt nur für Installationen aus einem laufenden MacOS heraus für sonst aber nichts...

Joa entweder dem Kext einen "sprechenden" Namen geben oder halt manuell organisieren. Es spricht zum Beispiel auch nichts dagegen die OS spezifischen Versionen von Extensions (mir fällt da zum Beispiel spontan der AirportITLWM.kext ein) innerhalb des Kexts Ordners in eigene Ordner zu packen. Der Vorteil davon ist das man sich das umbenennen der Extensions erspart und das ganze ein wenig übersichtlicher ist der Nachteil ist das man sich um das Eintragen in die config.plist und das aktualisieren dieser Extensions selbst kümmern muss da Tools wie zum Beispiel OCAT "nur" die oberste Ebene des Ordners für Ihre Automatismen nutzen.

Man sollte vorsichthalber vielleicht noch erwähnen das sich das "broken" primär auf AMD Systeme bezieht bei Intel Kisten funktioniert AppleALC mit Sequoia wie gewohnt (aktuelle Version vorausgesetzt)...

Idealerweise hat man eine EFI die für alle Systeme passt. Bei Clover geht das wie von Bob-Schmu beschrieben bei OC sollte es eigentlich gar nicht notwendig sein unterschiedliche Konfigurationen für verschiedene Systeme zu nutzen (ggf. im SMBIOS Bereich bei sehr alten macOS Versionen) hier kann man gut mit den min-kernel/max-kernel Settings arbeiten um bestimmte Kextversionen oder Patches nur für bestimmte OS Versionen zu verwenden ggf. muss man dann halt selbst Hand anlegen um die Dinge in der Verzeichnisstruktur zu organisieren und in die config.plist einzutragen.