Boot and Storage Notes for SBCs

Boot and storage setup imagery - SD cards, boot sequence diagram, storage media and SATA connections

Summary

Boot problems on SBCs usually come from three causes: unstable power, unreliable storage, or an image that doesn’t match the board. This guide outlines quick triage steps and practical fixes that don’t require guesswork. By systematically checking power delivery, storage integrity, and boot configuration, you can isolate most boot failures within minutes.

Unlike desktop PCs with BIOS diagnostics and verbose boot screens, SBCs often fail silently or with minimal feedback. Understanding the boot sequence and common failure points lets you diagnose problems even without serial console access.

Who this is for

Anyone experiencing boot failures, random crashes, or filesystem corruption on SBCs. If your board won’t boot consistently, boots into emergency mode, or shows filesystem errors, start here before reflashing or replacing hardware.

What you’ll do

  • Understand the SBC boot sequence and failure points.
  • Test power supply stability and voltage under load.
  • Diagnose storage failures using kernel logs and filesystem checks.
  • Match images to board revisions and storage types.
  • Implement safe shutdown procedures to prevent corruption.
  • Select appropriate storage for reliability and performance.

Understanding the boot sequence

Most ARM SBCs follow this boot order:

  1. Power-on: SoC begins execution from internal ROM.
  2. Boot ROM: Loads first-stage bootloader (SPL/U-Boot) from storage (SD/eMMC).
  3. U-Boot: Initializes hardware, loads kernel and device tree, passes control to kernel.
  4. Kernel: Initializes devices, mounts root filesystem, starts init system.
  5. Init (systemd): Starts services, reaches login prompt or graphical environment.

Failures at each stage produce different symptoms:

  • Stage 1-2 (ROM/SPL): No activity LEDs, no HDMI output. Usually power or storage connection failure.
  • Stage 3 (U-Boot): Activity LED blinks briefly then stops. Storage readable but bootloader corrupted or missing.
  • Stage 4 (Kernel): HDMI shows boot messages then kernel panic. Often wrong device tree or corrupted kernel image.
  • Stage 5 (Init): Boot messages appear but system hangs or drops to emergency shell. Filesystem corruption or misconfigured services.

Common boot failure causes

Power delivery problems

Symptoms: Random crashes, boot loops, filesystem corruption after power events.

Causes:

  • Weak power supply: 5V supply rated for 1A used with board drawing 2A under load.
  • Voltage drop in cables: Long or thin cables (28AWG) cause significant voltage drop.
  • Insufficient current: USB ports on computers rarely provide adequate current for SBCs.
  • Noisy power: Cheap supplies without proper filtering cause instability.

Tests:

# Check kernel for undervoltage warnings:
dmesg | grep -i "under-voltage\|voltage drop\|power\|throttle"

# On some boards, check voltage directly:
cat /sys/class/hwmon/hwmon0/in0_input
# Output in millivolts (should be 4900-5200 mV under load)

Solutions:

  • Use official or quality aftermarket 5V 2-3A power supply.
  • Use short (under 1 meter), thick (24AWG or better) micro-USB or USB-C cables.
  • Remove power-hungry USB devices during boot (external HDDs, WiFi adapters).
  • Add low-ESR capacitors near power input for filtering (hardware modification).

Storage media failures

Symptoms: Filesystem mounted read-only, I/O errors in dmesg, files disappearing, boot fsck repairs.

Causes:

  • Wear-out: Flash memory has limited write cycles (typically 500-3000 full-drive writes for consumer SD cards).
  • Corruption from unsafe shutdowns: Power loss during write operations corrupts filesystem metadata.
  • Counterfeit or low-quality media: Fake capacity cards, grade-C flash chips.
  • Poor card reader: Flashing with unreliable USB card reader introduces errors.

Tests:

# Check for I/O errors:
dmesg | grep -i "mmcblk\|error\|i/o error\|blk_update_request"

# Check filesystem:
sudo fsck -n /dev/mmcblk0p1
# -n: read-only check, doesn’t modify filesystem

# Test storage performance (may reveal failing sectors):
sudo badblocks -sv /dev/mmcblk0
# WARNING: This is destructive on some media, backup first

