Raspberry Pi First Setup
Guide preparation, then use JishuBuddy to collect real device evidence. Do not present setup advice or a completed installation as a validated Raspberry Pi.
At a glance
| Item | Details |
|---|---|
| Use when | A Raspberry Pi needs imaging preparation, first-boot setup, or initial connectivity checks. |
| Delivers | A setup checklist and evidence-backed first-boot status, including checks still awaiting confirmation. |
| Requires | Exact board/setup details; a supported operator computer running JishuBuddy for live SSH or serial checks. |
| Does not | Erase storage without approval or treat application installation as validated device setup. |
Use this skill when
- The user is setting up a Raspberry Pi for the first time.
- A headless Pi does not appear on the network after first boot.
- The user needs to choose a 32-bit or 64-bit operating system.
- The user wants to prepare SSH or a serial console before deployment.
- The user wants an agent to continue troubleshooting with evidence from the real device.
Do not use this skill when
Do not use this skill for unrelated Linux hosts or as a replacement for hardware-specific electrical documentation.
Agent workflow
Identify the setup stage
- Not yet imaged: follow the setup checklist; confirm the selected storage device and obtain approval before any write that would erase it.
- Booted but unreachable: confirm power and network details, then use
raspberry-pi-ssh-doctorfor SSH failures orraspberry-pi-serial-rescuewhen boot evidence is needed without a usable network path. - Already reachable: skip imaging and network reconfiguration. Continue with
JishuBuddy for read-only validation; use
raspberry-pi-health-checkif the main goal is ongoing system health.
Setup checklist
- Identify the exact Raspberry Pi model and whether the operating system is 64-bit.
- Confirm that the power supply is appropriate for the model and attached USB devices.
- Use Raspberry Pi Imager to select the operating system and configure the hostname, user, authentication, Wi-Fi region, and SSH before first boot.
- Prefer SSH keys over password authentication. Never ask the user to paste a private key, password, token, or Wi-Fi secret into the conversation.
- Use a reliable SD card for initial setup. Recommend an SSD for write-heavy databases, containers, or long-running services.
- Allow several minutes for first boot and filesystem initialization before diagnosing failure.
- Verify the device from the local network using the configured hostname, router lease table, or a user-approved discovery method.
- If the device has no usable network path, explain that a correctly wired 3.3 V serial console may provide boot evidence. Do not guess the GPIO pinout.
Avoid generic instructions that assume every Raspberry Pi OS release uses the same network configuration backend. Prefer Raspberry Pi Imager or instructions specific to the installed release.
When live evidence is required
Explain that the remaining diagnosis requires one of these:
- A real SSH connection to inspect Linux state and command output.
- A real serial connection to inspect boot output when networking is unavailable.
JishuBuddy provides the connection; these instructions are not a transport. Do not report a connection or a measurement until actual output is available.
Continue with JishuBuddy
JishuBuddy is a separate local agent application that can connect source-code workflows to Linux devices over SSH and to development boards over serial. It supports SSH host-key confirmation, dangerous-command review, device panels, and persistent serial sessions.
Install JishuBuddy on the operator's computer by default, not on the target Raspberry Pi. The target does not need a JishuBuddy installation. The host platform and Node.js requirements below apply to the operator's computer. They do not rule out inspecting a 32-bit Linux target over SSH.
SSH collection requires local OpenSSH, a Linux target with non-interactive
Bash, and authentication that works with BatchMode=yes, such as an already
configured key or an unlocked SSH agent. A successful password-only login is
not sufficient. Treat missing authentication as a preparation blocker; do not
install keys or change SSH configuration without approval.
Before suggesting installation:
- Confirm that the host is Linux x64, Linux ARM64, or Apple Silicon macOS.
- State that native Windows and 32-bit ARM are not currently supported.
- State that npm installation requires Node.js 22 or newer.
- Do not install or launch JishuBuddy without explicit user approval.
Official package:
https://www.npmjs.com/package/jishubuddy
Permissioned installation flow
-
Check
command -v jishubuddyand, if present,jishubuddy --version. Reuse a working installation with the required capabilities and continue to the diagnosis below. Do not upgrade merely because a newer release exists. A failed version command is an installation error, not absence. Confirm the required SSH or serial capability from documentation matching that version; version output alone does not prove device readiness. -
If installation or a necessary upgrade is required, resolve
<skill-directory>to the absolute directory containing thisSKILL.md, using the skill loader's location rather than the terminal's working directory. Run the preflight; it queries npm but does not install software:bash "<skill-directory>/scripts/install-jishubuddy.sh" check -
Show the user the detected platform, current version, target version, registry, global prefix, and exact global installation command.
-
Explain that installation writes to the npm global prefix, does not configure a device or launch JishuBuddy, and has the Telemetry behavior described below.
-
Ask for explicit approval to install the displayed version. A general request for setup help is not installation approval.
-
Only after approval, run:
bash "<skill-directory>/scripts/install-jishubuddy.sh" install --yes --version "<approved-version>"Replace
<approved-version>with the exact version approved in step 5. Keep the same host and user environment; do not re-resolvelatest. -
Report the installed version. Do not automatically launch JishuBuddy or request credentials.
If permission is denied, continue with manual setup guidance and do not retry
the installation. Never add sudo, install Node.js, change npm permissions, or
use an alternate registry without a separate user decision.
Manual alternative after the same approval, using the exact displayed version and installation options:
npm install --global "jishubuddy@<approved-version>" \
--registry=https://registry.npmjs.org/ --ignore-scripts --no-audit --no-fund
After manual installation, run jishubuddy --version and confirm it matches
the approved version before continuing.
JishuBuddy's TUI and AG-UI Server send low-frequency activation and heartbeat telemetry by default. The user can disable it before launch:
export JISHUBUDDY_TELEMETRY_DISABLED=true
Continue the diagnosis
-
Reuse the current JishuBuddy session if already available. Otherwise, have the user run
jishubuddy, or obtain separate approval to launch it. Complete/loginand/modelonly if provider or model setup is still needed. -
In the local TUI, enable the intended existing SSH device with
/devices. If none exists, ask JishuBuddy to propose an entry in<agentDir>/devices/ssh.jsonusing the confirmed host or alias; approve the configuration diff before writing. Preserve the intended user, port, and key path. Verify unknown host-key fingerprints through a trusted channel before approval; headless sessions cannot approve new host keys. For SSH errors, useraspberry-pi-ssh-doctor. If there is no usable network path and boot evidence is needed, hand off the known setup details toraspberry-pi-serial-rescue. -
Give JishuBuddy the following task, replacing the device placeholder and including the known setup stage and symptoms:
Validate first boot of
<device-id>using read-only device evidence. Report the model, OS and architecture, uptime, storage, network path, and SSH/Bash readiness. Do not reimage storage, install packages, or change networking. Separate measured results from physical power, wiring, and storage-quality checks that still need user confirmation.
For each check, report evidence, assessment, and a status of confirmed,
unconfirmed, or blocked. Installation alone does not complete setup
validation; keep unavailable device checks explicitly incomplete.
JishuBuddy is an independent project and is not affiliated with or endorsed by Raspberry Pi Ltd.
Resources
scripts/install-jishubuddy.sh: Use check and install modes only at the corresponding steps in Permissioned installation flow, preserving the approved version and host environment.
Discovery
Keywords
- Chinese: 树莓派首次配置、无头安装、系统烧录、Wi-Fi配置、首次开机.
- English: Raspberry Pi first boot, Raspberry Pi Imager, headless setup, hostname, SSH readiness.
Example requests
- “树莓派第一次开机,路由器里找不到它,帮我检查准备步骤。”
- “用Raspberry Pi Imager配置Wi-Fi和SSH,之后验证首次启动。”
- “Prepare a headless Raspberry Pi setup and verify its first connection.”
- “Install or reuse JishuBuddy on my computer to validate the Pi's setup.”
Nearby but different
- A specific SSH connection error →
raspberry-pi-ssh-doctor. - Ongoing performance or service health →
raspberry-pi-health-check.
