If you need to install this version of Mac OS, there’s a lot of wrong and bad information about this topic being generated by AI and Google links. The best and working method is shown in this YT. This approach creates a Thumb Drive that books into the same screen as MacOS Recovery and you select the reinstall MacOS option.
Have tested this approach for both Lion and Mountain Lion. Also, this does not work with Sierra, which has the new createinstallmedia structure:
Merging an Empty HFS Partition Into Active Data on macOS 10.8.5 Mountain Lion With CoreStorage
Reclaiming space stuck on the wrong side of the partition table, with an undocumented diskutil command
diskutil resizeVolume / mergePartitions can’t merge them — filesystem resize only grows forward into trailing free space, never backward. CoreStorage sidesteps this because it pools partitions logically instead of growing them in place. The undocumented diskutil coreStorage addDisk command works for this on 10.8.5 — but resizeVolume‘s “fill everything” shortcut (0) does not work on this OS version — you have to pass an explicit byte count. Full working sequence and output below.The setup: a disk with two partitions —
disk1s2 (90.8GB) was empty. disk1s3 (658.8GB) held all the active data. The goal: reclaim the 90.8GB and end up with one combined ~750GB volume, without wiping or cloning the data partition.
The obvious approach — delete the empty partition, then grow the data partition into the freed space — doesn’t work here, and it’s worth understanding why, because the failure isn’t a bug, it’s how partition resizing is fundamentally designed to work.
diskutil resizeVolume and diskutil mergePartitions both grow a partition by extending its trailing edge — moving the boundary that follows the partition further out on the disk, into space that comes after it. Neither can move a partition’s starting position. Doing that would mean physically relocating every block of an existing filesystem to a new starting offset on disk — not a metadata edit, but a full block-level move — and that’s simply not what these tools do.
That’s exactly the situation here: the empty space (90.8GB) sits before the data partition, not after it. Deleting the empty partition just leaves dead space that the data partition has no native way to absorb. This is a well-documented limitation reported independently by multiple users hitting the same “partitions in the wrong order” wall — see the Ask Different thread on this exact problem.
mergePartitions doesn’t get around this either: its own man page says whichever partition you list first keeps its data and gets grown — but “grown” still means grown forward. If the partition with your data is physically the second one, this hits the same wall dressed up in a different command.
CoreStorage is Apple’s logical volume manager (it’s what powers Fusion Drive and FileVault 2 under the hood). Instead of a single filesystem occupying one contiguous span of a disk, a CoreStorage Logical Volume Group (LVG) pools one or more Physical Volumes (PVs) — which can be any partitions, anywhere on the disk — into one logical address space. A Logical Volume (LV) inside that group is addressed logically, not by physical position. Because of that, two partitions can be pooled together into one usable volume regardless of which one is physically first on the disk.
This is why the fix here isn’t a resize at all — it’s converting the data partition into a CoreStorage volume, then adding the empty partition into the same pool.
Starting layout:
Data is preserved — this is a live, in-place conversion, not a wipe. disk1s3 becomes a CoreStorage Physical Volume, wrapped in a new Logical Volume Group, with the original filesystem now exposed as a Logical Volume at disk2.
addDisk is undocumented — it doesn’t appear in Apple’s diskutil man page and isn’t officially supported. Reports of its reliability across different 10.8.x point releases are genuinely mixed — broken on 10.8.2, reportedly fixed on 10.8.3, then reported broken again by other users afterward. Test on a disposable disk before trusting it with real data. It worked cleanly here on 10.8.5.After this step, diskutil list confirms both partitions are now part of the same CoreStorage group:
And diskutil coreStorage list shows a single LVG with both PVs and ~90.6GB of free space sitting unused inside the pool:
The space is pooled, but the Logical Volume itself hasn’t grown yet — that’s the last step.
The diskutil coreStorage resizeVolume man page (at least as documented on more recent macOS versions) says you can pass 0 as a shorthand for “grow to fill all remaining space in the LVG.” This does not work on 10.8.5:
The workaround is to calculate and pass an explicit byte count instead:
(Deliberately left slightly under the LVG’s total 749,678,182,400 B to leave headroom for CoreStorage’s own metadata — don’t try to claim every last byte.)
resizeVolume, mergePartitions) can’t reach it — this isn’t a bug, it’s inherent to how in-place filesystem growth works.addDisk can pool partitions regardless of their physical order, because it’s a logical layer, not a physical resize. But it’s undocumented and unsupported — back up first, and ideally rehearse the whole sequence on a throwaway test disk before running it against real data.resizeVolume‘s 0-for-“everything” shortcut, as documented on later macOS versions, does not exist on 10.8.5. Use currentSize + freeSpace in bytes instead, with the b suffix, and leave a small margin under the LVG total.The complete, unedited terminal transcript (including all diskutil list output at each stage) is available as a PDF here: resize-partition.pdf
Places stayed
DNS over HTTPS via Cloudflare Tunnel + AdGuard Home
Token-authenticated DoH on a Raspberry Pi without port forwarding
Cloudflare Tunnel replaces Caddy as the ingress layer. The tunnel makes an outbound-only connection from the Pi to Cloudflare’s edge — no port forwarding is required. Token enforcement and path rewriting happen at the Cloudflare edge before traffic reaches the Pi.
iOS / macOS client ↓ https://DoHserver-hostname/secret-token/dns-query Cloudflare edge WAF Custom Rule: block if URI does not contain token (returns 404) Transform Rule: rewrite /secret-token/dns-query → /dns-query ↓ /dns-query + CF-Connecting-IP header Cloudflare Tunnel (outbound from Pi, no port forwarding needed) ↓ https://localhost:443 AdGuard Home (DoH port 443, DoT port 853, trusted_proxies reads CF-Connecting-IP) ↓ Upstream resolvers
Stop AGH before editing — it overwrites changes made while running:
Ensure the following sections are set correctly. The trusted_proxies list is Cloudflare’s published IP ranges — AGH reads CF-Connecting-IP headers only from these addresses:
https://www.cloudflare.com/ips/ periodically for updates.Install via the official Cloudflare apt repository for automatic updates:
The credentials file lands in ~/.cloudflared/<UUID>.json. Copy both files to root’s home since the service runs as root:
Paste, replacing <TUNNEL-UUID> with your actual UUID:
originServerName tells cloudflared to validate AGH’s TLS certificate against the hostname rather than localhost. The catch-all http_status:404 rejects any request that doesn’t match the hostname rule.Delete any existing A or AAAA record for DoHserver-hostname in the Cloudflare DNS dashboard first, then:
In the Cloudflare dashboard: Security → WAF → Custom Rules → Create rule
Rule expression (paste into the expression editor):
http.host with the port number included — there is a bug in the Cloudflare UI that rejects http.hostname. Since http.host includes the port, the value must be DoHserver-hostname:443 not just DoHserver-hostname.In the Cloudflare dashboard: Rules → Transform Rules → URL Rewrite → Create rule
/your-secret-token//dns-queryThis rewrites /your-secret-token/dns-query → /dns-query before forwarding to AGH via the tunnel. The WAF rule runs first, so only requests containing the token reach this rewrite.
?dns= base64 GET requests for testing — AGH does not support this format. Use dnslookup which uses POST with binary wireformat as Apple devices do.Save as dns-settings.mobileconfig and install by airdropping to iOS, opening in Safari on iOS, or double-clicking on macOS. Generate a fresh UUID with uuidgen.
ServerAddresses needed — the device resolves DoHserver-hostname via normal DNS before the profile activates.Two changes required — both in the Cloudflare dashboard, nothing on the Pi:
not contains value to new tokenstarts with value to new tokenServerURL and reinstall on devicesCheck https://www.cloudflare.com/ips/ periodically and update trusted_proxies in AdGuardHome.yaml if ranges change. Stop AGH before editing.
Generate a bcrypt hash using single quotes to prevent shell expansion of special characters:
Caddy is installed but disabled. To revert:
Here is the guide:
Installing and Configuring Caddy on a Raspberry Pi
DoH with Token Authentication via Caddy + AdGuard Home
This guide sets up Caddy as a reverse proxy in front of AdGuard Home, providing DNS over HTTPS (DoH) with token-based authentication and automatic Let’s Encrypt certificate management.
The standard Caddy apt package does not include the Cloudflare DNS plugin required to generate and update SSL certificates via DNS-01 challenge using the Cloudflare API. A custom build is required using xcaddy, which needs the Go programming environment 1.21 or later.
linux-armv6l instead of linux-arm64 for Pi 3 or earlier.Go and xcaddy are only needed to build Caddy — once the binary is in place they can be removed:
AdGuard Home must move off HTTPS port 443 so Caddy can own it. Change only the HTTPS port — DoT on 853 is completely unaffected.
Go to Settings → Encryption Settings and change the HTTPS port from 443 to 8443. Save and let AGH restart. Note: to get to the Web UI again after AGH restarts, append :8443 to the URL.
Stop AGH before editing the yaml — AGH overwrites changes made while running:
Ensure these settings are present (add if missing, do not duplicate):
allow_unencrypted_doh: true is safe here because port 3000 is bound to localhost only — Caddy is the only process that can reach it.Generate a secret token. Use all or a subset of the output as your secret token:
Create/Edit the Caddy configuration file:
Paste the following, replacing your-secret-token with the string generated above:
auto_https disable_redirects prevents Caddy from trying to bind to port 80, which AGH already owns.handle block and reload Caddy. Also update ServerURL in your iOS/macOS profile.Paste:
Create a scoped API token in Cloudflare: My Profile → API Tokens → Create Token with Zone/Zone/Read and Zone/DNS/Edit permissions scoped to your zone.
Now insert that token into the Caddy environment file:
Paste:
Secure the file:
Caddy will immediately request a Let’s Encrypt certificate via DNS-01 challenge using the Cloudflare API. The request and result is visible in the log:
Look for certificate obtained successfully. This usually takes 30–60 seconds. The DNS-01 challenge creates and deletes a TXT record in Cloudflare automatically — it may happen too fast to see in the Cloudflare dashboard.
If not already done, create a firewall rule on your router allowing inbound TCP port 443 to your Caddy+AGH server’s IPv6 address. If you want to restrict to specific source prefixes you can scope the rule accordingly.
Install the dnslookup utility from Github for proper DoH testing (uses POST with binary wireformat, which is what Apple devices use):
Test the setup end-to-end:
curl with ?dns= base64 GET requests for testing — AGH does not support this format. dnslookup uses POST with binary wireformat which is what AGH and Apple devices use.To use the DoH server on Apple devices, a mobile configuration profile is needed. Save the following as dns-settings.mobileconfig and install by airdropping to an iOS device, opening in Safari on iOS, or double-clicking on macOS. Replace addresses with current values from dig yourserver-hostname A and dig yourserver-hostname AAAA. Generate a fresh UUID with uuidgen.
Caddy renews Let’s Encrypt certificates automatically. No cron jobs or manual steps needed. Certificates are stored in /var/lib/caddy/.local/share/caddy/.
Go only needs to be reinstalled when updating Caddy:
Update both occurrences in the Caddyfile handle block, reload Caddy, and update ServerURL in your iOS/macOS profile: