The Hackintosh Sample Page: What to Include and Why It Matters
A well-documented sample page saves time diagnosing boot failures. Learn the four sections: hardware, bootloader, ACPI, kexts. Includes a reusable template.
When you report a boot failure, the first thing an experienced Hackintosher asks for is a sample page. It's a structured snapshot of your build: motherboard model, CPU, GPU, bootloader version, essential kexts, ACPI patches, and SMBIOS choice. Without it, diagnosing a kernel panic or sleep issue turns into guesswork. Yet many legacy builders still describe their hardware in a few vague sentences, forcing helpers to drag out a dozen clarifying questions. A well-written sample page eliminates that back-and-forth and, more importantly, becomes your own reference when you return to the system months later.
<>
What a Sample Page Covers
A sample page documents every decision that affects macOS compatibility. It should be readable by both humans and machines — meaning you can paste it into a forum post or refer to it while editing your config.plist. Organise the information into four sections: hardware inventory, bootloader configuration, ACPI/SSDT summaries, and kexts with version numbers. Here's a breakdown of each section.
Hardware Inventory
- Motherboard: Manufacturer, model, BIOS version, and revision number (e.g., Gigabyte GA-Z77X-UD5H, BIOS F20).
- CPU: Exact model and stepping (e.g., Intel Core i7-3770K, Ivy Bridge, stepping 9).
- GPU: Vendor, model, VRAM size, and interface (e.g., NVIDIA GeForce GTX 660, 2 GB GDDR5, PCIe 3.0).
- RAM: Capacity, speed, and number of sticks (e.g., 16 GB (2×8 GB) DDR3-1600).
- Storage: Type (SATA SSD, HDD, NVMe), model, and firmware version. For NVMe on legacy boards, note the PCIe adapter used. Our Legacy Hackintosh Storage: SATA, IDE, and NVMe Compatibility Guide covers the quirks of older chipsets.
- Network: Ethernet controller (e.g., Realtek RTL8111F) and Wi-Fi/Bluetooth module if applicable.
- Audio: Codec (e.g., Realtek ALC898) and layout ID(s) tested.
Bootloader Configuration
List the bootloader you're using (Clover, OpenCore legacy, or even Chameleon for very old builds) and its exact version. For Clover, also record the installed drivers (e.g., ApfsDriverLoader, HFSPlus.efi, NvmExpressDxe.efi) and any custom boot arguments. Common flags for diagnostics are -v (verbose), debug=0x100 (keeps panic log on screen), and keepsyms=1 (symbolicates kernel panics).
If you use OpenCore, include the config.plist version and a list of enabled kexts in the Kernel -> Add section along with their bundle identifiers. Don't paste the entire plist — a hand-picked summary is enough.
<>
ACPI and SSDT Summaries
Document which ACPI tables you've added or patched. For example, a typical Ivy Bridge build might include an SSDT for CPU power management (generated by ssdtPRGen.sh) and a renamed _DSM to _XDSM patch for the GPU. Mention the origin of each SSDT — whether it was extracted from a real Mac, created with a generator, or hand-coded. If you have a screenshot of IORegistryExplorer showing the patched ACPI namespace, reference it. The article How to Use IORegistryExplorer for Hackintosh Diagnostics explains how to capture that information reliably.
Also note any binary renames applied in your bootloader (e.g., EC0 to EC, SAT0 to SATA). These are often the difference between a laptop that sleeps and one that kernel panics after lid close.
Verified Kexts and Versions
Create a table of every kext you inject, with the version number and the source (e.g., RehabMan's repository, acidanthera's GitHub, self-compiled). Use a simple format:
| Kext | Version | Purpose |
|---|---|---|
| Lilu.kext | 1.4.0 | Kernel patcher foundation |
| WhateverGreen.kext | 1.3.8 | GPU fixes and connectors |
| AppleALC.kext | 1.5.0 | Audio injection (layout-id 1) |
| RealtekRTL8111.kext | 2.2.2 | Ethernet driver |
| USBInjectAll.kext | 0.7.1 | USB port mapping |
If you're relying on a patched AppleHDA (not AppleALC), note the codec dump and the patch-commit reference. This level of detail helps you or anyone else rebuild the exact same setup on a different drive.
Creating a Template You Can Reuse
Instead of writing a sample page from scratch each time, keep a plain-text template in your EFI partition's root folder. Name it sample_page.txt. Fill in the blanks after you finish a new build or after a major OS update. When you archive the entire EFI folder, this file becomes the key to reconstructing the system later. For a full workflow, see How to Archive a Legacy Hackintosh Build So You Can Rebuild It Years Later.
A good template should include placeholders for every variable listed above, plus a section for known quirks (e.g., "Audio only works after a warm reboot" or "HDMI audio requires a custom SSDT"). Over time, you'll accumulate a library of sample pages for each of your machines — invaluable when you pull a retired board out of storage and can't remember which SMBIOS you used.
Risks and Precautions
Creating a sample page won't modify your system, but it does require you to collect information from running configurators and system profilers. Before you launch any tool that reads hardware registers, ensure you have a full backup of your EFI partition and your current macOS installation. A mis-click in a configurator could corrupt your bootloader settings. Save the sample page as a separate file — never edit your config.plist manually while the sample page is open, unless you're certain of the changes.
If you post your sample page publicly, be sure to redact any serial numbers or ROM values that could be used to activate iMessage or FaceTime. Including a valid SMBIOS serial in a public forum is a common mistake that can lead to hardware blacklisting by Apple's servers. Strip the serial and keep only the product name (e.g., iMac13,2).
Putting the Sample Page to Work
After you've written your sample page, use it as a checklist before every macOS upgrade. Compare the kext versions against the latest available for your target OS. If you're moving from Mavericks to Yosemite, for example, update Lilu and WhateverGreen before attempting the install. The sample page will tell you exactly which kexts need to change and which can stay.
When you encounter a boot loop after a minor update, return to the sample page and verify that no kext has been silently disabled by the bootloader. This structured approach cuts troubleshooting time by more than half. The next time someone asks "What is your build?" you can reply with a single link — your sample page — and get straight to the problem.
