ARM Linux: Reliable Setup Checklist

Summary

This checklist focuses on the repeatable steps that make ARM Linux installs stable on small hardware: good power, good storage, verified images, and basic operational hygiene after first boot. These practices prevent the most common failure modes: power-related crashes, storage corruption, boot failures after updates, and security compromises.

If you only follow a few rules, prioritize power and storage first—many symptoms that look like "software problems" come from voltage drop or failing media. A reliable foundation prevents hours of troubleshooting later.

Who this is for

Builders bringing up any SBC for the first time, or re-provisioning a board that needs to run unattended. If you're setting up an SBC for production use, home automation, or services that must run reliably, this checklist ensures you start with a solid baseline.

What you'll do

• Confirm your power and storage baseline meet minimum specifications.
• Verify the image checksum before flashing to detect corrupted downloads.
• Boot, update, and reboot once to validate stability under real conditions.
• Set a minimal security baseline for remote access (SSH keys, firewall).
• Document your configuration for rapid recovery and troubleshooting.
• Establish monitoring for critical failures (disk full, service failures).

Requirements before you begin

• Power supply: 5V 2A minimum for most boards, 3A for boards with onboard WiFi/SATA or when using power-hungry USB devices. Use official or quality aftermarket supplies.
• Power cable: Short (under 1 meter), thick (24AWG minimum) micro-USB or USB-C cable. Avoid thin phone charging cables.
• Storage: Reputable brand microSD card (SanDisk, Samsung) or eMMC module. Keep a spare known-good card for recovery testing.
• Network: Ethernet connection recommended for initial setup (more reliable than WiFi for troubleshooting).
• Console access: Serial UART adapter or HDMI+keyboard for emergency access if SSH fails.
• Documentation tools: Text editor or note-taking app to record configuration decisions and login credentials.

Pre-flash checklist

Select the correct image

• Match image to exact board model (not just SoC family). Example: Banana Pi and Banana Pro have different device trees despite using the same A20 SoC.
• Choose distribution based on use case: Armbian for servers/stability, Raspbian for Raspberry Pi compatibility, Ubuntu/Debian for mainstream packages, Arch Linux ARM for rolling-release updates.
• Prefer recent stable releases over old images (security updates, hardware support).

Verify download integrity

# Linux/macOS:
sha256sum downloaded-image.img
# Compare output with published checksum on download page

# Or use verification file:
sha256sum -c image.sha256
# Should output: downloaded-image.img: OK

# Windows (PowerShell):
Get-FileHash -Algorithm SHA256 downloaded-image.img

Never skip checksum verification—corrupted downloads cause mysterious boot failures that waste hours of troubleshooting.

Prepare storage media

1. Insert SD card into card reader.
2. Identify the device:

   # Linux:
   lsblk -o NAME,SIZE,MODEL,TYPE,MOUNTPOINT
   # Look for device with correct size, usually /dev/sdX or /dev/mmcblkN
   
   # macOS:
   diskutil list
   # Look for device like /disk2
   

3. Double-check the device name—writing to the wrong device destroys data irreversibly.

Flash the image

Recommended: Etcher (cross-platform GUI):

1. Download from balena.io/etcher.
2. Select image file, select target device, click Flash.
3. Etcher verifies the write automatically.

Alternative: dd (Linux/macOS command-line):

# Unmount all partitions on the device first:
sudo umount /dev/sdX*

# Write image (replace sdX with actual device):
sudo dd if=image.img of=/dev/sdX bs=4M status=progress

# Flush write cache (critical step):
sudo sync

# Verify write (optional but recommended):
sudo dd if=/dev/sdX bs=4M count=512 | sha256sum
# Compare with original image checksum

First boot procedure

Initial boot

1. Insert flashed SD card into board (power off first).
2. Connect Ethernet cable.
3. Connect HDMI and keyboard if available (for monitoring).
4. Connect power last.
5. Wait 60-90 seconds for first boot (initial setup runs).
6. Watch for activity LED blinking—solid or off indicates possible failure.

Find the board's IP address

• Check router DHCP lease table (look for hostname like "bananapi", "armbian").
• Use network scanner: nmap -sn 192.168.1.0/24 (replace with your subnet).
• Check serial console or HDMI output: ip a.
• Try default hostnames: ping bananapi.local (if mDNS/avahi enabled).

Initial login

ssh user@BOARD_IP
# Default credentials vary by image (check documentation)
# Common defaults: root/1234, pi/raspberry, ubuntu/ubuntu

Change default passwords immediately:

passwd
# Enter new strong password

Post-boot configuration checklist

Apply security updates

# Debian/Ubuntu/Armbian:
sudo apt update
sudo apt -y full-upgrade

# Check if kernel was updated:
uname -r
# Note the version for comparison after reboot

# If kernel updated, reboot:
sudo reboot

Wait 2 minutes, then reconnect and verify services started correctly:

systemctl --failed
# Should show no failed units

Set hostname and timezone

# Set hostname:
sudo hostnamectl set-hostname myboardname

# Set timezone:
sudo timedatectl set-timezone America/New_York
# List available: timedatectl list-timezones | grep -i york

# Verify:
hostnamectl
timedatectl

Configure SSH securely

Generate SSH key pair on your workstation (not the board):

ssh-keygen -t ed25519 -C "your-email@example.com"
# Save to default location, set passphrase (optional)

Copy public key to board:

ssh-copy-id user@BOARD_IP
# Enter password one last time

Test key-based login:

ssh user@BOARD_IP
# Should log in without password prompt

Disable password authentication (only after confirming key login works):

sudo nano /etc/ssh/sshd_config
# Set: PasswordAuthentication no
# Set: PermitRootLogin no

sudo systemctl reload ssh

Configure basic firewall

sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
# Add other services as needed: 80/tcp, 443/tcp, etc.
sudo ufw enable
sudo ufw status verbose

Document your configuration

Create a simple text file (store off-board) with essential information:

Board: Banana Pi
Image: Armbian 24.2.1 Bookworm (flashed 2026-01-11)
Hostname: homeserver
IP: 192.168.1.50 (DHCP reservation on router)
SSH: Key-based only, password auth disabled
User account: jamie
Firewall: ufw enabled, ports 22,80,443 open

Serial console: 115200 baud, /dev/ttyUSB0
Power: 5V 3A official supply, short USB cable
Storage: SanDisk Ultra 32GB (purchased 2025-12)

Installed services:
- nginx
- fail2ban

Backup location: /mnt/nas/backups/homeserver/
Last backup: (update after first backup)

Notes:
- Root login disabled
- Automatic security updates enabled

Final verification checks

# Confirm board is reachable:
ping -c 3 BOARD_IP

# Test SSH access:
ssh user@BOARD_IP

# Check system health:
df -h              # Disk space (should have plenty free)
free -h            # Memory (swap configured if needed)
uptime             # System running time
systemctl --failed # No failed services
journalctl -b -p err | head -n 20  # No critical errors

# Check temperature:
cat /sys/class/thermal/thermal_zone0/temp
# Should be below 60000 (60°C) at idle

# Test network connectivity:
ping -c 3 8.8.8.8
ping -c 3 google.com  # Tests DNS resolution

# Verify SSH key authentication:
exit  # Log out
ssh user@BOARD_IP  # Should log in without password

# Verify firewall:
sudo ufw status verbose

Ongoing maintenance baseline

• Weekly: Check disk space (df -h), failed services (systemctl --failed), error logs (journalctl -b -p err).
• Monthly: Apply updates and reboot under supervision to verify boot reliability.
• Quarterly: Test backup restoration, verify documentation is current, check storage health.
• Annually: Consider replacing SD card proactively (before failure) if used for 24/7 services.

Troubleshooting common setup issues

Random freezes, reboots, or filesystem errors

• Swap power supply and cable first—use 5V 2-3A supply with short, thick cable.
• Replace the SD card next; do not try to "repair" a flaky card for production use.
• Re-flash after verifying checksums; assume corruption until proven otherwise.
• Check for undervoltage warnings: dmesg | grep -i voltage.

Can't find the board's IP address

• Check your router's DHCP leases (look for "bananapi" or "armbian" hostname).
• Try a different Ethernet cable or port (link LEDs should be lit on both ends).
• Use a serial console to verify the system reached a login prompt and run ip a.
• Scan your network: nmap -sn 192.168.1.0/24.

SSH connection fails or times out

• Verify SSH service is running on board (check via serial/HDMI): systemctl status ssh.
• Check firewall settings: sudo ufw status. Allow SSH if blocked: sudo ufw allow 22/tcp.
• Verify you're on the same network subnet (can't SSH across router NAT without port forwarding).
• Try SSH with verbose output: ssh -v user@BOARD_IP to see where connection fails.

Frequently asked questions

How long does first boot take?

60-120 seconds typically. First boot runs initial setup (filesystem resize, SSH key generation, package configuration). Subsequent boots are faster (20-40 seconds to SSH login). If first boot exceeds 5 minutes, check serial console for errors.

Should I use the default user account or create a new one?

Create a new user for production systems: sudo adduser yourname, sudo usermod -aG sudo yourname. Disable or remove default accounts after setting up your own. For test/development systems, changing the default password is sufficient.

What if I lock myself out of SSH?

Use serial console or HDMI+keyboard to log in locally. Check SSH config: sudo nano /etc/ssh/sshd_config. Verify PasswordAuthentication yes temporarily, or add your SSH key to ~/.ssh/authorized_keys. Always test SSH access from a new terminal before closing your active session after config changes.

How do I set up WiFi instead of Ethernet?

Connect via Ethernet for initial setup first (more reliable). Once SSH is working, configure WiFi: sudo nmtui (NetworkManager TUI) or edit /etc/wpa_supplicant/wpa_supplicant.conf. Set country code: sudo iw reg set US. Test WiFi before disconnecting Ethernet.

What backup strategy should I use?

For system configuration: Backup /etc/ and home directories weekly. For full system: Create SD card image periodically: sudo dd if=/dev/mmcblk0 of=backup.img bs=4M status=progress. Compress to save space: gzip backup.img. Store backups off-board (NAS, cloud, external drive).

Should I enable automatic updates?

For home/lab systems: Enable automatic security updates only (unattended-upgrades on Debian/Ubuntu). For production: Manual updates during maintenance windows. Never auto-update kernel/bootloader without supervision—boot failures require physical access to recover.

What's the difference between stable and cutting-edge images?

Stable/LTS: Older kernel and packages, proven stability, less frequent updates, recommended for servers. Cutting-edge/rolling: Latest kernel and software, new features, more frequent updates, recommended for development/testing. Choose based on uptime requirements vs. feature needs.

Related guides

• Downloads hub: image files and integrity checks
• Quick Start Guide
• SBC Maintenance Routine
• Hardening SSH and Services on SBCs
• Boot and Storage Notes

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