Sofern Dein T440s auch über die 2 NGFF-Steckplätze verfügt,
ACHTUNG!!!! das T440s hat noch die whitelist. ohne gemoddetes bios kann die wlankarte NICHT getauscht werden!!!!!!
Posts by grt
-
-
Lediglich der Boot davon macht Probleme
sicher? ich hatte damit keine probleme beim T440s.
-
touch&stift ist wacom. ich hatte auf dem yoga 260 catalina am laufen, und konnte den stift in den systemeinstellungen konfigurieren, wenn ich mich recht erinnere. du hast was installiert? catalina oder bigsur?
-
touchscreen häangt am usb. ab catalina ist fingertouch nicht mehr möglich. stift geht aber weiterhin.
cardereader geht mit sinetek..kext. evtl einmal mit steckender leerer karte booten.
-
*grins... der bericht sagt doch ganz klar, was los ist
da fehlt die config.plist einer kext. entweder hab ich die komplette kext vergessen, oder (wahrscheinlicher) ich hab vergessen, dass bei meinen usb-kexten die info.plist nicht in contents, sondern direkt im kext selbst liegt. ist mir glaube ich mittlerweile etliche male passiert, und ich denk immer wieder nicht dran...
also. will heissen, alles broadcomspezifische muss weg. sind 3 kexte in der config.plist, die auf deaktiviert gehören. ausserdem sollten die deviceproperties für die broadcom raus - mit pciroot(0x0)/pci(0x1c ... fängt der eintrag an.
für die intelkarte muss unter kernel/force der eintrag für die io80211family.kext aktiviert werden.
und der pfad für die info.plist des usbkexts heisst Info.plist, nicht Contents/Info.plist - guck aber noch mal nach, ob die kext wirklich drin liegt. und usbinjectall.kext könnte aktiv sein, die deaktivier bitte, wenn dem so sein sollte.
wenns dann wieder hängt, foto bitte.
die seriennummern sind komplett genullt, da müsste wenn du die config oder teile davon nutzt, später was eigenes her.
-
also ja.. ein foto vom hänger/abbruch wär ganz nett.
ausserdem sagte ich ja bereits, dass ich eine broadcomwlankarte verbaut hab. mindestens das müsste deaktiviert werden.
2 akkus gibts ebenfalls, und dock dafür keins. all das könnte in die suppe spucken.
und eigentlich war die efi wg. eben der wlankarte und der veralteten ocversion auch eher zum gucken und vergleichen gedacht.
-
habt ihr mir einen Tipp wie ich die Kext-datei unter Windows bearbeiten kann?
was genau willst du bearbeiten? die kexte selbst doch nicht etwa? config.plists kann man eigentlich mit jedem texteditor bearbeiten. was es da an spezielleren, komfortableren als den systemeigenen editor für windows gibt, weiss ich allerdings nicht. hier gibts nur macos oder linux..
-
die herren bitte
zanken, wenn noch nötig hinter den kulissen per pn. oder noch besser gar nicht zanken.
-
ich schrub ja auch, dass die eher zum vergleichen ist..
und ein foto der panik wär evtl. recht aufschlussreich.
mein t440s hat 2 akkus und ausserdem statt der intelwlankarte eine broadcom dw1820a verbaut (dafür brauchte es ein modbios ohne whitelist). die broadcomkexte, sowie die einträge für wlan in den deviceproperties passen nicht zu deiner intelkarte, was evtl. ärger verursachen könnte, und ich hab die seriennummern "genullt", auch das könnte ärger machen. mindestens die 2 sachen sollten angepasst werden. ausserdem wärs interessant, zu wissen, ob du einen oder 2 akkus hast.
kexte werden aus dem efi-ordner ins system geladen beim start, wenn sie im kextordner liegen, und in die config.plist unter kernel/add korrekt eingetragen wurden.
-
ja, auf meinem läuft bigsur. ich hab mal meinen efiordner ausgebuddelt und drangehängt. opencore ist alles andere, als frisch, also eher zum vergleichen geeignet. für wlan zuständig ist die ssdt-T440s-arpt.aml. ich hab allerdings inzwischen eine dell dw1820a-karte eingebaut (modbios!), die broadcomkexte brauchts bei dir also nicht. beim airportitlwm.kext muss man auf die zum system passende version achten, und da gab es noch weitere massnahmen, von denen man eine aussuchen muss. ich hab mich bei intelkarten für das forcieren des io80211family.kext entschieden:
sip schalte ich meistens ab.
-
bei meinem t440s brauchts eine ssdt damit die wlankarte überhaupt erkannt wird.
ich guck nachher mal danach
-
später, bzw. morgen. bin noch unterwegs.
-
ich seh nix, was mir falsch vorkommt. die efi von meinem T440s ist nicht grossartig anders auf den ersten und 2. blick.
in deiner ist die BATC-ssdt drin, die macht nur sinn, wenn auch 2 akkus verbaut sind (wenn nicht, auch die acpi-patches, die irgendwas mit BATC zu tun haben, deaktivieren!). die idee, eine minimalefi für die installation zu nutzen finde ich gut. macht sinn.
im bios sollte eingestellt sein:
security -> execution prevention = enabled
boot -> uefi only
csm-support enabled/yes
EDIT: dock lass erstmal weg. alles, was zusätzlich ist, kann in die suppe spucken.
-
core i5 10400f
die prozessoren mit F haben doch gar keine igpu??
-
wie wärs denn mal mit einem boot mit dem abgespeckten efi-ordner von letztens, dem vor allem das -v gefehlt hat? da hing die kiste, aber es war leider nicht zu sehen warum, weil eben kein -v als bootarg. der gedanke, die efi bis aufs absolut notwendige abzuspecken ist ja genau richtig, aber bisher gibts noch kein aussagekräftiges ergebnis zu dem versuch. stehengebliebener apple-fortschrittsbalken sagt in etwa genau garnix aus..
ausserdem:
in (lenovo) läptopps wurden gerne samsung-evo-plus nvmes verbaut, mit der alten bockigen firmware, die nicht zur zusammenarbeit zu bewegen war, und leider bei läptops auch nur (wenn überhaupt) mit läptopherstellereigenen tools auf kompatible firmware geflasht werden konnten (windows hatte keine probleme damit, linux auch nicht). könnte ein grund für die nvme-kextbasierten kernelpanics sein. wenn eine ssd/nvme eines anderen herstellers greifbar wäre, könnte das vielleicht hilfreich sein.
-
muss die EFI, insbesondere die Kexte entschlackt und aktualisiert werden
genau das ist schon passiert. lilu, weg, virtualsmc (+2 plugins, dass die nicht undbedingt sein müssen, schrub ich irgendwo oben). zzgl. appplealc.kext. der stört aber offensichtlich nicht. allerdings fehlt da immer noch das ergebnis eines boots mit -v.
und vermurgelter acpikram, z.b. doppelte device-einträge/definitionen aus ssdt und dsdt gleichzeitig, oder deaktivierte, aber notwendige devices - was schnell passieren kann, wenn man ssdts einbaut, ohne zu prüfen, ob und wie die benötigt werden - kann ganz schön querschlagen. mal so nebenbei bemerkt. und das sehe ich nicht als finetuning. aber wenn du meinst, dass ich ruhe geben sollte, weil du hier besser helfen kannst, ok. dann viel erfolg.
-
Die SSDTs müsste ich bearbeiten, da war mir ja nicht mit was ich die bearbeiten sollen
jein... du müsstest vor allem erstmal die originale dsdt inspizieren. gibts das device PNP0C09. wenn ja, wie heisst das dingens. wenn es EC heisst, dann nimmst du die ssdt-usbx.aml so, wie die als prebuild angeboten wird. einfach rein in die efi, eintragen in die config.plist, gut ist. wenn das device irgendwie anders heisst, dann brauchts eine ssdt-ec-usbx.aml mit einem dummy-ec-device, was mac os beruhigt. das macht nix, aber ist da, heisst EC, und system ist zufrieden. und das ist gerade unklar. brauchts das, oder brauchts das nicht? meine thinkpaderfahrungen sagen "wohl eher nicht", aber ich hatte bisher noch kein thinkpad neuer als 6.gen in den pfoten. destawegen nachgucken bitte.
aber das problem mit den kernelpanics bzgl. nvmedingens hat mit dem EC eher nix zu tun. da ist was mit dem datenträger faul, der will was, was wir noch nicht erausgefunden haben, und was sich anscheinend auch von anderen T470 unterscheidet.
-
da ist immer der ionvme...kext mit im spiel bei den letzten kernelpanics. ist jeweils der nvmefix.kext in der efi? und was für eine nvme nutzt du kentallica ? hattest du mal versucht, mit deiner abgespeckten efi und dem -v als bootarg zu starten, wenn ja, was ist dann passiert?
die ssdts kannst du mit maciasl bearbeiten, und damit kannst du auch die originale dsdt angucken. eigentlich musst du nur mal nachgucken, was es mit dem EC-device in deiner dsdt auf sich hat. gibts eins, was auch EC heisst und nicht EC0 oder was auch immer anders, dann kannst du ganz getrost die prebuild SSDT-USBX einsetzen statt der mit dem EC-anteil. plug bleibt so wie sie ist, das kann man später mal "hübsch machen".
sooo.. ich hab mal geguckt, in arkturus' efi gibts den nvmefix nicht. versuch könnte sein, den nvmefix mal mit ins spiel zu bringen. oder eine andere nvme einzusetzen, falls da u.u. so eine von den bösartigen samsungs drinstecken sollte.
-
jein.. zumindest genau durchlesen, ob was angepasst werden müsste. steht in dem manuell bauen abschnitt drin.
die EC-USBX überprüf mal. ich denk, die brauchts nicht, da reicht die USBX aus. aber guck bitte nach.
PLUG ist für die CPU, da kann angepasst werden - alles löschen, was nicht dem eigenen pfad für die cpu entspricht. muss aber nicht zwingend sein, der nicht passende rest stört niemanden.
PNLF ist für die helligkeitsregelung, würde ich vorerst weglassen. gelegentlich macht die ärger, oder die version passt nicht oder so. nötig ist die helligkeitsregelung für die installation nicht.
und XOSI macht bei dualboot sinn, wenn man teile der ssdts beim windowsboot per OC (oder clover) nicht ausgeführt haben möchte. stört aber auch nicht, wenn sie da ist.
die beiden plugins für virtualsmc.kext könnten auch noch wegbleiben. für die installation werden sie nicht benötigt, sollten aber auch nix an ärger machen meines wissens nach.
intelmausi.kext fürs netzwerk würde ich einsetzen. die passt immer, muss sowieso dazu, und evtl. bewirkt das nicht erkannt werden des netzwerkanschlusses als EN0, dass man später da nacharbeiten muss.
ein voodoops2.kext muss bei einem läppi schon sein. gerade, wenn es sein könnte, dass usb nicht oder nur teilweise geht, guckt man ziemlich dumm in die röhre, wenn am einzigen reagierenden usbanschluss der installerstick hängt, und tastatur und trackpad nix machen. speziell, wenn man das erste mal im installerscreen gelandet ist, und dann wg. sowas nicht weiterkommt, ist der frust dann so richtig fies (ich sprech aus erfahrung...)
das usbmapping sollte ab bigsur vorab erledigt werden. dann besteht die gute chance, dass man nicht mit einem usbanschluss (wenn überhaupt einer geht..) durch die installation krepeln muss.
und warum auch immer der sein muss, ich hatte bei neueren smbios-versionen (ab 7.gen) immer den notouchid.kext im einsatz. soweit ich informiert bin, brauchts den, wenn das eingesetzte smbios-modell diese seltsame touchbar hat, der zu installierende läppi aber nicht.
-
ist ja auch nicht ganz falsch das mit den ssdts. aber das kapitel manuelles erstellen der ssdt ist aus meiner sicht das wichtigste, und sollte nicht einfach so übersprungen werden. bei der ssdt-plug tut es nicht wirklich weh, wenn man nix anpasst, bei der EC kann nicht anpassen schon zu durcheinander führen.
der ansatz jetzt mit deutlichst abgespecktem efiordner weiterzumachen ist schon richtig. deinen erster ordner fand ich z.b. haarsträubend übefrachtet für einen erstinstallationsefiordner.. den neuen schon deutlich besser. das wird schon noch. bios hattest du abgeglichen? und eine 2. grafikeinheit hat der läppi nicht?
