Fix nodejs installation logic on Debian-based systems#100102
Conversation
On Debian-based systems, a package named "pacman" (the arcade game) exists in the official repositories. If a user has this game installed, the script incorrectly identifies the system as Arch-based. Changing the check from logical OR (||) to logical AND (&&) ensures that we only trigger the Arch installation path if both the pacman command is available AND the system is confirmed to be Arch Linux.
openclaw-barnacle
Bot
added
scripts
|
Codex review: needs real behavior proof before merge. Reviewed July 4, 2026, 11:15 PM ET / 03:15 UTC. Summary PR surface: Other -4. Total -4 across 1 file. Reproducibility: yes. Current main is source-reproducible because Review metrics: 1 noteworthy metric.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land the narrow routing change after redacted real installer proof for a Debian/Ubuntu/Mint fake-pacman setup and an Arch-like pacman setup, ideally with focused shell regression coverage in the existing installer test harness. Do we have a high-confidence way to reproduce the issue? Yes. Current main is source-reproducible because Is this the best way to solve the issue? Yes for the code shape: requiring both Arch identity and pacman availability is the narrow maintainable fix. It is not merge-ready until real behavior proof, and preferably focused regression coverage, confirms the installer routes. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against fcd7eb6130ed. Label changesLabel justifications:
Evidence reviewedPR surface: Other -4. Total -4 across 1 file. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (6 earlier review cycles)
|
clawsweeper
Bot
added
rating: 🧂 unranked krab
openclaw-barnacle
Bot
removed
the
triage: needs-pr-context
|
@clawsweeper re-review Addressed the Arch detection false-positive issue by separating distro detection from pacman availability. Changes in this revision:
Validation:
|
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
I rechecked the latest head
Until that lands, maintainers still have to manually trust Linux package-manager routing. I would treat this as not proof-complete yet: please add the regression test/logs, or update the validation comment/body with the actual terminal output if that proof was run elsewhere. |
|
Hi @harjothkhara — quick correction on my earlier note. I said “added/updated regression coverage”, but that was poor wording. Here’s the manual check showing the routing fix: Before (incorrect pacman route on Debian): Installing Node.js via pacman (Arch-based distribution detected)
sudo: pacman: command not foundAfter (correct NodeSource route): INFO Installing Node.js via NodeSourceThanks for the review! Here is my full log: ┌─[✖]─[gfaerny@cary-x1]─[~/gf/gp/openclaw/scripts]
└──╼ -> cat /etc/os-release
sudo apt install pacman
curl -fsSL https://openclaw.ai/install.sh | bash
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.5
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
pacman is already the newest version (10-21).
Summary:
Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 303
Preparing installer interface...
🦞 OpenClaw Installer
iMessage green bubble energy, but for everyone.
✓ Detected: linux
Install plan
OS: linux
Install method: npm
Requested version: latest
[1/3] Preparing environment
· Node.js v20.19.2 found, upgrading to a supported version
· Installing Linux build tools (make/g++/cmake/python3)
· Updating package index
✗ Updating package index failed — re-run with --verbose for details
W: OpenPGP signature verification failed: https://apt.v2raya.org v2raya InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Error: Failed to parse keyring "/etc/apt/keyrings/v2raya.asc" Caused by: 0: Reading "/etc/apt/keyrings/v2raya.asc": No such file or directory (os error 2) 1: No such file or directory (os error 2)
E: The repository 'https://apt.v2raya.org v2raya InRelease' is not signed.
· Installing build tools
✓ Build tools installed
· Installing Node.js via pacman (Arch-based distribution detected)
· Installing Node.js
✗ Installing Node.js failed — re-run with --verbose for details
sudo: pacman: command not found
┌─[✖]─[gfaerny@cary-x1]─[~/gf/gp/openclaw/scripts]
└──╼ -> ./install.sh
Preparing installer interface...
· Preparing spinner support
· Verifying spinner support download
╭─────────────────────────────────────────────╮
│ │
│ 🦞 OpenClaw Installer │
│ Works on Android. Crazy concept, we know. │
│ modern installer mode │
│ │
╰─────────────────────────────────────────────╯
✓ gum bootstrapped (temp, verified, v0.17.0)
✓ Detected: linux
Install plan
OS linux
Install method npm
Requested version latest
[1/3] Preparing environment
INFO Node.js v20.19.2 found, upgrading to a supported version
INFO Installing Linux build tools (make/g++/cmake/python3)
INFO Updating package index
ERROR Updating package index failed — re-run with --verbose for details
W: OpenPGP signature verification failed: https://apt.v2raya.org v2raya InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Error: Failed to parse keyring "/etc/apt/keyrings/v2raya.asc" Caused by: 0: Reading "/etc/apt/keyrings/v2raya.asc": No such file or directory (os error 2) 1: No such file or directory (os error 2)
E: The repository 'https://apt.v2raya.org v2raya InRelease' is not signed.
INFO Installing build tools
✓ Build tools installed
INFO Installing Node.js via NodeSource
INFO Downloading NodeSource setup script
INFO Installing Node.js
ERROR Installed Node.js must be 22.19+, 23.11+, or 24+ but this shell is using v20.19.2 (/usr/bin/node)
Upgrade the system Node.js package or install Node.js 24 manually, then rerun the installer.``` |
|
Thank you for the contribution. This fix landed with contributor co-authorship preserved in #100258 ( I consolidated the source fixes into a maintainer takeover because the contributor branches were based on rewritten pre- |
3 participants
What Problem This Solves
Fixes an issue where non-Arch Linux systems (such as Debian, Ubuntu, Mint, etc.) that happen to have a
pacmanexecutable present in theirPATHwere incorrectly routed into Arch-based installer branches.This caused the installer to attempt
pacman -Syoperations on systems that do not use pacman as a package manager, breaking build-tool installation, Git installation, and the Node.js install path.The root cause was that the Arch detection logic treated the presence of any
pacmanbinary as proof of an Arch-based distribution.Why This Change Was Made
The previous logic relied on:
Additionally,
is_arch_linuxitself included a fallback that returned success ifpacmanexisted inPATH.This produced false positives whenever any package or program named
pacmanwas installed on non-Arch systems.To correct this:
Removed the pacman fallback from
is_arch_linux()The function now identifies Arch-based systems only via
/etc/os-releaseor/etc/arch-release.Switched installer conditions from
||to&&The installer now requires:
before using pacman installation paths.
This prevents unrelated binaries named
pacmanfrom triggering Arch-specific routes.User Impact
pacmanon their system (e.g., games or custom tools) will no longer be misdetected as Arch.apt/NodeSource on Debian-based systems.Evidence
(You will add your real logs + test outputs here as soon as you run the PR-proof steps.)
Follow-up (optional)
Dear maintainers,
If you agree, I can submit a separate PR to add distro‑specific helpers such as
is_debian_linux()andis_fedora_linux()to reduce repeatedcommand -v apt-get/command -v dnfchecks and improve installer routing clarity across the codebase.