Clover General discussion

[deeveedee]

@MakAsrock I took a quick look at your config.plist and don't see any glaring issues, other than the fact that you're using SMBIOS MacMini8,1 with a 12th Gen Intel PC.  I suspect that if you are having issues, it's more because you're attempting to use an SMBIOS for an 8th Gen Intel platform that expects an iGPU than because of your use of -no_compat_check.  I would think that with 12th Gen Intel / no iGPU / dGPU that you'd be using MacPro7,1 which is supported by Tahoe.

[MakAsrock]

10 minutes ago, deeveedee said:

@MakAsrock I took a quick look at your config.plist and don't see any glaring issues, other than the fact that you're using SMBIOS MacMini8,1 with a 12th Gen Intel PC.  I suspect that if you are having issues, it's more because you're attempting to use an SMBIOS for an 8th Gen Intel platform that expects an iGPU than because of your use of -no_compat_check.  I would think that with 12th Gen Intel / no iGPU / dGPU that you'd be using MacPro7,1 which is supported by Tahoe.

So, I was just trying to test the effect of the -no_compat_check boot argument. The result was negative. I'll try it tomorrow on a different system unit with 10th Gen Intel a UHD630 iGPU and a Radeon RX 560x dGPU. 

Then I'll write back and tell you what happened.

[LockDown]

14 hours ago, deeveedee said:

@LockDown and @MakAsrock

I'm probably misunderstanding what you're saying, so could you please clarify? - thank you.  I routinely install macOS Tahoe with boot-arg -no_compat_check or with Booter Patch "Skip board ID Check" using unsupported SMBIOS MacMini8,1.  I can perform this installation on systems with only UHD630 iGPU and with systems that have both dGPU Radeon RX 560x and iGPU UHD630.

 

Under what conditions does -no_compat_check or Skip Board ID check no longer work for installing Tahoe on systems with unsupported SMBIOS?

Im referring installation in general, as we are not in Tahoe thread.

Note: Pic not mine

 

Last time i did a fresh install ( not nessesarily Tahoe). i only mentioned Tahoe to test the "Repaired feature that SMBIOS choosing automatically according to OS version."

 

If i use unsupported smbios WITHOUT -no_compat_check or "Skip board ID Check", i get this  (which is obvious)

 

If i use unsupported smbios WITH -no_compat_check or  "Skip board ID Check", i get this (disregard whatever OS version is in the pic)

 

I have yet to try in Tahoe if the latter still accuring on a clean install

Edited July 7 by LockDown

[ThriftLover]

1 hour ago, LockDown said:

If i use unsupported smbios WITH -no_compat_check or  "Skip board ID Check", i get this (disregard whatever OS version is in the pic)

 

I have yet to try in Tahoe if the latter still accuring on a clean install

To fresh install Big Sur or later using unsupported smbios, I think you need vmm spoof such as revpatch=sbvmm. For an update, you need to be running on Big Sur or later as vmm spoof won't work in Catalina or older. You need both board-id bypass and vmm spoof to install or update when using unsupported smbios.  

[MakAsrock]

11 hours ago, MakAsrock said:

So, I was just trying to test the effect of the -no_compat_check boot argument. The result was negative. I'll try it tomorrow on a different system unit with 10th Gen Intel a UHD630 iGPU and a Radeon RX 560x dGPU. 

Then I'll write back and tell you what happened.

Don't ask how it was installed, I didn't do it.
The computer does not belong to me:
Motherboard: ASRock Z390 Phantom Gaming 6
iGPU: Intel HD Graphics 630
dGPU: Sapphire Pulse Radeon RX 580 8GB GDDR5
RAM: 32GB DDR4-3000
SSD: 128GB WD Green M.2
Audio: Realtek ALC1220 (Onboard)
LAN: Intel I219V + Realtek Dragon RTL8125AG (Dual LAN)
I/O: USB 3.0 / 3.1 / 3.1 Gen 2
Monitor: Full HD (via HDMI)
macOS Big Sur - Everything is installed and works perfectly.
macOS Tahoe - With -no_compat_check Bootloop

macOS Tahoe - With SMBIS MacPro7,1 (with -no_compat_check and without it) Everything is installed and works perfectly.

 

 

config.plist.zip

Edited July 7 by MakAsrock

[LockDown]

2 hours ago, ThriftLover said:

revpatch=sbvmm or board-id=VMM-x86_64 

adding to what @ThriftLoversaid, seems to work with tahoe 😮

Let me try again later... Have to go for now

Edited July 7 by LockDown

[MakAsrock]

1 hour ago, LockDown said:

adding to what @ThriftLoversaid, seems to work with tahoe 😮

Let me try again later... Have to go for now

Yes, it works for me.

[Matgen84]

@MakAsrock and All.

I confirm too. Using long time ago, revpatch=sbvmm as Arguments is working fine on my Z390 (Coffee Lake-R)  with MacPro7,1 SMBIOS.

[LockDown]

1 hour ago, MakAsrock said:

Yes, it works for me.

Not only in Tahoe. Previous OSs now works too👍

[deeveedee]

I have needed to use revpatch=sbvmm in my config.plist since Sonoma.  I thought everyone was using it for their hacks - no?

 

EDIT: This helped me for enrolling unsupported hack in Tahoe Beta

