I had Claude save the install notes for DreamServer on my new platform.

[kuston]

Hopefully this is helpful, I had Claude on one system assist me in getting DreamServer setup on my new system. Here are the notes:

DreamServer v2.4.0 Installation Report — Blackwell GPU + Miniconda System

System Specs:

• OS: Ubuntu 24.04 LTS (detected as 26.04 by installer)

• CPU: AMD Ryzen Threadripper 3960X 24-Core

• RAM: 64GB DDR4

• GPU: NVIDIA RTX PRO 6000 Blackwell Workstation Edition (96GB VRAM)

• Driver: nvidia-driver-580-open

• Storage: 500GB NVMe (OS) + 2TB RAID 0 (data)

• Docker: 29.1.3, Compose v2, NVIDIA Container Toolkit installed

• Python: Miniconda (conda) alongside system Python 3

Tier detected: NV_ULTRA

Model profile: qwen (Qwen3 Coder Next Q4_K_M)

Outcome: Successful install after working around several issues

---

Issue 1: PyYAML detection fails silently when Miniconda is installed (CRITICAL)

• Severity: Blocker — installer exits silently with no user-visible error

• Symptom: Installer stops after Phase 02 (System Detection) and returns to shell prompt. No error message displayed. Install log at /tmp/dream-server-install.log shows repeated

ModuleNotFoundError: No module named 'yaml' and [WARN] PyYAML not available. Service registry will be incomplete.

• Root cause: Miniconda adds its own python3 to the front of PATH. The installer runs sudo apt-get install python3-yaml, which installs the package for /usr/bin/python3 — but the

active python3 is Miniconda's, which doesn't see apt-installed packages. The set -euo pipefail in install-core.sh causes the script to exit on the resulting Python error with no

user-facing message.

• Workaround: Run conda deactivate before launching the installer.

• Suggested fixes:

  • Detect conda/venv in PATH and warn the user to deactivate before proceeding

  • Use /usr/bin/python3 explicitly for yaml operations instead of bare python3

  • Or pip3 install pyyaml into whatever Python is active, rather than relying on apt

  • Display an explicit error message instead of silently exiting

Issue 2: sudo password prompt causes apparent freeze during --non-interactive install

• Severity: High — install appears hung with no indication of what's wrong

• Symptom: Installer freezes during Phase 05 (Docker Setup) at sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml. When running with 2>&1 | tee, the password prompt is not

visible.

• Root cause: --non-interactive doesn't pre-cache sudo credentials. Long-running phases can exceed the sudo timeout, causing an unexpected password prompt mid-install.

• Workaround: Run sudo -v before starting the installer.

• Suggested fixes:

  • Add sudo -v at the top of install-core.sh

  • In --non-interactive mode, either require root or fail explicitly rather than blocking on a password prompt

  • Document the sudo -v prerequisite

Issue 3: NVIDIA open vs closed kernel modules not validated

• Severity: Medium — installer passes checks but GPU won't work at runtime

• Symptom: Installer checks DRIVER_VERSION >= 570 and passes, but doesn't verify whether open kernel modules are loaded. Blackwell GPUs (RTX PRO 6000, etc.) require

nvidia-driver-XXX-open. The closed (proprietary) variant loads modules but fails with NVRM: installed in this system requires use of the NVIDIA open kernel modules and nvidia-smi

returns "No devices found."

• Impact: Installer completes successfully but containers fail at runtime because the GPU isn't accessible.

• Suggested fixes:

  • Check for open kernel module status (e.g., modinfo nvidia | grep open or check /proc/driver/nvidia/params)

  • Verify nvidia-smi returns an actual device, not just a driver version

  • Warn Blackwell users specifically about the open module requirement

Issue 4: Installer appears to run phases twice

• Severity: Low — install still succeeds but takes longer and generates confusing output

• Symptom: When run with bash -x, the entire detection → features → docker → directories sequence appears twice in the trace output. Secrets are regenerated on the second pass.

• Possible cause: install.sh wrapper calling install-core.sh which re-sources phase scripts, or the script re-executing itself.

---

Notes:

• Miniconda is extremely common on ML workstations (Ubuntu 24.04's PEP 668 enforcement essentially requires it for PyTorch). Issue 1 will likely affect many users in the target

audience.

• The combination of set -euo pipefail + silent Python failures makes debugging very difficult. Users see no error — just a return to the shell prompt.

• Once these issues were worked around, the install completed cleanly and DreamServer came up with the correct NV_ULTRA tier, GPU assignment, and all expected services.

[Lightheartdevs]

Hey my friend! Thanks so much for the logs and feedback, anything we can get from people is always appreciated! What you had to share was genuinely valuable, and we pushed some fixes last night for this. Thank you again!

[kuston]

no problem, DreamServer has been a great aid in getting everything setup - it's saved me weeks. I'm starting from scratch.

…

On Sun, May 17, 2026 at 3:09 AM Mike Bradley ***@***.***> wrote: Hey my friend! Thanks so much for the logs and feedback, anything we can get from people is always appreciated! What you had to share was genuinely valuable, and we pushed some fixes last night for this. Thank you again! — Reply to this email directly, view it on GitHub <#1206 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AENB7N32AIL2EDTYUEHFYR343GFT7AVCNFSM6AAAAACY6JM2KSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMOJUHA4TKMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: <Light-Heart-Labs/DreamServer/repo-discussions/1206/comments/16948950@ github.com>