Compute and networking
Yaoshi
Whole-disk installation and independent takeover
Yaoshi installs a locally bootable Debian system on one explicitly authorized disk. Its RAM installer fixes the target, writes the prepared system and completes offline configuration. Installation and the new system’s SSH identity are verified separately. The operator then takes over updates, credentials and daily administration.
Reinstall a machine with several disks The operator verifies the disk and public key, then authorizes that whole-disk installation. Another disk remains an independent data witness. After installation, checks from the new system establish root identity and administrative access.
Turn one authorization into an independent host
Yaoshi uses network boot to enter a RAM installer. The controller supplies boot files, a prepared root filesystem and a current device view. A terminal interface selects the machine, whole disk and takeover public key. Entering the installer or discovering disks grants no permission to write them.
The result is a Debian system that boots from local storage with the selected packages and native initialization policy. The installer, controller and interface are not ongoing management dependencies. Updates, credentials and daily operation belong to the operator.
Separate product construction from installation
Installation uses two prepared components: an installer that runs in RAM and a compressed root filesystem image, called the Rootfs, in ext4 format. Packages come from fixed, authenticated Debian inputs. Additional packages change the root image while the same compatible installer can be reused.
Installation consumes complete material without contacting package archives or executing programs from the target root. It writes only the compact image’s actual expanded length. Native first-boot behavior subsequently grows the filesystem into the available partition.
| Input | Contents | Use |
|---|---|---|
| RAM Installer | Agent, official kernel and matching drivers, native installation tools | Discover targets and execute the installation. |
| Rootfs | System packages, boot files and native initialization policy | Stream into the selected root partition. |
| This authorization | Boot identity, whole-disk identity and takeover public key | Fix the object that may change and the takeover identity. |
Bind the materials, disk authorization and access key
Before installation, the operator needs a completed installer and Rootfs, the current machine’s boot identity, an exact whole-disk target and a canonical Ed25519 public key. The public key selects the key accepted by the installed system. The private key stays with the operator for the later independent SSH connection; it is not distributed with installation material.
The target is more than a device path that may change. After the operator reviews identity, sectors and capacity, the agent still compares the retained device object with the current disk. Reconnection, replacement under the same name or a changed occupancy relationship cannot reuse a decision about another device.
Check the complete material
Establish that the installer and root filesystem image are complete before authorizing a write, and retain their content identities.
Confirm this target
Review the current machine, whole disk, public key and destructive scope as one decision, then submit explicit authorization.
Retain the handover evidence
Keep the expected root-volume UUID and original boot identity for this installation. Check the installed system against that same identity.
Bind the target before the first write
The interface displays complete disk identity, capacity, sector geometry, the public key and the scope of data loss before accepting a specific confirmation phrase. The Agent then rechecks its retained kernel device, active users and partition relationships. A reused name or similar capacity cannot inherit the authorization.
Installation creates a GPT partition table, a 512 MiB FAT32 EFI system partition for boot files, and an ext4 root partition using the remaining aligned space. Decompression and writing proceed while the compressed stream is verified. Its complete digest can only be confirmed at the end, so a late failure may follow destruction of the old system. Neither layout replacement nor separate layout clearing is secure erasure.
Preflight
Check the boot, disk, public key, geometry, tools and firmware prerequisites.
Write
Create partitions, receive and verify the compressed stream, and count actual writes.
Configure
Write installation-specific identities and boot files; establish local boot selection.
Settle
Finish synchronization, unmounts and native tasks before reporting offline completion.
Observe installation and takeover separately
Controller admission, Agent execution, offline completion and SSH takeover are distinct observations. Offline success requires the writes and cleanup to finish. It does not establish that firmware booted the new system, that it acquired a lease or that login is available.
An explicit takeover check connects to an address confirmed by the operator. The authorized key must establish administrator access (UID 0), the expected root filesystem’s unique identifier (UUID) and a boot UUID different from the installer’s. A retained matching identity permits checking after final-report loss, while preserving the original known or unknown offline outcome.
| Result | Meaning | Not established |
|---|---|---|
| Authorization admitted | This boot’s installation opportunity is allocated. | The Agent has begun writing. |
| Offline installation succeeded | Writing, configuration and settlement completed. | The system booted or permits login. |
| SSH takeover verified | Current root access to the intended new system. | A missing installation report has been recovered. |
Recover the original facts after a missing report
If submission returns no definite answer, first inspect the authorization retained by the current agent and compare its disk and public key with the original decision. Submitting another installation is not a way to discover what the first one did: the single opportunity in this installer boot may already belong to the original request.
Once the original installation has an expected root-volume UUID, an independent handover check can use the current address confirmed by the operator. It only reads administrator identity, the root-volume UUID and boot identity. It neither changes the target system nor rewrites a failed or unknown offline result as successful.
Supported conclusion: this system matches the installation
Administrator access, the expected root-volume UUID and a new boot identity must all match to support the independent SSH handover result.
Unsupported conclusion: closing the interface cancels writing
The agent retains an admitted installation. Losing the terminal or control connection does not cancel the disk task or establish that the old disk content survived.
Check next: only offline success is available
Observe the actual firmware boot and independent SSH handover before concluding that the operator can administer the installed system.
Resolve uncertainty with independent evidence
One Installer boot admits only one installation authorization. A preflight rejection or later failure does not restore that opportunity. Interface exit, reporting loss and controller shutdown do not cancel accepted disk work. A transfer failure must stop further functional writes and settle the actual tasks.
Specified verification scenarios cover unchanged non-target disks, sector geometries, interrupted writes, firmware boot and SSH takeover after the controller stops. They define the required evidence; support on a particular machine depends on applicable execution records and its actual hardware.