Edited July 7 by deeveedee

[LockDown]

23 minutes ago, deeveedee said:

I have needed to use revpatch=sbvmm in my config.plist since Sonoma.  I thought everyone was using it for their hacks - no?

I am using that on a already installed OS but not during install. Never thought the issue i posted above will fix it

[MakAsrock]

9 minutes ago, LockDown said:

I am using that on a already installed OS but not during install. Never thought the issue i posted above will fix it

I am using that on any macOS since Ventura. I couldn't imagine that someone wouldn't know about this trick. 😜 

[LockDown]

45 minutes ago, MakAsrock said:

I couldn't imagine that someone wouldn't know about this trick. 😜 

Well. Im used to installing an OS on a running OS. And since my running OS already has the svbmm flag, i never thought i would be needing it on a USB install method 😀

Do you consider that as a trick? Dont think so 😜✌️

[MakAsrock]

1 hour ago, LockDown said:

Well. Im used to installing an OS on a running OS. And since my running OS already has the svbmm flag, i never thought i would be needing it on a USB install method 😀

Do you consider that as a trick? Dont think so 😜✌️

I use the same config during installation and subsequent use. 😉🫠

[Slice]

There is no new Clover-5174. It is ambition of MakAsrock.

The latest version is 5173.

[MakAsrock]

10 hours ago, Slice said:

There is no new Clover-5174. It is ambition of MakAsrock.

The latest version is 5173.

Not ambition, but a reissue.
GitHub won't let me use tag 5173 again.

Edited July 10 by MakAsrock

[LockDown]

@Slice

IgnoreNVRAMBoot still exist in clover?

[Slice]

15 hours ago, LockDown said:

@Slice

IgnoreNVRAMBoot still exist in clover?

Never exists

[LockDown]

There were a lot of posts about it way back then. Gave it a try but didnt work

[Zenith432]

Hi,

 

I'm trying to install Macos Sequoia 15.7.7 with Clover with no luck and am looking for help.

 

• CPU i3-10100
• H410 Chipset (Gigabyte H410M)
• Clover 5173
• config.plist attached
• Injected kexts latest FakeSMC, Lilu, WhateverGreen and RealtekRTL8111.kext.  Also a couple of Info.plist-only kexts to reassign pci-ids for Sata and Xhci to something Apple supports.
• Drivers ApfsDriverLoader, OpenRuntime and VBoxHFS.

This setup works well with Macos Catalina 10.15.8 (including Apple's update distributed in 2026)

 

The only ACPI patch is something to fix an undefined local variable error in _STA TZ10.  I also replace ssdt6 with one to describe USB ports correctly and to effectively do the same as the _STA RTC patch.  This patch chooses an RTC device called PNP0B00 instead of "Time and Alarm" Device called ACPI000E that macos doesn't like.

 

No booter, kernel or kext patches are used.  The OpenRuntime quirks are as in the config.plist distributed with Clover.

 

I created a USB flash drive installer for Macos15.7.7.  It works fine on a Mac Mini 2018, and also boots very well by itself with the above set up with Clover on PC.  It boots a lot faster than a Catalina 10.15.7 installer USB.

 

Then I go ahead and try to install Sequoia on an internal Sata SSD.  I've tried both "upgrade install" from Catalina AND a fresh install on an empty APFS partition with single empty volume.

I encounter the same problem both ways.

• The first stage of the install that copies files to the system "Data" volume works fine and then concludes with a message to reboot.  I reboot.
• The second stage of the installer goes on for a while, counting down time.  Then with about 8 or 9 minutes remaining it reboots.  There's no message and I can't tell if this is a normal reboot at the end of the 2nd stage or an erroneous spontaneous reboot.
• After the reboot the "installed" system is unusable.  Clover doesn't show any recognized boot loading option for it (i.e. doesn't find boot.efi or com.apple.Boot.plist in the allowed locations.)  Clover does show an option to boot the APFS partition from the "Preboot" volume, but this starts and hangs midway eventually rebooting.
• When I examine the file systems created from the installer USB with Terminal, it looks like the file system structure on the two System volumes (code+data) was only partially created and is incomplete which why the system is unbootable.

And ideas about this or where I can find logs to diagnose it?

 

Thanks.

 

config.plist

Edited 5 hours ago by Zenith432

[MaLd0n]

@Zenith432 try this https://limewire.com/d/1rH65#lr95NvdDat

Direct uploading to the forum isn't working; I had to use an external site.

[Max.1974]

On 7/18/2026 at 2:57 AM, LockDown said:

There were a lot of posts about it way back then. Gave it a try but didnt work

Hi my friend ! Maybe tou can try This command :

 

sudo nvram ResetNVRam=1 && sudo reboot 

 

 

[Zenith432]

1 hour ago, MaLd0n said:

@Zenith432 try this https://limewire.com/d/1rH65#lr95NvdDat

Direct uploading to the forum isn't working; I had to use an external site.

Thanks, but I get the exact same result.

Maybe 80GiB for the partition are not enough or the SSD is defective.  After the non-functioning install there are only about 10-11 GiB on the APFS container and the rest are free.

I keep the log window during the 1st stage install open, but it scrolls by too fast right before rebooting so I don't see what it says.  The part about "Syncing extracted files to disk" takes the most time.

🤷‍♂️