# Check SMART data if available:
sudo smartctl -a /dev/mmcblk0

Solutions:

  • Replace SD card immediately if I/O errors appear - failures accelerate rapidly.
  • Use high-endurance cards (SanDisk MAX Endurance, Samsung PRO Endurance) for write-heavy applications.
  • Enable log rotation and reduce logging verbosity to minimize writes.
  • Mount read-mostly filesystems with relatime or noatime mount options.
  • Use wear-leveling filesystems (F2FS on eMMC) for better longevity.
  • Consider USB-attached SATA SSD for root filesystem if supported.

Image/board mismatch

Symptoms: Board powers on but never reaches login, HDMI shows scrambled output or nothing.

Causes:

  • Wrong device tree: Image built for Banana Pi used on Banana Pro (different GPIO, peripherals).
  • Wrong bootloader: U-Boot compiled for SD boot used on eMMC.
  • Wrong SoC family: Image for Allwinner A10 used on A20 board.
  • Corrupted download: Image file corrupted during download.

Tests:

# Verify image checksum before flashing:
sha256sum downloaded-image.img
# Compare with published checksum on download page

# On running system, check loaded device tree:
cat /proc/device-tree/model
# Should match your board exactly

# Check boot messages via serial console:
# Connect UART adapter, use screen or minicom at 115200 baud
screen /dev/ttyUSB0 115200
# Look for "Wrong device tree" or "Failed to load" messages

Solutions:

  • Download image from official sources only (lemaker.org, armbian.com).
  • Verify checksums before flashing - don't skip this step.
  • Match image to exact board model (not just SoC family).
  • Use Etcher or dd for flashing - avoid Windows tools that modify partitions.
  • Keep a known-good SD card as rescue media.

Unsafe shutdown damage

Symptoms: Filesystem check runs on every boot, systemd emergency mode, journal corruption.

Causes:

  • Power loss during write: Metadata updates interrupted mid-operation.
  • Hard reset during boot: Pressing reset during filesystem initialization.
  • Kernel panic during shutdown: Driver bug prevents clean unmount.

Solutions:

# Always shut down cleanly:
sudo shutdown -h now
# or
sudo systemctl poweroff

# For unattended systems, add UPS or monitor power button:
# Configure acpid or systemd-logind to handle power button gracefully

# Enable journaling filesystem features:
# ext4: data=ordered (default) or data=journal for more safety
sudo tune2fs -o journal_data /dev/mmcblk0p1

# Set filesystem check intervals:
sudo tune2fs -c 30 -i 1m /dev/mmcblk0p1
# Check every 30 mounts or 1 month

Boot diagnostic commands

Run these on a booted system to check for signs of instability:

# Check recent boot errors:
journalctl -b -p err | less
# Look for: failed services, I/O errors, kernel warnings

# Check kernel ring buffer:
dmesg --color=never | tail -n 150
# Look for: mmcblk errors, voltage warnings, failed device initialization

# Check filesystem mount options:
mount | grep "^/dev"
# Verify: rw (read-write), not ro (read-only forced by errors)

# Check systemd boot time:
systemd-analyze blame | head -n 20
# Slow boot may indicate failing storage or services timing out

# Check for failed services:
systemctl --failed

# Check last boot time:
uptime
last reboot | head -n 5
# Frequent reboots indicate instability

Choosing reliable storage

MicroSD card selection

For general use (desktop, development):

  • SanDisk Ultra or Samsung EVO Plus
  • Class 10, UHS-I (U1) minimum
  • 16-32GB sufficient for most distributions

For 24/7 services (servers, logging systems):

  • SanDisk MAX Endurance or Samsung PRO Endurance
  • Rated for continuous recording (10,000+ hours)
  • Higher write endurance (tens of thousands of program/erase cycles)

Avoid:

  • No-name brands from marketplaces (often counterfeit)
  • Cards with suspiciously high capacity at low prices (fake capacity)
  • Very old cards (flash degrades over time even when unused)

eMMC vs SD card

