A23SS4NDRO

Bella guida, un giorno se avrò problemi darò una chance a RU.efi che lo vedo molto intrigante. I 5 minuti di tempo mi fanno pensare un po' a Mission impossible quando si deve detonare una bomba e hai il conto alla rovescia XD Comunque per Bios Insyde ci sta un tool che gira sia su Win che su linux che funziona allo stesso modo di Ru.efi (anche da riga di comando) https://github.com/macos86/BIOS-Manual-Mode-InsydeH2O/blob/master/GuidaInsydeH2O.md https://github.com/lietxia/XiaoXinAir14IML_2019_hackintosh/wiki/DVMT

ok quindi per le porte del front panel che consiglieresti? metterle come 0xFF o definirle come 0x03 entrambe (dal momento che sono entrambe 3.0?)

no su che cosa intende per connector-type, se intende la porta o se intende la funzionalità dentro il metodo ci credo, windows non ne parliamo va ahahah😂

acpica si esprime a riguardo?

non comprendo dove sia la facilità che possa avvantaggiare clover rispetto ad OpenCore... di certo, se si parla di punti di vista come ad esempio "mi piace più l'arancia rispetto alla pera" ci sta, ma quando si ha a che fare con qualcosa di oggettivo, pratico, è come se uno ora dicesse, mi trovo meglio con Chamelon piuttosto che con Clover

grazie, apprezzo molto quindi le porte "blu" per capirci vanno sempre intese come 3.0 anche quando si tratta del corrispondente valore della porta in acpi con HS, quindi per HS01 Return ( GENG (One, 0x03)) è quello che usi attualmente e che è corretto o è più corretto definire le HS retrocompatibili come 0x00?

alla fine come avete risolto? Io e @dreamwhite abbiamo sentito che khronokernel diceva di mappare le porte in maniera diversa da quanto descritto qui (metodo ora in uso) https://www.macos86.it/topic/1256-post-installazione-su-asus-z370-prime-a-ii/?do=findComment&comment=57816 ma definendo ad esempio come porte interne (0xFF) solo bluetooth o AIO interni, che non scollegheresti mai (che hanno una "higher wake priority" - e che casi come le porte del case perderebbero la funzionalità "hotplug", cosa che, tra l'altro, non mi è mai capitata e vi assicuro che uso al 99.99% delle volte le porte del front panel per collegare eventuali USB per trasferire foto, e non devo riavviare il pc per fare in modo che inserendo la porta la USB compare) => questa cosa che ha detto va in confitto con quanto riportato qui: Riporta invece di definire le porte come il vero connettore presente fisicamente, quindi una porta 3.0 del case che è retrocompatibile a 2.0, va definita nei corrispondenti campi (ad esempio HS01 e SS01 rispettivamente con Return (GENG (One, 0x03)) sia per HS01 che per SS01, mentre ora per HS01 utilizzo Return (GENG (One, Zero)) - cosa che mi ha stupito un po') @Gengik84 se puoi farci un po' di chiarezza in merito, ringrazierei molto, su quale sarebbe l'approccio corretto

- hai letto anche il topic su bugtracker? - da quale build è sorto il problema? - hai provato ad usare una scheda di rete diversa per isolare il problema?

Ciao, questo comportamento è perfettamente documentato in questa sezione: https://dortania.github.io/OpenCore-Install-Guide/extras/kaslr-fix.html Consiglio caldamente di seguire la guida per sistemare - in modo tale che tu riesca anche a capire perché avviene, e associare al problema che hai una causa che hai imparato a riconoscere https://dortania.github.io/OpenCore-Install-Guide/

Comunque ho testato a connettermi con la WiFi e il problema non c'era (prima che risolvessi con quello che ho proposto sopra) Quindi @fabiosun se hai una fenvi in giro prova a vedere se ti torna la sezione Network collegandoti alla stessa rete ma stavolta non per via cablata ma via wireless

Allego qui il comando che ho utilizzato per risolvere: 1) Aprire il finder, e premere CMD + K 2) Dovete conoscere il path remoto dove avete abilitato la condivisione nel caso di SMB, per NFS il comando è leggermente diverso Digitare: smb://username:password@192.168.1.x/MyShare Oppure se si vuole tentare con il login interattivo: smb://192.168.2.x/MyShare al posto del comando mostrato nello screenshot Metodo alternativo da terminale: open 'smb://username:password@server/share' oppure: mkdir /Volumes/SMBShare; sudo mount_smbfs //username:password@192.168.1.x/MyShare /Volumes/SMBShare

Alla fine ho risolto con il metodo che ho spiegato in questo issue: https://github.com/acidanthera/bugtracker/issues/1556 Ma vorrei capirci di più

