Downloading AMD DMG 2: What It Is and How to Verify Legacy Hackintosh Images

What an AMD DMG 2 Hackintosh image contains, how to verify its integrity, and the specific bootloader settings needed for AMD CPU compatibility.

If you have spent any time in Hackintosh communities targeting older macOS versions, you have likely encountered the cryptic label "AMD DMG 2" attached to certain pre-built disk images. Unlike the more common Intel-oriented DMG files that circulate for Haswell or Skylake builds, the AMD variant addresses a fundamentally different hardware family — one that requires a custom kernel, patched system libraries, and often a separate set of boot arguments just to reach the installer. This article dissects what an AMD DMG 2 actually contains, how it differs from a standard vanilla image, and the critical verification steps you must perform before deploying it on any production drive.

Origins of the AMD DMG 2 Label

The term "AMD DMG 2" first appeared in forums around macOS Sierra 10.12.3 and gained traction during High Sierra 10.13.x. It refers to a second-generation packaging method for AMD-compatible macOS installers. Earlier AMD DMG files (sometimes called "rev 1") were simple wrappers around a vanilla macOS installer plus a kernel patch applied at boot via a custom bootloader configuration. The rev 2 format introduced a modified BaseSystem.dmg with pre-integrated AMD kernel extensions and patched IOKit families, making the image bootable on AMD hardware without requiring the user to manually replace kernel files after installation.

The "2" does not indicate a specific macOS version. It is a community convention that signals the image has been rebuilt from the ground up for AMD CPUs, typically including:

  • A pre-patched kernel (often based on Bronya’s or Sinetek’s work for older AMD architectures)
  • Modified System.kext and IOPCIFamily.kext to handle non-Intel CPUID handling
  • Adjusted boot.efi to support AMD CPU topology detection
  • Custom ACPI tables (SSDTs) that disable unsupported CPU power management features

These images are almost exclusively distributed by small teams or individual maintainers who test on specific AMD platforms — typically AM3+ (FX-series) or early FM2+ (A-series APUs). Compatibility with Ryzen is extremely limited and generally not covered by the AMD DMG 2 label.

What the DMG Actually Contains

When you mount an AMD DMG 2, you will see a folder structure that differs from a standard macOS installer. Instead of a single Install macOS.app, the image usually contains:

  • BaseSystem.dmg — the actual recovery system, pre-patched
  • KernelPatches folder — a set of precompiled kernel binaries for different AMD CPU generations (Bulldozer, Piledriver, Steamroller, Jaguar)
  • Extra folder — bootloader configuration files (typically for Clover or Chameleon) with AMD-specific boot arguments such as amd_has_avx=1, npci=0x2000, and cpus=1 for troubleshooting
  • PostInstall folder — kexts and scripts that must be applied after the first boot, including patched AppleHDA, Realtek RTL8111 Ethernet drivers (see our earlier guide on Fixing Realtek RTL8111 Ethernet on Hackintosh High Sierra for chip revision details), and AMD GPU framebuffer patches

A common mistake is treating the DMG as a direct write-to-USB image. It is not. You must restore the BaseSystem.dmg to a partition or USB drive using Disk Utility (or asr on a real Mac), then copy the bootloader files manually. The AMD DMG 2 is a distribution format, not a bootable disk image.

Verification Before Deployment

Because these images circulate through unofficial channels, verification is not optional. Even a single corrupted kernel patch can cause a panic at IOConsoleUsers: gIOScreenLockState 3 or a permanent boot loop. Follow this checklist before writing the image to any drive that contains data you care about:

  1. Checksum match — The distributor should provide an MD5 or SHA-1 hash. Compare it exactly. If the hash is missing, treat the image as untrusted.
  2. Mount and inspect the BaseSystem.dmg — Inside it, navigate to /System/Library/Kernels/ and verify that the kernel file size matches the expected size for the macOS version. A kernel that is 2–4 MB larger than usual may indicate a debug build or a corrupted binary.
  3. Check boot.efi version — Run strings boot.efi | grep -i "10.13" (adjust for your target OS). If the embedded version string does not match the macOS version you intend to install, the image may have been assembled from mismatched components.
  4. Test in a virtual machine first — If possible, mount the DMG inside a VMware or QEMU guest running macOS (if you have a licensed copy) and verify that the installer launches. This step alone catches 80% of corrupted images.

Do not skip the hash verification. A corrupted kernel patch can silently corrupt your filesystem during installation. Always back up your existing data before attempting any installation from a community DMG.

Bootloader Configuration Specific to AMD DMG 2

AMD Hackintosh builds rely heavily on bootloader flags that are rarely needed on Intel systems. If you use Clover (the most common bootloader for these images), the config.plist must include at least the following under Boot and KernelAndKextPatches:

Key Value Purpose
KernelPm True Enables kernel power management patches for AMD CPU idle states
AppleIntelCPUPM False Disables Intel-specific CPU power management assertions
KernelLapic True Fixes Local APIC panic on AMD Bulldozer and later
Boot: npci 0x2000 Prevents PCI configuration hang on certain AMD chipsets (SB950, SB850)

If the DMG includes a pre-built config.plist, compare it against this table. Missing any of these entries will likely result in a boot failure. The AMD DMG 2 maintainers often target a single chipset, so if your motherboard uses a different southbridge (e.g., an AM4 board with a B350 chipset), you will need to adjust the ACPI patches yourself. For X79/X99 users who might be experimenting with AMD GPUs, our guide on Fixing ACPI Panics on X79/X99 Hackintosh for macOS High Sierra covers the SSDT modifications that also apply to AMD systems with NVIDIA GPUs.

Risks Specific to AMD DMG 2 Images

Beyond the usual risks of any Hackintosh DMG (malware, data loss, broken updates), AMD-specific images carry additional dangers:

  • Kernel mismatch — The patched kernel in the DMG may be compiled for a specific macOS build number (e.g., 17G65). Installing on a different build (17G66) can cause random panics that are difficult to diagnose because the panic log points to generic kernel routines.
  • CPUID spoofing side effects — The kernel patch that fakes the CPUID to match an Intel processor can break FaceTime, iMessage, and iCloud sync because Apple’s server-side checks detect the mismatch. Expect these services to be non-functional unless you also patch the system’s SMBIOS to match a real Mac model that used an AMD CPU — which does not exist. There is no clean workaround.
  • Sleep corruption — AMD Hackintoshes rarely achieve stable sleep. The ACPI tables provided in the DMG often disable sleep entirely by setting SleepState to zero. Do not attempt to enable sleep manually unless you have verified the SSDT for your exact motherboard model.

These limitations are not bugs in the DMG; they are inherent constraints of running macOS on unsupported CPU architectures. The AMD DMG 2 format is a tool for experimentation and legacy software preservation, not for daily-driver reliability.

Final Practical Step

If you decide to proceed with an AMD DMG 2 image, create a dedicated test partition on a spare drive — never on your main system disk. After writing the BaseSystem.dmg to the partition, boot once with the -v flag and watch the kernel output. If you see AMD: Unknown CPU family 0x15 or Still waiting for root device, you are likely dealing with an image compiled for a different AMD microarchitecture than your CPU. In that case, the image is not salvageable without recompiling the kernel patches from source — a process that requires Xcode and a working macOS installation on Intel hardware. Keep a copy of the original DMG’s hash and notes about your hardware revision, so that if the image later becomes unavailable, you can reproduce the setup from known-good components.