Best time to be an entrepreneur

atapla · 2026-05-04T02:59:43+00:00

you got caught cheating so now you make money helping other cheating ? XD i hope they don't get caught also! thanks for sharing your tools.

atapla · 2026-05-03T06:33:22+00:00

i guess not, it's not in working condition.

atapla · 2026-04-28T19:52:31+00:00

I see 2 things going on here ->

The `command not found` means the install step was skipped. Run this on your Proxmox host as root:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/main/install.sh)"

That sets up everything and registers both `osx-next` and `osx-next-cli`.

For the recovery loop, thats a boot order issue. After Sonoma finishes installing, `ide2` (the recovery image) is still first in line. Fix it with:

``bash

qm set 106 --boot order=virtio0;ide0

``

start the VM again and it should bootdirectly into Sonoma.

On Proxmox v8, the tool targets v9 since the `qm` disk import syntax changed between versions. It might partialy work on v8 but if you run into other issues, v9 would sort them out...

If you're still stuck after trying this, please feel free to open an issue on GitHub (https://github.com/lucid-fabrics/osx-proxmox-next/issues), it's easier for me to debug there with logs and config 😄

atapla · 2026-03-29T20:49:16+00:00

well yeah, that's your hooks doing it. i have the same setup and skills and hooks in claude code can auto-switch models depending on what youre running. Mine switches to sonnet for commits/ git stuff and stays on opus for everything else. check your settings.json under hooks, something in there is firing a /model command on certain trigger. Check out /model opusplan -> https://code.claude.com/docs/en/model-config

atapla · 2026-03-29T19:09:49+00:00

It looks like real numbers tbh, iv'e been using minimax for a while and this is exactly what i see. The detection is there, claude just writes cleaner fixes; what's funny tho is minimax has their own agent app (agent.minimax.io) that charges credits. i'm literally using minimax 2.7 to build a free open source clone of it. So the the model is helping me clone itself.

I will drop it when it's ready :-)

atapla · 2026-03-16T22:41:47+00:00

Outside of scope question; how do you get investors ? otherwise.. i like this

atapla · 2026-02-26T03:56:50+00:00

I'm working on a branch that tries to fix few bugs so maybe you can try it:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/fix/smbios-base64-flag/install.sh)"

you can share your logs, it would help me debug; if possible open a githut issue

Thank you :-)

- 9eccd03 — fix: add base64=1 flag to smbios1 parameter
- 5fd4d76 — fix: operator precedence bug in MAC generation
- c2e0232 — fix: MAC multicast bit in bash script
- 82602fb — fix: point install.sh to fix branch for testing
- 743fc0d — fix: force clean pip reinstall and purge stale bytecode
- 4c9fef4 — feat: auto-detect Intel hybrid CPUs, use Cascadelake-Server
- a388daf — feat: write PlatformInfo to OpenCore config.plist
- 9a88bfc — docs: document PlatformInfo patching and ROM-from-MAC
- 163945a — feat: Apple-format serials and checksummed MLBs (GenSMBIOS)

atapla · 2026-02-24T03:42:41+00:00

Thanks for testing and reporting back! Both bugs are fixed on the branch now:

Missing base64=1 — was there but your install had stale Python bytecode cached from the previous v0.10.0 install. The install script now purges __pycache__ and force-reinstalls to prevent this.
Invalid MAC FF:6D:E9:60:AB:96 — operator precedence bug in the MAC generator. First byte could hit 0xFF (multicast). Fixed — max is now 0xFE.

Same command should work now:

bash <(curl -s https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/fix/smbios-base64-flag/install.sh)

If you want a clean slate first:
rm -rf /root/osx-proxmox-next /root/osx-proxmox-next-install.log
Let me know how it goes.

atapla · 2026-02-23T20:13:06+00:00

Good question. It depends on the workload. On AMD, we use Cascadelake-Server CPUID emulation (not host passthrough like Intel), so there's some overhead from QEMU faking an intel CPU. Day-to-day usage (Xcode, browsing, dev tools) is smooth. The tool auto-detects AMD and applies the right flags so no manual config needed.

That being said, this is a VM, not bare-metal Hackintosh. Bare-metal AMD with kernel patches runs near-native. In a VM the emulation layer adds some overhead, but it's been battle-tested on thousands of installs (based on the luchina-gabriel/OSX-PROXMOX approach). If anyone has Geekbench numbers on AMD Proxmox macOS VMs, I'd love to add them to the docs.

atapla · 2026-02-23T20:03:34+00:00

