Before you begin

OPEMOS.EXE supports macOS and a Windows x86_64 builder path. Apple Silicon is the primary development host; Intel macOS and Windows have less physical coverage. Windows requires hardware virtualization with WHPX, QEMU (including its share firmware directory), cdrtools mkisofs, OpenSSH ssh and ssh-keygen, Python, and the managed Fedora appliance. The app reports the specific missing prerequisite and keeps build controls disabled until its QEMU WHPX launch probe succeeds. Windows can refresh a read-only list of eligible USB physical drives; physical USB writing remains unavailable.

You need enough free space for the source image, disposable overlay, final raw image, and runtime reserve; QEMU and the managed Fedora appliance; an official Valve SteamOS recovery image; and network access for exact OPEMOS artifacts and authenticated userspace inputs.

The application reports exact required and available storage before expensive mutation. It does not resize SteamOS partitions automatically.

Development launch

git clone https://github.com/CorniiDog/OPEMOS.EXE.git
cd OPEMOS.EXE
./cargodev_init_macos.sh

On Apple Silicon, prepare the x86_64 appliance once:

./builder/appliance/build_macos.sh --architecture x86_64

Build an image

  1. Download the official SteamOS recovery image from Valve.
  2. Drag the .img, .img.bz2, .img.gz, or .img.xz into OPEMOS.EXE.
  3. Review the detected SteamOS version, kernel, architecture, and output.
  4. Leave NVIDIA source on Automatic (Recommended) unless deliberately testing a pinned project branch.
  5. Choose whether to retain the image, write a selected removable drive, or do both.
  6. Click Build NVIDIA Image.
  7. Keep the progress window open while the managed appliances validate and mutate the disposable overlay.

Automatic mode never chooses an experimental upstream NVIDIA tag. It accepts only an exact kernel and a bounded same-series publication policy defined by OPEMOS.

Read the result

Result Meaning
locally-built-verified Exact local build passed structural and provenance checks; hardware certification is separate
nvidia-mutation-valid Offline mutation and independent image inspection passed
development-unverified Build completed but a production trust property was not established
Marker-only image NVIDIA installation was not accepted; useful only as an earlier development milestone
Failed Disposable output is rejected and the original remains unchanged

Successful output includes a versioned manifest sidecar. It records basenames, hashes, target identity, tool/appliance identity, trust, and verification state without embedding full host paths.

Export to USB

USB export accepts only a whole external physical removable device. Immediately before writing, OPEMOS.EXE revalidates identity and capacity, requires the exact ERASE diskN phrase, asks for final confirmation, writes through a narrowly authorized raw-device descriptor, reads the written range back, verifies its SHA-256, and ejects it.

A finalized -nvidia.img may be dropped into the application again when its adjacent .manifest.json remains beside it. OPEMOS.EXE rehashes the image and requires the manifest’s complete NVIDIA-mutation and independent-validation result before offering USB export. It never starts the builder merely because a filename ends in -nvidia.img.

The GUI must not run as root. Virtual and internal disks remain ineligible even though the copy engine is tested against disposable virtual media.