CloverBootloader: a UEFI and legacy boot manager for macOS, Windows and Linux

The firmware problem CloverBootloader addresses

A machine with UEFI firmware and a machine with a legacy BIOS do not hand control to an operating system the same way. CloverBootloader exists to sit in that gap and present one boot menu regardless of which firmware you have. The README states the project boots macOS, Windows and Linux in UEFI, or legacy mode, on a Mac or PC with UEFI or BIOS firmware. That sentence covers four combinations, and covering all four is the reason the project is larger than a typical boot menu.

The audience is narrow but real. It is people running more than one of those three systems on the same disk, and people whose firmware does not offer a usable menu of its own. The README also notes Clover can boot using UEFI firmware directly, or through CloverEFI, its own UEFI firmware emulation. That second path is what makes legacy BIOS machines viable: the firmware has no UEFI to hand off to, so Clover supplies one. If your machine boots one operating system and its own firmware menu already works, Clover is overhead you do not need.

How Clover is put together: EDK2, packages and drivers

The repository layout answers most of the architecture question. The README credits the main base to EDK2, and the top level carries the EDK2 package directories you would expect: MdePkg, MdeModulePkg, UefiCpuPkg, NetworkPkg, ShellPkg, ArmPkg and others. Clover's own code sits alongside them in CloverEFI, CloverApp, Drivers, FileSystems, Library, Protocols and Include. The build description files Clover.dsc, Clover.fdf and CloverPkg.dec are what a UEFI build consumes.

Two details in that listing are worth pointing out. There is a BootHFS directory, which is the piece that lets the bootloader read an HFS volume, and there is an Ext4Pkg directory for ext4. Those are not incidental: a boot menu that cannot read the volume holding the kernel cannot boot it. There is also an OpenCorePkg entry among the top-level items, which is a submodule rather than Clover's own code, and a MemoryFix directory whose purpose the README does not explain.

The GUI is not a separate program. The README describes a customizable interface with themes, icons, fonts, background images, animations and mouse pointers, plus a theme manager and a theme repository at CloverThemes. Native screen resolution is used, and Page Up or Page Down changes the GUI resolution. The function keys are the operational surface: F2 saves preboot.log, F4 saves the original OEM ACPI tables into /EFI/CLOVER/ACPI/origin, F5 tests DSDT patching, F6 saves graphics firmware into /EFI/CLOVER/misc, F11 resets NVRAM. Those keys are how you get diagnostics off a machine that will not boot, and they are the most concretely documented part of the project.

Installing CloverBootloader and booting from it the first time

The README does not give a step-by-step install procedure. It points to the Clover-Wiki and the Clover-Documentation repository, and the repository root carries build notes as separate files: Build_Clover_Tahoe.md, Build_Clover_in_Sequoia.txt, buildExtras.sh and build_gcc16.sh. Treat those as the starting point rather than any command invented here.

What the README does document is the layout Clover expects once it is running. ACPI originals go to /EFI/CLOVER/ACPI/origin and graphics firmware to /EFI/CLOVER/misc, so the ESP must contain an EFI/CLOVER directory tree. A minimal mental model of that tree looks like this:

/EFI/CLOVER/
  ACPI/origin
  misc

The practical first use is to boot the machine and press F2. The README says F2 saves preboot.log from the GUI. That file is the record of what the bootloader saw, and it is the artifact you attach when asking for help on the support forums the README lists.

If a menu entry is missing, F3 shows hidden entries. If the machine will not boot at all, F11 resets NVRAM, which is the documented escape hatch for a boot entry that has gone bad. The README also states you can create a Clover boot entry in NVRAM with a tool from the GUI, and launch an EFI command shell from the GUI. Those two are the recovery tools when the menu itself is the problem.

One caution that follows from the repository listing rather than the README: there is a SignTool directory and a Certificates directory, but the README does not describe a signing or verification step for what you build. Do not assume the output is signed.

Where CloverBootloader is the wrong choice

