@matteoiacca, what do you think the workflow should be here? how should this get implemented? and what error handling should we implement?

@gandolf243!

Telling the user upfront that the Mac will restart multiple times is definitely an improvement. Before we dive deep into coding the daemon scripts, here are a few technical hurdles we should plan for:

1. Network availability in early boot:
   • If the patcher needs to download anything online (KDKs, missing payload assets, or packages), a LaunchDaemon running before loginwindow won't have Wi-Fi connected yet (network connections and Keychain credentials typically initialize at/after login). The package would need to be 100% offline/self-contained.
2. Reducing reboot cycles:
   • Having 3 reboots is still quite heavy. Ideally, we should see if we can do the revert + stage new patches in a single boot cycle, or at most 1–2 reboots.
3. Rollback & Failsafe:
   • We need a reliable fallback so that if patching fails halfway through (e.g. disk space, SIP/SSV verification), the daemon doesn't loop or leave the system unbootable without recovery.
4. Quick note on requirements.txt:
   • The comment removed in the initial commit documents why --no-binary=pyinstaller needs PYINSTALLER_COMPILE_BOOTLOADER for 10.13 High Sierra hosts. We should probably keep that comment intact and keep this branch focused strictly on the auto-patcher logic.

Let's break this down into smaller steps: first, test the CLI commands needed for an unattended unpatch/repatch flow, then build the daemon wrapper around it once the core commands are bulletproof.

• Starting Patch Process

• Determining Required Patch set for Darwin 25
  Bypassing SIP validation - host detected as VMware VM with allow_vmware_root_patching enabled (test-only, see host_is_vmware_vm)
  This is designed only for advanced developers to test the syntax of the root patching process.
  Bypassing AMFI validation - host detected as VMware VM with allow_vmware_root_patching enabled (test-only, see host_is_vmware_vm)

• Verifying whether Root Patching possible

• Patcher is capable of patching

• Unprivileged hdiutil attach failed, retrying with administrator privileges

• Failed to mount Universal-Binaries.dmg
  Subprocess failed.
  Command: ['/usr/bin/hdiutil', 'attach', '-noverify', '/Library/Application Support/albert-mueller/OpenCore-Patcher-T2/OpenCore-Patcher-T2.app/Contents/Frameworks/Universal-Binaries.dmg', '-mountpoint', '/var/folders/9g/6ywz29657hdgf2p3p0nkysth0000gn/T/tmpuy312q33/payloads/Universal-Binaries', '-nobrowse', '-shadow', '/var/folders/9g/6ywz29657hdgf2p3p0nkysth0000gn/T/tmpuy312q33/payloads/Universal-Binaries_overlay', '-stdinpass']
  Return Code: 1
  Standard Output:
  hdiutil: attach failed - Permission denied
  Standard Error:
  Elevated hdiutil attach did not mount the image

• Critical resources missing, cannot continue with patching!!!

Testing in a virtual machine. After returning to the menu and back to the root patching, it succeeds. However, this is what I tested from main. And did so inside a virtual machine.
@gandolf243 @matteoiacca

@gandolf243 @matteoiacca Also, it is a good idea to make this function opt in or opt out so if the user faces a corrupted patch, it can't just trigger a kernel panic and the patcher to render the machine unbootable indefinately on its own.

• Starting Patch Process
• Determining Required Patch set for Darwin 25
  Bypassing SIP validation - host detected as VMware VM with allow_vmware_root_patching enabled (test-only, see host_is_vmware_vm)
  This is designed only for advanced developers to test the syntax of the root patching process.
  Bypassing AMFI validation - host detected as VMware VM with allow_vmware_root_patching enabled (test-only, see host_is_vmware_vm)
• Verifying whether Root Patching possible
• Patcher is capable of patching
• Unprivileged hdiutil attach failed, retrying with administrator privileges
• Failed to mount Universal-Binaries.dmg
  Subprocess failed.
  Command: ['/usr/bin/hdiutil', 'attach', '-noverify', '/Library/Application Support/albert-mueller/OpenCore-Patcher-T2/OpenCore-Patcher-T2.app/Contents/Frameworks/Universal-Binaries.dmg', '-mountpoint', '/var/folders/9g/6ywz29657hdgf2p3p0nkysth0000gn/T/tmpuy312q33/payloads/Universal-Binaries', '-nobrowse', '-shadow', '/var/folders/9g/6ywz29657hdgf2p3p0nkysth0000gn/T/tmpuy312q33/payloads/Universal-Binaries_overlay', '-stdinpass']
  Return Code: 1
  Standard Output:
  hdiutil: attach failed - Permission denied
  Standard Error:
  Elevated hdiutil attach did not mount the image
• Critical resources missing, cannot continue with patching!!!

Testing in a virtual machine. After returning to the menu and back to the root patching, it succeeds. However, this is what I tested from main. And did so inside a virtual machine. @gandolf243 @matteoiacca

It's a good idea to fix somehow this issue before implementing this new function.
@gandolf243 @matteoiacca

@albert-mueller, @Medelcartelinc, we have some work to do here, any ideas of what to do and how to get started?

@albert-mueller, @Medelcartelinc, we have some work to do here, any ideas of what to do and how to get started?

@gandolf243 Before starting to work on the auto root patching system, we need to fix the bug that causes when trying to root patch to abort and only at the second time it succeeds. Except this, the new root patching system is now fully working and tested across multiple systems.