adamantinum

1 ora fa, fabiosun ha scritto:

ciao, ma una qualsiasi macchina virtuale ti parte?

Hai configurato il bios della piastra madre per funzionare in virtualizzazione (IOMMU nel bios)?

 

Ciao, grazie della risposta.
Sì, tutte le altre macchine virtuali partono, anche la recovery di Monterey, e IOMMU è abilitato.

Buonasera a tutti,
Sto provando a far girare Monterey su qemu, usando la configurazione di OpenCore di https://github.com/kholia/OSX-KVM, che in passato avevo visto funzionare.
Il processo di installazione da recovery funziona, anche il primo riavvio, al successivo (dove immagino dovrebbe entrare nel sistema per la configurazione finale) si blocca alla schermata seguente: https://ibb.co/DbwVKjd
Guardando nella sezione di risoluzione problemi di dortania ho provato quanto propone, fra cui abilitare SetupVirtualMap per le VM: https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/extended/kernel-issues.html#stuck-on-eb-log-exitbs-start

Ho provato anche ad aggiornare OC e il plist (https://pastebin.com/XzsrXC79) all'ultima versione, ma il problema si presenta comunque.
Spero qualcuno sappia consigliarmi, grazie in anticipo.

6 ore fa, A23SS4NDRO ha scritto:

No purtoppo l'unico modo per estrarre BaseSystem.dmg è installare con createinstallmedia e andarsela a prendere dalla cartella BaseSystem nascosta, è circa 1GB di recovery che ho salvato qui:

 

https://drive.google.com/drive/folders/1furf_lVuRvzye5Y81WhI-jXRC8CDMizQ?usp=sharing

Se aggiorni le kext su dortania.github.io/builds agli ultimi commit puoi rimuovere quella bootarg che è solo per situazioni di test

Grazie, speriamo nei successivi rilasci torni il classico DMG...

Il 7/6/2021 at 21:57, A23SS4NDRO ha scritto:

Hanno diviso le recovery tra arm e x86, spostandole da AssetData/Restore a AssetData/payloadsv2

Voglio provare a bootare la recovery con il metodo com.apple.recovery.boot

Scusa se rispondo a un messaggio di qualche giorno fa, ma oggi stavo guardando proprio quelle immagini dmg.

Sarebbero l'equivalente di BaseSystem.dmg? Perché provando a convertirle in iso da Linux (sia con qemu-img che con dmg2iso) mi dice che il file è corrotto e non trova qualche cosa specifica UDIF, mentre se uso una recovery di Big Sur riesco a convertire tranquillamente il "vecchio" BaseSystem.dmg.

@xballox piccola correzione: mi è stato fatto notare che VoodooTSCSync non è più aggiornato, tuttavia esiste un plugin di Lilu, CpuTscSync, che dovrebbe svolgere la medesima funzione. Non l'ho ancora provato, ma tienilo comunque presente nel caso volessi aggiornare.

Il 13/9/2020 at 15:19, labam ha scritto:

Salve,

avrei il tuo stesso problema ma con un notebook differente, ossia in firma, se il notebook va in sleep alla ripresa  lo schermo si illumina soltanto, niente video, il resto sembra funzionare correttamente, ho provato ad inserire le ultime release dei kexts in questione ma non ho risolto...

qualche altro suggerimento?

Massimo

A me fortunatamente era bastato quello, però ho usato le beta, non le ultime release...  Puoi trovarle sul sito di dortania oppure provare a compilare da te.

Ho ricompilato Lilu e Whatevergreen agli ultimi commit e pare sia stato sufficiente per risolvere.

Grazie per il suggerimento, ma purtroppo il problema persiste sia provando il boot arg, che provando il plugin...

Buonasera,

Ho aggiornato da un po'a Big Sur e ho notato molti miglioramenti rispetto a Catalina. L'unico problema creatosi è l'impossibilità di risvegliare il monitor del laptop dopo la messa in stop del sistema (qualsiasi sia l'hibernatemode: 0, 3 oppure 25): resta soltanto lo schermo nero illuminato, pur "funzionando" premendo i tasti sento i suoni di sistema. Provando tuttavia a collegare un monitor esterno VGA si risveglia anche lo schermo interno e posso usare il sistema senza problemi (oltre a vedere gli effetti dei tasti premuti a schermo nero illuminato). È un problema di iGPU come credo? Esistono solzioni? Oppure posso crercare file di log per riportare un issue, a Lilu o Whatevergreen suppongo? La EFI è quella in firma, OpenCore versione 0.6.1, il problema avviene per qualunque versione di BS.
Grazie in anticipo a tutti.

