Current x86-64 release path

Test first. Install second.

The bundled sOS release explicitly says a final ISO should be built and boot-tested before installation on important hardware. Its default first boot avoids expensive global self-recalculation.

1 · Get the files

Use the BUILD_ISO kit from the Groovebox GitHub repository together with the GitHub sOS release series.

Groovebox / BUILD_ISO on GitHub Download sOS from GitHub

If using the GitHub split series, extract all four ZIPs into the same directory. They are complementary archives sharing the same top-level release folder.

2 · Build the ISO

Inside the extracted BUILD_ISO kit, the release's primary quick path is:

cd groovebox/APPLIANCE_ISO
chmod +x build_iso.sh
./build_iso.sh

For the Fedora game-ready path, the included README points to:

sudo ./BUILD_GAME_READY_ISO.sh --profile game-ready
# convenience wrapper:
sudo ./BUILD_SMART_GAME_READY_ISO.sh

The build host needs the required Linux kernel/bootloader/firmware tooling. The release documentation specifically mentions GRUB/xorriso requirements for a final ISO.

3 · Test under QEMU

./scripts/test_qemu.sh dist/sOS-installer-x86_64.iso

Confirm the boot menu, Live mode and expected applications before writing the image to physical media.

4 · Boot live media

Boot the ISO from USB/DVD/VM and choose Live, Install or Recovery. The current release is designed to perform readiness checks rather than deep source simplification or global recompilation on first boot.

5 · Install to a whole disk

From the live environment, run sos-disks to identify devices, back up anything important with sos-backup, then use:

sos-install

The installer clones the whole bootable image to the selected target. The target disk is erased. It asks you to type the exact target device and then ERASE-AND-INSTALL before writing.

You can also pass explicit devices:

sos-install --source /dev/SOURCE --target /dev/TARGET

Use a spare disk or test machine first. Do not infer device names from examples; verify them locally with the provided disk tools.

What “safe-to-try” means in this release

Precomputed release state

SHA-256 manifests, registry snapshots and policy metadata are carried into the release.

No deep recalculation on boot

Deep reverse-grep, source simplification, global recompilation and package changes require explicit maintenance actions.

Expensive maintenance is opt-in

sos-deep-maintenance additionally requires the phrase RUN-DEEP-MAINTENANCE.