Anto65

Probabile il time out è impostato a 0 e si deve selezionare a manina Se impostato 1-3-5 sec.i al riavvio si posiziona in automatico su Macos installer, dopo i sec.i di attesa impostati... l installazione continua Almeno da me è impostato così ( 3 sec.i ) e funziona Una volta lanciato l aggiornamento... Vado al bar a prendere il caffè Al ritorno ha fatto tt da solo 😜

Si ma ora da dove stai avviando però ? Mica stai usando la usb con i driver abilitati x Linux, non dovresti vede quelle icone bensì come la foto sopra

A sto punto disabilita la entry di Zorin È lo avvi da Ubuntu 🤷‍♂️ Era diverso se erano in dischi separati e ognuno con la propria Efi

!!! Sostituisci il config.plist.zip Windows e' rimasta FS0 mentre le distro sono su FS7 ... gia' modificato dovrebbe essere a posto Sostituito anche /\EFI\Microsoft\Boot\bootx64.efi con /\EFI\Microsoft\Boot\bootmgfw.efi ... visto che prima nn l avviava 🤞

Ok anche Debian ha grubx64.efi... Dovrebbe avviarlo 🤔 La FS dov è OC qual è ? ( da map-table )

Hi try , EFI.zip updated to OC 0.8.3 (commit 8312345) Keep yours safe

Aggiungo Ventura Beta4 Full Installer ( tramite browser ) https://swcdn.apple.com/content/downloads/38/20/012-43306-A_W9DB8VVCIJ/bc67zqs7nmctf0532u7x0getywayvn1zz1/InstallAssistant.pkg

Tu mi dici quello che devo fare e io lo faccio 😂 Mi spiace x la gpu credo non sia un grosso problema ... hai gia' il case pure ... pazienza Si lo puoi fare anche dal mac ... hackcheck .. l avevi gia' scaricato o sbaglio ? Qua mi sa che ti sbagli 😉

Esperti e' na parola grossa 😆 ( parlo x me ) Credo che il wake on lan possa influire Se hai applicato la patch di Gengik https://www.macos86.it/files/file/71-patch-usb-connector-type/ e' specificato come definire i connettori sul SSDT usb3 > 0x03 .... etc

Per chi non si ricorda 🙃 come ha impostato il valore CSR ( SIP ) con l ultimo commit https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true&version=0.8.3&sha=83123452fe6bb254ad40ff7a55e142213f1ea4c0 e' possibile visualizzarlo al boot ( Aggiungere " --show-csr " in Arguments ) Occio cambia la struttura del plist nella sezione drivers Da Enabled ( YES / NO ) a Load ( Enabled / Disabled )