If your board supports both:

  • eMMC advantages: Faster (especially random I/O), more reliable, soldered (can’t be removed accidentally).
  • SD advantages: Cheaper, easier to replace, can swap between boards.
  • Recommendation: Use eMMC for production/always-on systems, SD for development/testing.

USB-attached SSD

Some boards support booting from USB after initial bootloader on SD/eMMC:

  • Advantages: Much faster, longer lifespan, larger capacity.
  • Disadvantages: Extra component, requires USB 3.0 for best performance, more power draw.
  • Setup: Keep bootloader on SD, mount root filesystem from USB SSD.

Troubleshooting specific scenarios

Board won’t boot at all (no LEDs, no activity)

  1. Check power supply is plugged in and switched on.
  2. Try different power supply (5V 2A minimum).
  3. Try different power cable (shorter, thicker gauge).
  4. Remove all USB devices and try again.
  5. Try different SD card (known-good card from another working board).
  6. Check for physical damage (burned components, swollen capacitors).

Boots to emergency mode or maintenance shell

Symptoms: "Give root password for maintenance" prompt.

Causes: Filesystem errors detected during boot, /etc/fstab references non-existent devices.

Steps:

  1. Enter root password to get shell access.
  2. Check filesystem: fsck -y /dev/mmcblk0p1 (repairs automatically).
  3. Check /etc/fstab: cat /etc/fstab. Comment out lines for devices not present.
  4. Remount root read-write: mount -o remount,rw /.
  5. Edit fstab: nano /etc/fstab.
  6. Reboot: reboot.

Random freezes, reboots, or crashes during operation

  1. Check power first: Swap power supply and cable. Measure voltage if possible (should be 4.9-5.2V under load).
  2. Check temperature: cat /sys/class/thermal/thermal_zone0/temp. If above 80000 (80°C), add cooling.
  3. Check for kernel errors: dmesg | grep -i "error\|fail\|bug".
  4. Check for OOM kills: journalctl | grep -i "out of memory\|killed process". Add swap if memory exhausted.
  5. Test storage: sudo badblocks -sv /dev/mmcblk0 (destructive, backup first).
  6. Minimal boot test: Boot with network cable unplugged and no USB devices to isolate hardware issues.

Frequently asked questions

How do I access the serial console for debugging?

Connect a USB-to-UART adapter (3.3V logic level) to the UART pins on the board (usually labeled TX, RX, GND). Use terminal software: screen /dev/ttyUSB0 115200 or minicom -D /dev/ttyUSB0 -b 115200 on Linux, or PuTTY on Windows. Serial console shows bootloader and kernel messages even when HDMI doesn’t.

What’s the difference between boot and system failures?

Boot failures occur before you see a login prompt (bootloader, kernel, init). System failures occur after login (services crashing, application errors). Boot failures are usually hardware/power/storage; system failures are usually software configuration.

Should I use ext4 or F2FS for the root filesystem?

ext4 is the safe default (mature, widely supported, good performance). F2FS is optimized for flash storage (better wear-leveling) but less mature. Use ext4 unless you have specific reasons for F2FS (high write load, eMMC storage).

Can I recover data from a corrupted SD card?

Sometimes. If the card is still readable: dd if=/dev/mmcblk0 of=sdcard-backup.img bs=4M to create an image, then fsck or testdisk to recover files. If the card has hardware failure (not detected at all), data recovery is unlikely. Always keep backups.

Why does my board boot sometimes but not always?

Intermittent failures point to power issues (marginal supply, poor contact), temperature-dependent hardware failure, or failing storage with intermittent read errors. Test with different power supply first, then replace SD card.

How long should boot take?

Typical boot times: 20-40 seconds to SSH login on server images, 45-90 seconds to desktop on GUI images. Slower than 2 minutes usually indicates storage problems, network timeouts (waiting for DHCP), or misconfigured services.

What mount options reduce SD card wear?

Add to /etc/fstab: noatime (don’t update access time on reads, reduces writes), commit=60 (delay writes for up to 60 seconds, reduces frequency). Example: /dev/mmcblk0p1 / ext4 defaults,noatime,commit=60 0 1.

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