ARM Linux: Reliable Setup Checklist

ARM Linux setup checklist - Systematic configuration process and setup steps diagram

Summary

This checklist is about the small things that decide whether an ARM Linux install behaves itself: power, storage, verified images and the basic housekeeping that comes after first boot. Those are the points that tend to fail first. When a board starts crashing, corrupting files or refusing to boot after an update, the fault is usually there rather than in the software stack.

Start with power and storage. Jumping straight to packages and services is a classic mistake, because a weak supply or a tired card makes software look guilty for no reason. Get the base right and the rest becomes far easier to trust.

Who this is for

This is for people bringing up an SBC for the first time, and for anyone re-provisioning a board that has to run unattended. Put it into production, home automation or any service that needs to stay up, and this is the baseline that stops small setup errors turning into long support calls.

What you'll do

Check that power and storage meet the minimum spec.
Verify the image checksum before flashing so a broken download does not waste the rest of the afternoon.
Boot, update and reboot once under real conditions to see whether the system stays steady.
Set a minimal security baseline for remote access, using SSH keys and a firewall.
Write down the configuration so recovery and troubleshooting are quicker later.
Put basic monitoring in place for failures that matter, such as disk full and service faults.

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 metre, and thick, 24AWG minimum, using micro-USB or USB-C. Thin phone charging cables are the wrong tool here.
Storage: Use a reputable brand microSD card such as SanDisk or Samsung, or an eMMC module. Keep one spare known-good card for recovery testing.
Network: Ethernet is recommended for initial setup because it is more reliable than WiFi when things go wrong.
Console access: Keep a serial UART adapter or HDMI plus keyboard ready in case SSH does not come up.
Documentation tools: A plain text editor or note-taking app is enough to record configuration decisions and login credentials.

Pre-flash checklist

Select the correct image

Match the image to the exact board model, not just the SoC family. Banana Pi and Banana Pro use different device trees even though both are built around the A20 SoC.
Choose the distribution around the job in front of you: Armbian for servers and stability, Raspbian for Raspberry Pi compatibility, Ubuntu or Debian for mainstream packages, Arch Linux ARM for rolling-release updates.
Prefer recent stable releases instead of old images, mainly for security updates and 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 lead to strange boot failures and burn time in troubleshooting that should never have been needed.

Prepare storage media

Insert the SD card into the card reader.

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

Check the device name again. Writing to the wrong device destroys data irreversibly.

Flash the image

Recommended: Etcher (cross-platform GUI):

Download it from balena.io/etcher.
Select the image file, select the target device, then click Flash.
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

Insert the flashed SD card into the board, with the power off first.
Connect the Ethernet cable.
Connect HDMI and keyboard if available for monitoring.
Connect power last.
Wait 60-90 seconds for the first boot, since the initial setup is still running.
Watch the activity LED. If it is solid or off, treat that as a possible failure.

Find the board's IP address

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

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 check that 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 the SSH key pair on your workstation, not on the board:

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

Copy the public key to the 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 the 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, stored off-board, with the essentials:

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 so boot reliability is actually tested.
Quarterly: Test backup restoration, check that the documentation is still current, and verify storage health.
Annually: If the board runs 24/7 services on SD storage, consider replacing the card before it fails.

Troubleshooting common setup issues

Random freezes, reboots, or filesystem errors

Swap the power supply and cable first. Use a 5V 2-3A supply with a 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 that is ruled out.
Check for undervoltage warnings: dmesg | grep -i voltage.

Can't find the board's IP address

Check the router's DHCP leases for a hostname like "bananapi" or "armbian".
Try another Ethernet cable or port. Link LEDs should be lit on both ends.
Use a serial console to confirm 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 that the SSH service is running on the board, using serial or HDMI: systemctl status ssh.
Check firewall settings: sudo ufw status. Allow SSH if it is blocked: sudo ufw allow 22/tcp.
Confirm you are on the same subnet. SSH will not cross router NAT without port forwarding.
Try SSH with verbose output: ssh -v user@BOARD_IP so you can see where the connection fails.

Frequently asked questions

How long does first boot take?

Usually 60-120 seconds. First boot runs the initial setup, including filesystem resize, SSH key generation and package configuration. Later boots are quicker, normally 20-40 seconds to SSH login. If the first boot goes past 5 minutes, check the 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 the default accounts after your own user is in place. On test or development systems, changing the default password is enough.

What if I lock myself out of SSH?

Use the serial console or HDMI plus keyboard to log in locally. Check the SSH config: sudo nano /etc/ssh/sshd_config. Verify PasswordAuthentication yes temporarily, or add your SSH key to ~/.ssh/authorized_keys. Test SSH from a new terminal before you close the session you are using to make changes.

How do I set up WiFi instead of Ethernet?

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

What backup strategy should I use?

For system configuration, back up /etc/ and home directories weekly. For a full system, create an SD card image periodically: sudo dd if=/dev/mmcblk0 of=backup.img bs=4M status=progress. Compress it to save space: gzip backup.img. Keep backups off-board, on a NAS, in the cloud or on an external drive.

Should I enable automatic updates?

For home or lab systems, enable automatic security updates only, using unattended-upgrades on Debian or Ubuntu. For production, use manual updates during maintenance windows. Do not auto-update the kernel or bootloader without supervision. Boot failures need physical access to recover.

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

Stable or LTS uses an older kernel and older packages, but it has a track record and fewer surprise changes. That makes it the safer choice for servers. Cutting-edge or rolling images ship the latest kernel and software, with new features and more frequent updates. They suit development and testing. The choice is straightforward enough: uptime first, or new features first.

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