docs: set 16 GB minimum supported RAM

2026-09-04 09:14:38 +03:00
parent 677f4f4006
commit 4953bb33b2
5 changed files with 35 additions and 3 deletions
@@ -143,7 +143,7 @@ Build host notes:
 - The live-build workdir under `dist/` is disposable; source files under `iso/builder/` stay clean.
 - Container build requires `--privileged` because `live-build` uses mounts/chroots/loop devices during ISO assembly.
 - On macOS / Docker Desktop, the builder still must run as `linux/amd64` so the shipped ISO binaries remain `amd64`.
- Operators must provision enough RAM to hold the full compressed live medium plus normal runtime overhead, because `toram` copies the entire read-only ISO payload into memory before the system reaches steady state.
+- Supported systems have at least 16 GB of installed RAM. This provides room for the full compressed live medium plus normal runtime overhead because `toram` copies the entire read-only ISO payload into memory before the system reaches steady state. A mid-copy failure must not be classified as low RAM without direct `ENOSPC`, OOM, or tmpfs-limit evidence.

 ## Post-boot smoke test

@@ -91,7 +91,7 @@ Fills gaps where Redfish/logpile is blind:
 - Live-ISO-only responsibilities stay in `iso/` integration code
 - Live ISO launches the Go CLI with `--runtime livecd`
 - Local/manual runs use `--runtime auto` or `--runtime local`
- Live ISO targets must have enough RAM for the full compressed live medium plus runtime working set because the boot medium is copied into memory at startup
+- Live ISO targets have a supported minimum of 16 GB installed RAM, enough for the full compressed live medium plus runtime working set; mid-copy failures require direct evidence before being classified as memory exhaustion

 ## Key paths

@@ -0,0 +1,31 @@
+# Supported systems have at least 16 GB of RAM
+
+**Date:** 2026-09-04
+**Status:** active
+
+## Context
+
+EASY-BEE boots the live image with `toram`. The compressed live medium is
+copied into RAM before the root filesystem is used. During investigation of a
+boot failure, the large squashfs copy was observed to stop part-way through.
+
+The servers in scope are not low-memory systems. The minimum supported
+hardware configuration has 16 GB of installed physical RAM.
+
+## Decision
+
+- EASY-BEE targets and supports systems with at least 16 GB of installed RAM.
+- Capacity below 16 GB is outside the supported hardware envelope.
+- A mid-copy `toram` failure on supported hardware must not be attributed to
+  insufficient total RAM without direct evidence such as `ENOSPC`, an OOM
+  event, or an unexpectedly restricted tmpfs.
+- Diagnostics must preserve the actual copy/read error so media transport,
+  virtual-CD disconnects, and I/O failures can be distinguished from memory
+  exhaustion.
+
+## Consequences
+
+The approximately 2.8 GB live medium has sufficient capacity headroom on
+supported systems. Current v14 boot investigation therefore treats the
+part-way SquashFS copy failure as a source-media or virtual-media read-path
+failure unless boot logs provide explicit evidence of memory exhaustion.
@@ -18,3 +18,4 @@ One file per decision, named `YYYY-MM-DD-short-topic.md`.
 | 2026-08-31 | Support bundle uses private staging and unique atomic output | active |
 | 2026-09-03 | PCIe link verdict comes only from the existing real-traffic GPU bandwidth SAT | active |
 | 2026-09-03 | Runtime Copy to RAM succeeds only after active loop devices move to tmpfs | active |
+| 2026-09-04 | Supported systems have at least 16 GB of RAM | active |