From 4953bb33b22771ace08908429b09042e82ea989e Mon Sep 17 00:00:00 2001 From: Mikhail Chusavitin Date: Fri, 4 Sep 2026 09:14:38 +0300 Subject: [PATCH] docs: set 16 GB minimum supported RAM --- bible-local/architecture/runtime-flows.md | 2 +- bible-local/architecture/system-overview.md | 2 +- ...9-04-supported-systems-minimum-16gb-ram.md | 31 +++++++++++++++++++ bible-local/decisions/README.md | 1 + iso/README.md | 2 +- 5 files changed, 35 insertions(+), 3 deletions(-) create mode 100644 bible-local/decisions/2026-09-04-supported-systems-minimum-16gb-ram.md diff --git a/bible-local/architecture/runtime-flows.md b/bible-local/architecture/runtime-flows.md index 16223ce..2441c8b 100644 --- a/bible-local/architecture/runtime-flows.md +++ b/bible-local/architecture/runtime-flows.md @@ -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 diff --git a/bible-local/architecture/system-overview.md b/bible-local/architecture/system-overview.md index d301004..ac4a89b 100644 --- a/bible-local/architecture/system-overview.md +++ b/bible-local/architecture/system-overview.md @@ -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 diff --git a/bible-local/decisions/2026-09-04-supported-systems-minimum-16gb-ram.md b/bible-local/decisions/2026-09-04-supported-systems-minimum-16gb-ram.md new file mode 100644 index 0000000..8650617 --- /dev/null +++ b/bible-local/decisions/2026-09-04-supported-systems-minimum-16gb-ram.md @@ -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. diff --git a/bible-local/decisions/README.md b/bible-local/decisions/README.md index 792bf8c..bd3bbde 100644 --- a/bible-local/decisions/README.md +++ b/bible-local/decisions/README.md @@ -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 | diff --git a/iso/README.md b/iso/README.md index 2c43629..433b439 100644 --- a/iso/README.md +++ b/iso/README.md @@ -47,7 +47,7 @@ sh iso/builder/build-in-container.sh --cache-dir /path/to/cache - The builder image is automatically rebuilt if the local tag exists for the wrong architecture. - The live ISO boots with Debian `live-boot` `toram`, so the read-only medium is copied into RAM during boot and the runtime no longer depends on the original USB/BMC virtual media staying present. -- Target systems need enough RAM for the full compressed live medium plus normal runtime overhead, or boot may fail before reaching the TUI. +- Target systems require at least 16 GB of installed RAM for the full compressed live medium plus normal runtime overhead. On supported hardware, do not classify a mid-copy failure as low RAM without direct `ENOSPC`, OOM, or tmpfs-limit evidence. - The NVIDIA variant installs DCGM 4 packages matched to the CUDA user-mode driver major version. For driver branch `580` / CUDA `13.x`, the package family is `datacenter-gpu-manager-4-cuda13` rather than legacy `datacenter-gpu-manager`. - Override the container platform only if you know why: