Arch Linux for Banana Pi

Illustration for Arch Linux for Banana Pi documentation

Summary

This page is a practical, repeatable routine for running Arch Linux on Banana Pi-class boards. The goal is simple: get to a clean first boot, keep updates safe, and know what to check when something changes.

Because Arch is rolling, the biggest risk is updating without a safety net. The guidance below keeps you in control: verify downloads, bring up networking, update with a plan, then confirm you still have console access and a healthy system.

Who this is for

New board owners who want a predictable “flash → boot → update” flow, and developers who need an easy maintenance routine for a headless SBC.

What you’ll do

  • Flash an Arch Linux image to reliable storage and boot with minimal peripherals.
  • Bring up networking (Ethernet first), confirm DNS, and set the clock.
  • Update packages safely with pacman and reboot under supervision.
  • Lock down basic access (keys for SSH, disable password logins where possible).
  • Run quick verification checks so you spot problems early.

Quick checklist

  • Known-good SD card (or eMMC module if applicable) and a reliable writer.
  • Stable PSU; avoid undervoltage (random resets are a classic symptom).
  • Ethernet cable (preferred for first boot), or a known-compatible Wi‑Fi dongle.
  • Optional: USB–TTL serial adapter (3.3V) for recovery and early boot logs.
  • Image file downloaded from the LeMaker downloads hub.
  • Checksum file (or a published hash) to verify the download.
  • Keyboard/HDMI only if you are not using SSH/serial.

Image + boot flow (safe, repeatable)

  1. Verify the download before flashing. From your workstation: 
    sha256sum archlinux-image.img.xz
sha256sum archlinux-image.img

    Match the output to the published checksum. If you can’t verify integrity, re-download before proceeding.

  2. Identify the target device and flash carefully. Confirm the device node first: 
    lsblk
# Example output will show /dev/sdX with the SD card size

    Flash using the method you prefer (GUI imager or command-line). Re-insert the card and confirm partitions appear.

  3. Boot with minimal peripherals. Use Ethernet if possible, and keep USB devices to a minimum until the system is stable.
  4. Get access (serial or SSH). If you have a serial adapter, capture early boot output. If using SSH, confirm the board got an IP address and that you can log in reliably.
  5. Do a supervised first update and reboot. This is the point where rolling releases most often surprise you; keep a console open and plan the reboot.

Network bring-up tips

  1. Confirm link and address: 
    ip a
ip r
  2. Confirm DNS: 
    cat /etc/resolv.conf
getent hosts example.com
  3. Confirm time is sane: 
    timedatectl status

    If the clock is wildly wrong, TLS and package downloads can fail.

Pacman update routine (safe on SBCs)

  1. Refresh and update: 
    sudo pacman -Syu
  2. If the update touched kernel/boot components, plan a reboot. Keep serial or local console access available.
  3. Reboot: 
    sudo reboot
  4. After reboot, verify health: use the checks in the next section.
  5. Repeat updates intentionally. On headless systems, avoid unattended upgrades until you have proven remote recovery access works.

Basic hardening (small steps that help)

  1. Use SSH keys for admin access. From your workstation, generate a key if needed and install it on the board.
  2. Disable password SSH login once keys work. Edit /etc/ssh/sshd_config and set: 
    PasswordAuthentication no

    Then restart the service and confirm you can still log in before closing your session.

  3. Keep a recovery path. If you can, keep serial access available and avoid changing both networking and SSH settings in the same session.

Verification checks

Run these after first boot and after any significant update:

uname -a
ip a
systemctl --failed
journalctl -b -p err | tail -n 80
dmesg | tail -n 50

Troubleshooting

  • Board boots but no network: try Ethernet first; confirm the interface name with ip a; check ip r for a default route.
  • Package downloads fail: confirm time with timedatectl and DNS with getent hosts; then retry pacman -Syu.
  • Random reboots or filesystem errors: treat power and storage as suspects; try a different PSU and a different SD card.
  • System is up but SSH is unavailable: confirm sshd is running; check firewall settings; use serial console to recover.
  • After update you lose access: boot with serial logging; check journalctl -b -p err for errors; revert the last risky change first (networking/SSH).

Common mistakes

  • Updating without a working recovery console (serial or local access).
  • Flashing the wrong target device (always confirm with lsblk first).
  • Skipping checksum verification and blaming the board for a corrupt download.
  • Trying Wi‑Fi first boot with an unknown dongle instead of Ethernet.
  • Changing SSH settings before confirming key-based login works.

Author: LeMaker Documentation Team
Last updated: 2026-01-04