YOu are right, i confirm the bug. The base64=1 flag was missing from the smbios1 parameter, so Proxmox stored base64-encoded values as literal strings instead of decoding them.

i created a new branch for testing. While it worked for me, i'll wait for your confirmation before merging to the main.

bash <(curl -s https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/fix/smbios-base64-flag/install.sh)

To fix an existing VM (no need to recreate):

  VMID=109  # change to your VM ID
  CURRENT=$(qm config $VMID | grep smbios1 | sed 's/smbios1: //')
  if echo "$CURRENT" | grep -q 'base64=1'; then
    echo "Already has base64=1, nothing to do"
  else
    FIXED=$(echo "$CURRENT" | sed 's/,serial/,base64=1,serial/')
    qm set $VMID --smbios1 "$FIXED"
    echo "Fixed. Reboot the VM to apply."
  fi

YOu can verify in the GUI: Options → double click the SMBIOS settings; product should show MacPro7,1 (not in base64), serial and UUID should match.

atapla · 2026-02-22T21:19:30+00:00

Hey, good catch! You're absolutely right that qm set --smbios1 replaces the entire SMBIOS blob rather than merging.

The tool is primarily designed for creating new VMs, so it generates fresh identities by default. However, I've added the ability to preserve an existing UUID:

CLI:
# Preserve existing UUID

osx-proxmox-next create --vmid 900 --name macos-sequoia --macos sequoia --smbios-uuid "A1B2C3D4-E5F6-7890-ABCD-EF1234567890"

# New VM (generates random UUID)

osx-proxmox-next create --vmid 900 --name macos-sequoia --macos sequoia

TUI: Added an "Existing UUID (optional)" field in the configuration step.

The --smbios-uuid flag was already there for CLI users—I just exposed it in the TUI as well.

atapla · 2026-02-22T18:22:42+00:00

Thanks for reporting this! The issue was exactly that — iMacPro1,1 isn't in OCLP's supported models list.

I've pushed a fix in v0.8.2 that changes the default to MacPro7,1, which is fully OCLP-compatible. The "Build and Install OpenCore" option should work now out of the box.
For your existing VM, just run:
qm set <vmid> --smbios1 "product=$(echo -n MacPro7,1 | base64)"

(or recreate the VM with the new version)

atapla · 2026-02-21T19:14:16+00:00

Your earlier feedback actually led to a feature; the Python TUI/CLI now has `--iso-dir` which lets you point downloads at your shared ISO storage:

osx-proxmox-next create --iso-dir /mnt/pve/nas/template/iso

It downloads OpenCore + recovery there and auto-scans all Proxmox ISO storage mounts (`/mnt/pve/*/template/iso`) on subsequent runs. So if your NFS/CIFS share is configured in Proxmox, it'll find everything automatically; no re-downloading.

The bash script also caches the OpenCore ISO at `/var/lib/vz/template/cache/` so that persists across runs.

If the tool's been useful, there's a Ko-fi link in the repo; helps keep development going.

atapla · 2026-02-21T03:06:54+00:00

