Leaderboard

@Anto65 @fabiosun fatto aggiornamento kext e funziona di nuovo tutto perfettamente, grazie a tutti.

For Win 10 32-bit SYSTEM setup I'm finding this seems to work best / quickest.

Thanks for your appreciation on my guide, probably resetting the nvram parameters recreates the kext blacklist, I'm on 6.1.48 right now and I'll try with 6.1.50. Yes the new AMFIPass doesn't require the specific bootflag, I'll update the guide.

As I've specified in the bottom of the thread Ventura and Sonoma are not supported as guest os right now, I'm investigating and probably the issue is that AVX2 CPU extensions are required for these two latest releases of macOS and they are not passed to the VM. Probably with a custom OC EFI and CryptexFixup.kext it could work but I need to test it.

Hi Tomnic, Nice guide. Ive tried this with 6.1.50 and everything working installing Win 10 guest into the Box Host on Sonoma(in the process installing Win 32bit apps I needed etc...) but on reboot and resetting NVRAM SIP to 0000000 & removing the AMFIPass kext in config.plist its back to the kernel error cant load. Any info on this? BTW I used AMFIPass v1.40 and didn't require the bootflag -amfipassbeta METHODOLOGY 1. In config.plist (see image) inside your boot EFI, Add the numbers csr-active-config = 03080000 (see image) into the NVRAM section of config.plist (to workaround security & Privacy Oracle Box kext sign problems with this partial SIP disable). 2. Add AMFIPass.kext details (see image) into kernel section of config.plist. Save config.plist back to the EFI /OC folder. 3. Download version 1.40 of AMFIPass.kext and copy it over onto your EFI drive's Kext folder. 4. Ensure you can reset NVRAM in Opencore when rebooting 5. Reboot, and hit space, number to reset your NVRAM. 6. Now it should boot with your SIP disabled and use AMFIpass to allow the box kernel thru. 7. Download & install Vbox v.6.1.48 or 6.1.50 8. During the installation process it should ask you to sign / allow the Oracle Virtual Box / ALLOW it inside your 'System Settings' Security & privacy section. 9. After install and the kernel of box has been signed it will ask to reboot. Go ahead and reboot. 10. After reboot, locate and download/install Oracle_VM_VirtualBox_Extension_Pack-6.1.50.vbox-extpack (if using ver 6.1.50) 11. Now grab a ISO from Microsoft and install your guest OS - in my case it was Windows 10 32 bit iso 12. Go thru the motions of installing the guest OS like you normally would. 13. Locate and download VBoxGuestAdditions_6.1.50.iso or VBoxGuestAdditions_6.1.48.iso and install them from a guest ISO storage drive.This will provide a number of addition hardware features and functionality. 14. Finally, fine tune your guest OS for display USB pointing devices etc... 15. If you get problems running virtual box - quit Vbox completely (stop any guest VMs running first if you can) and then rerun it by running it from within Applications folder and not as an alias as sometimes aliases get corrupted or lose sight of the software. 16 I tried then resetting SIP to Enabled and disabling AMFIPass kext inside config plist Kernel section, reboot, resetting NVRAM and booting up to Sonoma but the Kernel errors reappeared and I found they were no longer 'Allowed' by the OS. Subsequently, virtual box guest VM's failed to start. 😞 17. So went back to partially Disabling SIP (csr-active-config = 03080000) but didn't require AMFIPass to ON now that Ive installed vBox. More on this soon... useful links: Virtual Box Old Builds: https://www.virtualbox.org/wiki/Download_Old_Builds_6_1 and https://download.virtualbox.org/virtualbox/6.1.50/ to find the Guest Additions etc... AMFIPass kext: https://community.macmeup.com/index.php?/files/category/3-kexts/. or payloads/Kexts/Acidanthera/AMFIPass-v1.4.0-RELEASE.zip

We talk about it in another thread in Italian and in English😉

è andato tutto a posto Grazie

Tralasciando il livello infimo di conoscenza dell'autore dell'articolo pubblicato del mondo Hackintosh e dei quattro poveracci che sostengono che OCLP sia un pericolo per la sicurezza quando i processori Apple Mx sono TUTTI attaccabili a basso livello per natura (al pari ahinoi delle CPU x86/x86_64 con bug equivalenti di progettazione) scinderei il discorso su vari livelli: Se parliamo di supporto di macOS futuri all'architettura Intel x86_64 per le CPU siamo d'accordo, la possibilità di installare nativamente l'ultimo macOS in circolazione morirà molto probabilmente con la prossima release di MacOS 15. Se parliamo di supporto di macOS alle ultime GPU, siamo già morti da Monterey: viviamo con la serie AMD RX 6xxx con la sola possibilità di "raddoppiare" le performance aggiungendo GPU identiche... M2 Ultra non supera due RX 6950XT tuttavia... ci sappiamo ancora difendere! M3 Ultra non lo vedo ancora circolare... Se sarà possibile installare versioni di macOS future su Desktop ARM perché tanto anche il mainstream virerà verso altre architetture? Chi può dirlo? Il reverse engineering delle GPU Apple è stato già fatto mirabilmente con Asahi linux, si può benissimo adattare il lavoro, seppur tosto, a Darwin per ARM... Certo fare Hackintosh cambierà... ma chi si ricorda quando si partì da PearPC per avere la primissima release di Tiger funzionante su Intel? C'è sempre un trampolino di lancio dietro l'angolo a voler leggere la storia del fare Hackintosh. Finché c'è volontà di studiare e sviluppare nulla è mai morto o impossibile da implementare, altrimenti ogni battaglia non intrapresa è sempre sicuramente persa!!!