@iCanaro te se disattivi wifi etc su 11.2.3 vedi server SMB? E invece, 2° test, se disattivi schede di rete Intel (mettendo offline l'interfaccia) e usi solo wifi, vedi qualcosa? Lato funzionamento standard (internet, ping etc) funziona perfettamente Il problema ora sta nel fatto che non vi è alcuna possibilità di vedere se ci sono altre macchine sulla rete

Che scatole, ma come fanno a rilasciare delle regression così? E poi stiamo parlando del release channel stable, non capisco Sarà che è IntelMausi che deve essere aggiornato per essere compatibile?

Mi sa che Apple ha assunto qualche ingegnere microsoft

fino a quando avevo 11.2.2 non avevo problemi con Lan intel e realtek

Potete verificare (se avete server SMB sulla vostra rete) se dopo l'aggiornamento da 11.2.2 a 11.2.3 vi compaiono gli stessi in Network?

in realtà se mettessi prima qualcosa del tipo prima FakeSMC e poi Lilu non sarebbe errato, addirittura lo stesso vale se metti prima RealtekRTL8111" e poi Lilu si certo ma a questo punto conviene direttamente andare a mano piuttosto che aprire un configurator e poi andare a vedere dove eventualmente ha fatto ehm.. "stupidaggini"

certo ma devi usare altri tool per farlo Non è irrilevente che possa corrompere il plist secondo me.. these rarely respect OpenCore's configuration and even some like Mackie's will add Clover properties and corrupt plists!

diciamo che il problema è che si inserisce in un contesto in cui la documentazione già ci sta, non è come clover che non hai un reference manual scritto come si deve - il config-sample.plist presente nel cloverv2.zip è penoso, etc personalmente non lo vedo necessario anche perché non vedo cosa sta succedendo "under the hood" con un applicazione che non è opensource, e può fare anche danni

Dipende, infatti come avevo citato prima: La regola generale de facto è "i plugin vanno dopo"

si ma non sono dipendenti tra loro quindi non cambia...

diciamo che è più una pezza che una soluzione

diciamo che i commenti un po' lo suggeriscono: Però ho sentito opinioni differenti.. riporto alcune citazioni: 1) Kext load order is determined based on dependency. First, all dependencies and CFBundleIdentifiers for all kexts to load are gathered and all parents within the Kexts folder are determined, then the list of kexts is walked - skipping and readding to the end of the list any child kext whose parent has not been added yet. This is repeated until all kexts have been added. As for the ExecutablePath not being filled in - injector kexts are plist-only. They have no executable, and as such, that field will be blank. The executable is determined based on the contents of the Info.plist of the kext, and verified before attempting to walk the list of kexts. This is neither an issue with your config or the software, and appears to be working as intended. 2) Kext load order is specific - but only when comparing kexts that are dependent on each other. Lilu being first isn't a requirement - it just needs to load before any of its plugins. AppleALC and WhateverGreen are not dependent on each other, and as such, it doesn't matter which of them is first - but Lilu must be loaded before either of them as they both depend on it. 3) Both OC Snapshot and the Clean snapshot also verify kext load order based on dependency checking and warn if you attempt to load kexts with duplicate bundle ids that overlap when comparing min/max kernel - [...] (Propertree) also ensures kext load order based on dependency checking, and will prompt if they're ordered incorrectly. Kext load order is verified on every snapshot, clean or otherwise. 4) [...] (Propertree) also verifies kext load order - ensuring that all parents are loaded before children - and if the existing order is incorrect, it'll prompt you with an offer to fix it when snapshotting

diciamo che i commenti un po' lo suggeriscono: Però ho sentito opinioni differenti.. riporto alcune citazioni: 1) Kext load order is determined based on dependency. First, all dependencies and CFBundleIdentifiers for all kexts to load are gathered and all parents within the Kexts folder are determined, then the list of kexts is walked - skipping and readding to the end of the list any child kext whose parent has not been added yet. This is repeated until all kexts have been added. As for the ExecutablePath not being filled in - injector kexts are plist-only. They have no executable, and as such, that field will be blank. The executable is determined based on the contents of the Info.plist of the kext, and verified before attempting to walk the list of kexts. This is neither an issue with your config or the software, and appears to be working as intended. 2) Kext load order is specific - but only when comparing kexts that are dependent on each other. Lilu being first isn't a requirement - it just needs to load before any of its plugins. AppleALC and WhateverGreen are not dependent on each other, and as such, it doesn't matter which of them is first - but Lilu must be loaded before either of them as they both depend on it. 3) Both OC Snapshot and the Clean snapshot also verify kext load order based on dependency checking and warn if you attempt to load kexts with duplicate bundle ids that overlap when comparing min/max kernel - [...] (Propertree) also ensures kext load order based on dependency checking, and will prompt if they're ordered incorrectly. Kext load order is verified on every snapshot, clean or otherwise. 4) [...] (Propertree) also verifies kext load order - ensuring that all parents are loaded before children - and if the existing order is incorrect, it'll prompt you with an offer to fix it when snapshotting