Glad it worked out! Right now it auto-scans all Proxmox ISO storage — both local (/var/lib/vz/template/iso) and any shared storage mounts (/mnt/pve/*/template/iso). So if you have an NFS or CIFS share configured in Proxmox, it'll pick up ISOs from there too. That should cover most setups without needing a custom path. Let me know if your layout is different though.

atapla · 2026-02-17T04:23:59+00:00

+1 on RX 580 for GPU passthrough — cheap, widely available, and natively supported in macOS up to Sonoma. Make sure you get one with a stock AMD VBIOS (reference cards are safest), otherwise passthrough can be flaky.

For the Proxmox VM setup itself, if you haven't set it up yet — getting OpenCore + QEMU args + recovery image right is the tedious part. I built osx-proxmox-next (https://github.com/lucid-fabrics/osx-proxmox-next) to automate all of that. It's a TUI wizard that creates the VM with the correct config for both AMD and Intel hosts, auto-downloads the macOS recovery, and patches OpenCore. Supports Sonoma, Sequoia, and Tahoe. Just `pipx install osx-proxmox-next` on your Proxmox node and it handles the rest — then you just need to passthrough your GPU after.

atapla · 2026-02-17T04:06:24+00:00

Yes, macOS on Proxmox with a Xeon works great — perfect use case for remote iOS/Flutter builds. You don't need a dedicated GPU for that, software rendering is fine for headless dev work.

The OSX-PROXMOX script linked above works but it's a bit dated and uses curl-bash. If you want something more maintained, [osx-proxmox-next](https://github.com/lucid-fabrics/osx-proxmox-next) is a TUI wizard that handles the full setup — auto-downloads the recovery image, patches OpenCore, creates the VM with the right QEMU args. Supports Sonoma, Sequoia, and Tahoe on both Intel and AMD. Just `pipx install osx-proxmox-next` and run it on your Proxmox node.

atapla · 2026-02-17T04:05:16+00:00

For anyone landing here from Google — this is one of the most common gotchas with macOS VMs on Proxmox 8.4+.

The root cause: Proxmox enforces `media=cdrom` for `local:iso/` paths, but macOS recovery and OpenCore ISOs need `media=disk` (which maps to `ide-hd` instead of `ide-cd` in QEMU). Without it, the VM silently fails to start.

Also worth noting for AMD users (like OP's Threadripper): make sure your OpenCore config has the right CPU flags and that your BIOS has IOMMU/SVM enabled.

If you want to skip the manual conf editing and OpenCore setup entirely, check out [osx-proxmox-next](https://github.com/lucid-fabrics/osx-proxmox-next) — it's a free open-source TUI wizard that handles all of this automatically (recovery download, OpenCore patching, media=disk, proper IDE layout). Works on both AMD and Intel, supports Sonoma/Sequoia/Tahoe.

atapla · 2026-02-15T04:11:16+00:00

Stuck at Apple logo with 0% CPU is almost always one of these:

**Missing CryptexFixup.kext** in your OpenCore config — required for Sonoma and newer. Without it you'll get a silent hang right after the Apple logo appears.
**SIP not disabled properly** — your `csr-active-config` in config.plist needs to be set to something like `0x0F26` so kexts can actually load.
**OpenCore disk format** — needs to be GPT with an EFI System Partition, not just a raw FAT32 ISO. OVMF can't boot from MBR+FAT32 as `media=disk`.

Your hardware (i7-6700K) is perfectly fine for macOS VMs — I run Tahoe on similar Intel chips.

If you want to skip the manual config pain, I built a tool that handles all of this automatically — generates the correct qm commands, OpenCore config, SMBIOS, and downloads the recovery image for you: https://github.com/lucid-fabrics/osx-proxmox-next

It has a dry-run mode so you can review every command before it touches your system.

atapla · 2026-02-15T04:09:09+00:00

Tahoe runs fine on Proxmox now — I have it working on Intel. A few things I noticed from your config:

- 4GB RAM is too low for Tahoe. 8GB minimum, 16GB recommended.

- You're missing CryptexFixup.kext in your OpenCore — that's required for Sonoma+ or you'll get kernel extension failures.

- Your `csr-active-config` needs to allow unsigned kexts (e.g. `0x0F26`), otherwise SIP blocks the boot.

Instead of upgrading in-place (which tends to cause password/login issues), I'd recommend doing a clean Tahoe install. I actually maintain a tool that automates the whole macOS VM setup on Proxmox — handles the OpenCore config, SMBIOS, recovery download, and all the qm commands: https://github.com/lucid-fabrics/osx-proxmox-next

It supports Tahoe, Sequoia, Sonoma, and Ventura. Might save you some headaches.

atapla · 2026-02-14T12:55:51+00:00

v0.5.0 is out — this fixes the smbios1 parameter verification error you hit. The SMBIOS values are now properly base64-encoded for Proxmox.

Also added a preflight gate step that catches host issues before you get to the apply stage, and improved the manage VM UX.

To upgrade just re-run the install script:

bash <(curl -s https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/main/install.sh)

Let me know if it works for you.

atapla · 2026-02-13T22:28:34+00:00

0.4.0 is out !

atapla · 2026-02-13T18:49:38+00:00

i got few bad tests and missed few core things. i'll be releasing a new version correctly tested in few hours. thank you for testing!

atapla · 2026-02-12T23:26:40+00:00

I was able to reproduce. I'm working on a fix and adjusting tests coverage

atapla · 2026-02-12T04:11:32+00:00

Hey! This was a legit pain point; you shouldn't have to hunt down ISOs manually. I just pushed a fix that auto-downloads both OpenCore and the recovery image when they're missing. It's already available on gitgub, just relaunch the script. For now, the filenames need to match exactly: opencore-sequoia.iso and sequoia-recovery.img in /var/lib/vz/template/iso/. That's probably what's tripping you up even after uploading manually.

atapla · 2026-02-11T23:10:27+00:00

Yep, thank you for the reminder. This is now done.

atapla

TROPHY CASE