11f27f5ef9
Reached 238 via public-key enrolment - no password anywhere. The first attempt failed because the key had never landed in authorized_keys; the second worked once the fingerprint matched. Findings worth keeping beyond this node: The VM reports 'AMD Ryzen 9 3900X' and then lists 65 CPUID flags that stop at SSE4.2. No avx, no avx2, no fma. That silicon has AVX2 and FMA, so VirtualBox is masking them and /proc/cpuinfo is a declaration, not a measurement. Recorded as *unverified* rather than absent, because confirming it needs an actual AVX instruction executed and there is no gcc on the guest - a flag list cannot settle it. This is the defect the compute design already has, one layer down. The agent sets throughput_factor by string-matching a GPU model (40.0 if '4070' in name else 20.0), which is a declared factor wearing a measured one's name. Here the hypervisor makes the same kind of lie. Capability discovery therefore has to probe by executing instructions and treat an unverifiable feature as unavailable. Also: cpu.max is 'max 100000' so the guest is not CPU-capped, memory is 47.0 GiB unballooned, no GPU and no nested virt flags, and umbra has no sudo. Recorded in docs/ node-238-capability-profile.md with how each value was obtained.
3.8 KiB
Node 238 — capability profile
Measured 2026-10-03 by connecting over SSH as umbra. Every line is an observation,
not an inference from the model name.
Identity
| host | bd-VirtualBox @ 192.168.123.238 |
| os | Linux Mint 22.3 |
| kernel | 6.8.0-142-generic |
| arch | x86_64 |
| hypervisor | oracle (VirtualBox) |
| systemd | 255, cgroup v2 |
| account | umbra, no sudo |
| python | 3.12.3 at /usr/bin/python3, no numpy |
| docker | 29.8.2 installed, daemon active, socket not usable by umbra |
Host key, pinned at first connect:
SHA256:TUYmtC+joG56eJYWb79Hd79SlZqBGyHylDYh1wACY/s (ED25519)
Controller key used: umbratools-node-management@oldbox,
SHA256:j94G4sFwCqqeWlrAtSaQONrRHuSGW1bm33THqtoPxfg
The finding that matters: this box lies about its CPU
/proc/cpuinfo reports AMD Ryzen 9 3900X 12-Core Processor and then lists 65
CPUID flags that stop at SSE4.2. There is no avx, no avx2, no fma, no
avx512f.
A Ryzen 9 3900X has AVX2 and FMA. They are not optional on that silicon. So the
hypervisor is masking them in CPUID, and /proc/cpuinfo inside this guest is a
declaration rather than a measurement.
I could not confirm by execution — no gcc on the VM, so I could not compile an AVX
instruction and watch it fault. So AVX is recorded as unverified, not as absent.
This is the same failure the compute design already has, one layer down. The agent sets:
"throughput_factor": 40.0 if "3060" in name or "4060" in name or "4070" in name else 20.0
— a declared factor wearing a measured one's name, decided by string-matching a GPU
model. Here the hardware makes the same kind of lie, and a scheduler that trusted
/proc/cpuinfo would send AVX-tuned work to a machine that may fault on it.
Consequence for onboarding: capability discovery must probe by executing instructions, and treat an unverifiable feature as unavailable. Declared is not measured, whichever side of the hypervisor it comes from.
Measured
| property | value | how |
|---|---|---|
| logical CPUs | 12 | nproc |
| cores/socket | 12, 1 thread each | lscpu |
| cpu.max | max 100000 → unlimited |
/sys/fs/cgroup/cpu.max |
| memory total | 47.0 GiB (49,330,516 kB) | /proc/meminfo |
| memory in use | ~10.4 GiB at time of check | free |
| swap | 1 GiB | free |
| disk / | 125 GB total, 75 GB free | df |
| disk device | sda VBOX HARDDISK |
lsblk |
| loadavg | 0.51 / 1.14 / 0.88 | /proc/loadavg |
| scalar list sum | 8,388,608 items in 0.841s | python loop |
| list-comp doubling | 13.5 M items/s | python list-comp |
docker0 and br-9c6f539459cf are present, so this guest has nested container
networking; enp0s3 is the LAN interface.
Fit for purpose
Good for: capability discovery work, benchmarking harness development, testing the scheduler, testing the agent update path, cross-network tests, developing the ingest and object-storage paths against a real second node.
Not good for: GPU work (no nvidia-smi, and nested virt flags are 0 so no passthrough),
and anything needing root until sudo is arranged.
No sudo is a live constraint, not a formality — poc/poc_node_user.sh setup and
update both require root, and the GPU udev rules require it outright. For this
sandbox, running the agent as umbra in user space is the better shape anyway: the
capability and benchmarking work needs no root, and keeping it unprivileged means the
benchmark results are not measured through a privileged lens.
Open
umbrahas no sudo. Decide whether to grant it or stay unprivileged.- Docker is running but its socket is not accessible to
umbra— needs thedockergroup, which needs root to add. Not required for the current work. - AVX/AVX2/FMA status unverified by execution. Installing
gccwould settle it; that needs no sudo.