# nginx cross-distribution reboot study evidence

Capture date: 2026-08-09 UTC

This directory records a deliberately small OpenFactory example: put the same
nginx requirement into four Linux image recipes, boot each resulting artifact,
and verify that nginx still works after rebooting the same retained VM.

The target families are:

- Ubuntu 24.04
- Debian 13 (Trixie)
- Fedora 43
- openSUSE Leap 15.6

## What counts as a pass

A target passes only when all of the following are true on the initial boot and
again after a reboot of the same VM:

1. The native package database reports nginx installed.
2. `nginx.service` is enabled for future boots.
3. `nginx.service` is active.
4. A process is listening on TCP port 80.
5. `http://127.0.0.1/` returns HTTP 200.
6. `nginx -v` reports an installed version.
7. The kernel boot ID changes across the reboot.

Ubuntu, Debian, and Fedora also completed the screenshot-backed assertion plan,
which checks boot readiness, package-manager health, and outbound HTTPS.
openSUSE completed the same nginx contract in a lean retained-VM run after the
screenshot layer stalled; that result is labeled `provision-only retained VM`
in the raw evidence rather than being represented as a full assertion-plan
pass. A built ISO alone is never recorded as a pass.

## Reproduce it

Download a recipe from the `recipes/` directory. The four inputs intentionally
use the same `headless` and `nginx` features, the same nginx service
declaration, and the same runtime assertions. The openSUSE recipe additionally
declares `qemu-guest-agent`, which the retained-VM test transport needs.

After authenticating the public OpenFactory CLI, run:

```bash
openfactory build --recipe ubuntu-24.04.json --wait
```

You can also import the downloaded JSON through
`https://console.openfactory.tech`, review it, start the build, and use the
managed VM test controls. The final result files preserve the recorded recipe
and ISO SHA-256 values, assertion output, proof-command output from both boots,
changed boot IDs, and cleanup outcome. The compact failed-run files preserve
the runner verdicts and identifiers used in the attempt history. None of these
files contains authentication data.

## Evidence files

- `results-debian.json` is the completed Debian retained-VM and reboot proof.
- `results-ubuntu.json` is the completed Ubuntu retained-VM and cold-restart
  proof, including the live-media reset assist.
- `results-fedora.json` is the completed Fedora r4 retained-VM and reboot
  proof after the systemd preset correction.
- `results-opensuse.json` is the completed openSUSE Leap r8 retained-VM and
  reboot proof after the guest-agent, volume-label, resolver, and document-root
  corrections.
- `results-fedora-r3.json` preserves the failed Fedora run that isolated the
  first-boot preset defect.
- `results-opensuse-r3.json` preserves the failed openSUSE run that separated
  guest-agent package installation from guest-agent service enablement.
- `results-opensuse-r4.json` preserves the failed openSUSE run that isolated
  the remastered ISO volume-label mismatch.
- `results-opensuse-r5.json` preserves the failed openSUSE run that isolated
  the baked resolver file and empty nginx document root.
- `results-opensuse-r7-transient.json` preserves the runner's test-backend
  interruption during the r7 attempt; the chronological record describes the
  resumed run's definitive resolver failure.
- `results-rpm.json` records the first Fedora and openSUSE test outcomes that
  exposed service-enablement and guest-agent defects.
- `attempt-history.md` is the chronological audit trail, including failed and
  quarantined builds. Failures are retained because they are part of the useful
  technical result.
- `results.json` is the four-target aggregate: four passed targets, zero failed
  targets, with each target's proof mode preserved.

## Interpretation limits

This is a functional build-and-boot comparison, not a distribution benchmark.
It says nothing about throughput, security posture, long-term maintenance, or
which distribution is “best.” Package versions come from each distribution's
configured repositories on the capture date. A runtime pass also does not
override an unresolved artifact-publication safety finding; those are reported
as separate outcomes.