16 ore fa, xballox ha scritto:

Guarda veramente grazie mille! Ora sembra veramente funzionare tutto ! Non so come ringraziarti veramente. 

Figurati! Sono stato un anno con un sistema inutilizzabile perché non sapevo come risolvere, ora non posso che aiutare chi è nello stesso problema 🙂 

Avevo problemi con glitch simili dopo l'aggiornamento del firmware UEFI di ASUS, ho risolto col kext VoodooTSCSync. Prova, magari funziona anche per te.

Breve aggiornamento, forse ho capito dove sia il problema (o parte di esso): se nel config abilito come satelliti sia ELAN che HID, indipendente dall'ordine con cui i kext sono dichiarati, per qualche motivo viene caricato solo ELAN e il touchpad non va. Se abilito solo HID il touchpad non è riconosciuto dalle impostazioni, ma funziona per spostare il cursore e per cliccare, mentre le gesture a più dita non vanno. Considerando che dà questo problema anche con versioni più vecchie di I2C che in passato mi funzionavano mi verrebbe da pensare sia cambiato qualcosa nella gestione dei kext...

Ecco qui, non vedo dove possa essere la differenza rispetto a quando qualche mese fa funzionava tutto, prima di rifare la EFI.

archivio.zip

Allora non ho capito di quale Darwin parli, ho presente solo quello del controllo.

No, il Darwin adesso non c'è.

Il Kernel Panic avveniva con 
 

Method (_STA, 0, NotSerialized)  // _STA: Status
            {
            	If (_OSI ("Darwin"))
                {
                    GPEN = One
                    SBRG = One
        	    }
                
                If ((SBRG == Zero))
                {
                    Return (Zero)
                }

                If ((GPEN == Zero))
                {
                    Return (Zero)
                }

                Return (0x0F)
            }

Invece boota riducendo il tutto a 

Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                Return (0x0F)
            }

Ioreg è il seguente... All'avvio il touchpad dovrebbe essere riconosciuto e pinnato senza problemi, se sapessi come controllare i blog di boot verificherei.

ioreg.zip

0x0f, ho sbagliato a scrivere nel post.

OK, il problema era proprio Return (0x0f). Seguendo la guida su dortania avevo aggiunto un if (_OSI("Darwin")) che rendeva alcuni oggetti col valore giusto LER far ritornare 0x0f a _STA. Non perché ma dava panic. Sostituendo tutto con solo Return (0x04) boota senza problemi. Il touchpad però non va 😂

L'avevo già fatto con SSDT, ora ho provato anche direttamente in DSDT ma va comunque in panic...

Mi è stato consigliato di chiedere direttamente sul supporto di VoodooI2C, magari sanno se il panic è colpa del kext (credo proprio di sì dato che riporta VoodooGPIO nel backtrace).

Al limite rifaccio la EFI da capo quando esce OC 0.6 😄

Purtroppo sono ancora qui 🙁
Dopo aver patchato il DSDT (allego se qualcuno vuole controllare), al remoto va in Kernel Panic a VoodooGPIO, eppure mi pare di aver seguito correttamente l'ordine dei plugin suggerito dalla documentazione VoodooI2C (Services, GPIO, I2C) e la guida per il GPIO pinning: dispositivo ETPD, pinning eseguito manualmente. Codice apice 0x6d, quindi il pin decimale è 85 e quello hey 0x0055.

Qui una foto del Panic, se può servire: https://ibb.co/9WjVwk5

Grazie per la pazienza 😅

DSDT.aml.zip

Parte, grazie mille! Ora ho applicato le patch e devo solo trovare l'ordine corretto dei kext per evitare vada in panic ahah.

Ma a cosa serieve la patch per la batteria che hai messo? Dovrebbe influire sulla durata? Perché ho notato che il PC si scarica in fretta.

Patchato in che senso? Indicatore e percentuale di batteria funzionano, usando solo SMCBatteryManager

Questo sembra proprio qualcosa del DSDT...

Va bene, provo. Input l'avevo messo perché adesso è incluso tra i plugin di I2C

Senza boota normalemente.

L'ordine dei miei kext è il seguente:

Lilu

VoodooTSCSync
VoodooInput
VoodooI2CServices
VoodooGPIO
VoodooI2C
VoodooI2CELAN
VoodooI2CHID
VoodooPS2Controller
VoodooPS2Keyboard
VirtualSMC.kext
SMCBatteryManager
SMCSuperIO
WhateverGreen
AppleALC
USBInjectAll

Purtroppo si blocca sempre a questo punto e poi dà il simbolo di divieto.