Dashboard: HugePages reads red when enabled but unused (0 in use) — should be green

[VijitSingh97]

Problem

When HugePages are enabled (HugePages_Total > 0) but none are in use yet (used == 0) — e.g. right after boot, or while Monero is still syncing and the miner is held — the dashboard header renders:

Huge Pages: Allocated (0 / 3072) ← in red

Red implies something is wrong, but nothing is: HugePages are correctly reserved; the miner simply isn't consuming them yet (it starts using them once mining begins). This is the normal startup / sync state, so it shouldn't read as an error.

Where it's coded

1. build/dashboard/mining_dashboard/collector/system.py → get_hugepages_status() already distinguishes three states:

   • total == 0 → ("Disabled", "status-bad", …) (genuinely off)
   • used > 0 → ("Enabled", "status-ok", …) (actively used)
   • total > 0 and used == 0 → ("Allocated", "status-warn", …) ← this case

2. build/dashboard/mining_dashboard/web/views.py (~L408) flattens the three-state into two:

   "variant": "ok" if hp_class == "status-ok" else "bad",

   so status-warn becomes bad.

3. build/dashboard/mining_dashboard/web/static/components.mjs:112 renders binary:

   class=${s.hugepages.variant === 'ok' ? 'status-ok' : 'status-bad'}

   → bad → red. (A .status-warn amber class exists in dashboard.css but is never reached for HugePages because of the flatten + binary check.)

Desired

When HugePages are enabled (total > 0), the status should be green, even with used == 0. Reserve red for the only genuinely-bad case: total == 0 ("Disabled" / not enabled). "Allocated but not yet used" is expected, not an error.

Fix options

• Simplest (matches the ask): in views.py, treat status-warn as ok for HugePages (or, in get_hugepages_status(), return status-ok for the total > 0, used == 0 case). Allocated → green; keep the "Allocated" vs "Enabled" label distinction if useful.
• Softer alternative: preserve the three-state and render status-warn as amber instead of collapsing it — fix the views.py flatten and the binary check in components.mjs:112 to honor a warn variant. (Not red, not full green — "ready, not yet used".) Per the report, plain green is preferred.

Add/extend a unit test for get_hugepages_status() covering all three states, and assert the views.py mapping doesn't turn an enabled-but-unused node red.

Repro

Enable HugePages (GRUB hugepages=N + reboot) on a node while Monero is still syncing (miner held). Dashboard header shows "Huge Pages: Allocated (0 / N)" in red despite HugePages being correctly reserved.

[VijitSingh97]

Acceptance criteria (the color contract)

Red/green must reflect the genuine enabled/disabled state, driven solely by HugePages_Total:

• RED ⇔ genuinely disabled — HugePages_Total == 0 (nothing reserved in kernel/GRUB).
• GREEN ⇔ genuinely enabled — HugePages_Total > 0 (reserved + available), regardless of how many are currently in use.
• The used count (Total − Free) is informational only — it stays in the displayed X / Total string but must not drive the color. So a freshly-booted/syncing node (total > 0, used == 0) is genuinely enabled → green; only total == 0 is red.

Optional, out of scope here: if total > 0 but smaller than the RandomX dataset needs (~2 GB ≈ ~1040 × 2 MB pages), that's "enabled but insufficient" and could warrant an amber/warn — a separate enhancement from this enabled/disabled color fix.

[VijitSingh97]

Related: #104 — Surface setup/host warnings as dashboard badges (AVX2, HugePages, low disk/RAM) already scopes the HugePages badge. This issue is the specific correctness bug in that badge (reads red when HugePages is enabled but unused / 0 in use). Fix standalone or fold into #104.