Be' la gui almeno sembra aposto al boot 🙃 E' un po' un casotto cosi' .... quando installo qualsiasi distro di linux , disabilito qualsiasi altro disco dal bios in modo che grub non venga installato dappertutto e non crei le sue cartelle ubuntu o debian nelle partizioni EFI altrui Cosi facendo la Cartella EFI viene creata nel proprio disco di destinazione Puoi provare a montare la partizione EFI dI Windows ( con OCAT dovresti riuscire se ti da problemi puoi usare anche Hackcheck ) Copiare le cartelle debian e ubuntu sul dektop eliminare debian e ubuntu dalla partizione EFI del disco ( Windows ) Copiare / sostiutire la EFI che hai nella usb nella partizione EFI di macos_120gb Copiare le cartelle debian e ubuntu precedentemente salvate sul dektop nella EFI di macos_120gb , dovresti avere cosi' fai anche una foto all interno della cartella debian cosi ( la mia e' deepin ) Ripeti la mappatura da shell ( SENZA LA USB INSERITA ) ... dovresti trovare adesso la EFI di OC in FS1 oppure 2 ( FS0 sappiamo che e' WIN ) in modo da ottenere il nuovo percorso Alternativa avviare Linux da bios tramite f11 o quello che e'

Con l installer completo credo che sostituisce x intero quello che riguarda il bluetooth, cosa che che non riesce a fare con l aggiornamento incrementale, invece di aggiornarlo cerca di sostituirlo... Fallendo https://www.insanelymac.com/forum/topic/351969-pre-release-macos-ventura/?do=findComment&comment=2788755

Ieri dopo aver provato diversi commit precedenti di OC 0.8.3 , Clover , OC-Debug , con e senza Fakesmc , OC- Mod ... niente l errore persisteva Disabilitato BlueToolFixup.kext ... boom ha preso e aggiornato tranquillamente Non saprei se questa e' la soluzione valida per tutti , noto anche problematiche diverse , ma comunque da tenere in considerazione

Ops ! Adesso non so' se dipende pero' , dalla mia superfibra 😄 ... riproviamo

Se lasciavi il time out com era 1-3 Secondi ... faceva tutto da solo ... comodo x quando si aggiorna 😉

Beta 4 ( 22A5311F ) 🤣

Dal pdf ResizeGpuBars Type: plist integer Failsafe: -1 Description: Configure GPU PCI BAR sizes. This quirk sets GPU PCI BAR sizes as specified or chooses the largest available below the ResizeGpuBars value. The specified value follows PCI Resizable BAR spec. Use 0 for 1 MB, 1 for 2 MB, 2 for 4 MB, and so on up to 19 for 512 GB. Resizable BAR technology allows to ease PCI device programming by mapping a configurable memory region, BAR, into CPU address space (e.g. VRAM to RAM) as opposed to a fixed memory region. This technology is necessary, because one cannot map the largest memory region by default, for the reasons of backwards compatibility with older hardware not supporting 64-bit BARs. Consequentially devices of the last decade use BARs up to 256 MB by default (4 remaining bits are used by other data) but generally allow resizing them to both smaller and larger powers of two (e.g. from 1 MB up to VRAM size). Operating systems targeting x86 platforms generally do not control PCI address space, letting UEFI firmware decide on the BAR addresses and sizes. This illicit practice resulted in Resizable BAR technology being unused up until 2020 despite being standardised in 2008 and becoming widely available in the hardware soon after. Modern UEFI firmware allow the use of Resizable BAR technology but generally restrict the configurable options to failsafe default (OFF) and maximum available (ON). This quirk allows to fine-tune this value for testing and development purposes. Consider a GPU with 2 BARs: • BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB. • BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB. Example 1: Setting ResizeGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged. Example 2: Setting ResizeGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB. Example 3: Setting ResizeGpuBars to 16 GB will change BAR0 to 8 GB and leave BAR1 unchanged. Note 1 : This quirk shall not be used to workaround macOS limitation to address BARs over 1 GB. ResizeAppleGpuBars should be used instead. Note 2: While this quirk can increase GPU PCI BAR sizes, this will not work on most firmware as is, because the quirk does not relocate BARs in memory, and they will likely overlap. Contributions to improve this feature are welcome. Se puo interessare vit9696 https://www.insanelymac.com/forum/topic/349485-how-to-opencore-074-075-differences/?do=findComment&comment=2770810

Aggiungo pure questa da verificare PlatformInfo> UpdateSMBIOSMode> Custom (default e' Create) Se non si vuole mettere mano all ssdt @Giaccaz 🙃 puoi provare la mod di OC EDIT : @Extreme™ vedo che hai aggiunto l altra l immaggine 👍

HE EHE HE ... vorrei che cominciasse a editare da solo @ldp48 devi inserire lA PARTIZIONE INTERESSATA ... cioe' FS0 non tutto il resto ... Anyway Avevo gia' pronto 🙃 il config.plist.zip l unica cosa che devi fare e' inserire il percorso della tua FS0 cioe' questo : PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,AB260C35-02AC-41BF-AE93-14AD0AB12FF1,0x800,0x32000) ( dal tuo map text ) lo sostituisci qui , quello in rosso , a tutti e 3 Ho disabilitato i drivers per Linux e cambiato lo scanpolicy le icone Ubuntu.icns.zip e Zorin.icns.zip copiale nella cartella del tema in OC > Resources > Image > My-Theme > Apple13 Prova un po'

Ma seguire la guida ? 🙃 ... apriamo il file map-table.text e copiamo la path , che andremo ad inserire nel plist in Misc/Entries ...

Mi sto preparando 😁 https://imgur.com/a/DJtPA9K

Hai confrontato con il sample.plist ?

map > map-table.text si lo ritrovi nella EFI DI OC

A ok... perché usano tutti la stessa part.e EFI Cioè FS0 Ubuntu e Debian non hanno una EFI x conto suo Salva il file di testo... Avranno tutti lo stesso percorso

non interessano le FS dove c e' il sistema , bensi solo le partizioni EFI , quelle devi memorizzare Es. x WIN ( NEL MIO ) FS0 quindi qual e' quella di win FS1 o FS4 ? Quelli sono i file di siStema ... devi individuare la EFI ( nel mio caso FS1 )