Hydra-OS/docs/install.md

Install HydraOS

HydraOS targets x86_64 UEFI systems. Disable Secure Boot for this first image. Boot the ISO and open the recovery terminal. The live session uses a locked hydra-live account with local sudo access; changes in the live filesystem are volatile. The image provides no default SSH login or universal installed password.

hydra-install lists disks without selecting one. Inspect the devices, then ask for a plan using the whole disk you intend to erase:

hydra-install
hydra-install --disk /dev/CHOSEN_DISK --user YOUR_USER

Replace the placeholders with an actual whole disk and your desired account name. The installer rejects mounted devices, the running root, the live medium, and their backing disks. These checks help prevent mistakes; verify the chosen disk and preserve backups before executing the plan. Physical disk installation requires the operator's explicit choice.

To execute, enter the identical resolved whole-disk path in the confirmation:

sudo hydra-install --disk /dev/CHOSEN_DISK --user YOUR_USER \
  --execute --confirm-erase /dev/CHOSEN_DISK

Execution erases the disk, creates a 1 GiB FAT32 EFI partition and an ext4 root, extracts the prepared payload, and prompts twice on the local terminal for your installed account password. Passwords have no command-line or configuration option. The installed root account stays locked. Defaults are Europe/Moscow and English UTF-8, with Russian UTF-8 also available; --timezone accepts an IANA zone present in the payload.

The installer removes the live account, local password-free sudo rule, and live autologin overrides, then builds a normal disk initramfs and fallback UEFI loader. Wait for Installation completed, power off, remove the ISO, and boot the installed disk. Log in with the account and password you supplied. On failure, read the printed live diagnostic path; when a target root was mounted, a nonsecret snapshot is also saved at /var/log/hydra-install.log on that disk.

Disposable VM acceptance

Run the repository harness with QEMU/KVM, qemu-img, Python 3, and a generic x86_64 QEMU OVMF CODE/VARS pair. A Xen-specific OVMF build is unsuitable: the first validation attempt with that variant produced no guest boot output. Use trusted image and matching firmware files. For example:

install -d -m 700 "$HOME/.cache/hydra-tests"
python3 dev/iso-smoke.py --iso /absolute/path/to/hydra-os.iso \
  --ovmf-code /absolute/path/to/OVMF_CODE.fd \
  --ovmf-vars /absolute/path/to/OVMF_VARS.fd \
  --scratch-parent "$HOME/.cache/hydra-tests"

The harness creates a private directory under /tmp, a new 32 GiB sparse qcow2 disk, and a private copy of OVMF variables. There is no existing disk argument. QEMU attaches the ISO read-only; serial and QMP use private Unix sockets. Tool overrides --qemu and --qemu-img support temporary development environments. --scratch-parent, --memory, --boot-timeout, and --install-timeout control retained artifacts and bounded resource use. Prefer a disk-backed scratch directory: an installed disk stored on a tmpfs such as /tmp consumes host RAM. The example keeps test data in the user's cache.

The test boots the live image, runs the real installer through the guest's controlling terminal using a generated password, writes a persistence sentinel, shuts down, and launches a second QEMU with the ISO absent. It verifies password login, disk root, removed live overrides, services, bridge/NAT configuration, DNS, recovery tools, and a routed new TCP connection from a synthetic LAN to a synthetic VM endpoint. Network namespaces and veth interfaces exist only inside the disposable HydraOS guest. When guest KVM is available, it launches a further fresh-disk QEMU as the installed account to exercise KVM, the bridge helper, and private QMP; this checks VM launch, not a nested operating system boot. It also logs the installed account out and back in, checking that the same VM, private sockets and user audio services survive a measured interval without an open login session. This establishes process/socket continuity, not audio playback.

report.json records each observed check, ISO/firmware SHA256, failures, and skipped nested virtualization. Serial/QEMU logs and the qcow2 remain in the printed scratch directory for review; passwords are redacted even across serial read boundaries. Cleanup controls only the QEMU process created by this run. A passing unit suite establishes harness behavior, not ISO acceptance. An actual successful report from the built ISO is required for boot/install/reboot acceptance.

Checks requiring the laptop

Disposable QEMU results cannot establish ASUS FX517ZC hardware support. Before using HydraOS daily, boot the live ISO and observe Wi-Fi, touchpad, audio, brightness, suspend/resume, USB device selection, input capture, and actual display refresh. Physical installation and these checks remain pending until explicitly performed and recorded.