The README does not document rollback. If you write a Clover entry into NVRAM and it misbehaves, the documented recovery is F11 to reset NVRAM, and that is a blunt instrument: it clears the variable store rather than undoing one change. On a machine whose firmware depends on NVRAM variables for other settings, that is a real risk, and the project's own documentation does not offer a finer-grained alternative.

The second limitation is build cost. Clover is C, built from EDK2 packages, with GCC and Xcode and Visual Studio project files in the tree (CloverVC.sln, CloverVC.vcxproj, the Xcode directory, Nasm.inc for the assembler). There is a binutils-2.46.1.tar.xz at the top level, which tells you the toolchain itself can be part of the work. A user who wants a boot menu and nothing else will spend more time on the build than on the boot.

The third is the documentation split. The README is a feature list and a credits list. Installation, configuration keys and troubleshooting live in the wiki and in Clover-Documentation, and there is a separate Clover History page. Nothing in the README tells you which release tag corresponds to which configuration format. If you are not prepared to read outside the repository, Clover is the wrong tool.

Clover compared with OpenCore

The comparison people actually search for is Clover against OpenCore, and the repository itself hints at the relationship: OpenCorePkg appears as a top-level entry, meaning Clover pulls in OpenCore's package as a submodule. They are not independent projects ignoring each other.

The difference in approach is where the boot logic lives. Clover carries a full GUI with themes, icons, fonts, animations and mouse pointers, and exposes a large set of function keys for diagnostics and on-the-fly testing (F5 tests DSDT patching, F7 tests HDA output, F9 switches screen resolution). That is a boot environment. OpenCore's design, as its own project documents it, is a configuration-driven bootloader with a plist describing the machine, and it does not ship a themed menu of this kind.

A second difference is legacy support. Clover's README states it boots in legacy mode through CloverEFI UEFI firmware emulation. If you have a BIOS-only machine, that is the feature that decides the question. If your machine is UEFI and your configuration is settled, the Clover GUI is surface area you are maintaining for no benefit.

Neither project is a package. Both are built and placed on an EFI system partition by hand, and both require you to know your firmware mode before you start.

Maintenance, releases and the BSD-2-Clause licence

The last push to the default branch was on 2026-09-02, and the most recent release is 5175, dated 2026-08-31. The two before it are 5174 (2026-08-10) and 5173 (2026-07-03). The release cadence in that window is roughly one release a month, and the repository is not archived.

Upgrade cost is the interesting part. Releases are numbered rather than versioned semantically, so 5173 to 5174 to 5175 tells you ordering and nothing about compatibility. The README does not describe an upgrade procedure, a configuration migration path, or a compatibility guarantee between releases. Anyone running Clover in a multi-boot setup should read the Clover Change Explanations thread the README links before moving to a new tag, because that is where the project says recent changes are described in detail.

Licensing is BSD-2-Clause, per the badge and the LICENSE file at the repository root. That is a permissive licence, and it is worth noting that Clover incorporates code from other projects: the README credits Intel, Apple, Oracle, Chameleon, rEFIt and Xom, and nanosvg, and states Clover is based on Chameleon, rEFIt, XNU and VirtualBox, with EDK2 as the main base. Redistribution therefore involves more than one set of terms, and the README does not enumerate them. Check the individual package directories before shipping a build; this is not legal advice.

Editorial conclusion

Clover suits people who need one boot menu across macOS, Windows and Linux on either UEFI or legacy BIOS firmware, and who are willing to build from source or work from the Clover-Wiki. It is the wrong tool if you want a package manager, a signed release binary, or a documented rollback path, because the README does not describe one. Before committing, verify three things on your own hardware: that your firmware mode is what you think it is, that the release tag you downloaded matches the build instructions you are following, and that you can reach the Clover-Wiki page for the configuration keys you intend to change.

Frequently asked questions

Official sources

1. CloverHackyColor/CloverBootloader on GitHub
2. Issues
3. License: BSD-2-Clause
4. README
5. Releases