From network boot to the first disk write

Define what this boot should deliver

Network boot obtains an execution environment; the subsequent task needs its own authority. Infra delivers an application runtime: the controller selects an image, the Bootstrap environment verifies and prepares a read-only root, then grants execution. Yaoshi first enters a RAM installer and waits for explicit whole-disk authorization.

The paths obtain authority separately. Infra grants execution to one application within that boot; Yaoshi may write only the whole disk explicitly authorized for that attempt. An address, an image transfer or a device listing grants neither permission. Completion still requires observations from the application or new system.

Bind identity to the object actually used

Infra checks the actual network peer, unexpired lease, boot interface and static declaration when selecting an image. Hardware reports are observations rather than an authority source. Model and serial information can help an operator understand a machine, without replacing its current network binding.

Yaoshi assigns a random disk identifier within the current boot and retains the real kernel device object. Before writing, it rechecks identity, capacity, sector geometry, occupancy and partition relationships. Reappearance of a device name does not transfer the original authorization.

Separate content integrity from permission to change a device

Infra verifies the complete application image before preparing the root and granting execution. A failure before the grant must settle I/O, mounts and the child before another acquisition. Once the grant may have been delivered, that boot never starts a second application.

Yaoshi receives, decompresses and writes the root filesystem image (Rootfs) concurrently. The complete compressed digest can only be checked after the last byte, so a destructive operation may precede final verification. A failure record must retain whether potentially mutating work began. Late verification failure cannot restore the previous system.

Missing replies do not end accepted responsibility

Once an installation is admitted, the current boot’s opportunity is allocated. Lost replies do not permit resubmission, and a restarted controller does not take over the previously dispatched task. The accepting installation agent owns disk execution. Interface exit and a lost reporting connection are not cancellation.

Ending a wait, settling local work and ending remote effects require separate observations. Installation failure becomes terminal only after native writers, children, I/O and mounts settle. While cleanup remains incomplete, the original owners and nonterminal state stay in place. Timeout or an offline flag cannot certify that the disk is safe.

Place a lost reply back in the actual sequence

Suppose the installation agent admitted work but the terminal lost its network connection before receiving the reply. This establishes an incomplete local result, not an untouched disk. If a later record shows that writing began, retain that disk identity and original work. If the record remains unavailable, do not invent a definite failure.

Two questions remain: whether native writing and cleanup have settled, and whether the new system has the expected identity. The first determines when a new decision over conflicting resources is possible; the second establishes current takeover. They can be confirmed separately without asking one delayed terminal response to explain the entire history.

1. Retain the original subject

   Keep this boot, authorized whole disk and known dispatch facts. A reappearing device name grants no new permission.

2. Inspect remaining work

   Observe settlement of the same actual write, child, IO and mounts.

3. Obtain current takeover evidence

   At the explicitly authorized address, check the new boot identity, root filesystem and administrator access.

• Disconnection grants no reinstall authority

  A missing reply neither revokes admitted work nor establishes an unchanged disk.

• Report known and unknown results separately

  Successful current takeover can coexist with a lost original installation report.

Obtain takeover evidence from the new system

Offline success establishes target content, boot configuration and synchronization settlement. An explicit check then authenticates with the authorized key at an operator-confirmed address and verifies root privileges, the expected root filesystem’s unique identifier (UUID) and a boot UUID distinct from the Installer. It establishes current takeover while preserving the known or unknown installation-report outcome.

Specified verification can seed a target and a non-target disk with independent bytes, then separately examine lost admission replies, interrupted writes, lost final reports and local boot. Non-target content, actual task termination and new-system identity cover different parts of the path. These scenarios are not evidence that the experiments have already passed.

The execution rules select the verification environment by actual effects. Owned files and direct children can be observed in controlled processes; firmware, system services, global block devices and boot behavior require an isolated VM with independent termination control. Process exit, guest completion and resource settlement remain distinct from the application result.