Banana Pi

Move Root to SATA on Banana Pi: SD Boot + SATA Root Filesystem for Real-World Reliability (2026 Guide)

Published: 21 March 2026 14 min read By LeMaker Team
Banana Pi connected to SATA hard drive with SD card for boot and root filesystem migration diagram

Why Move Root to SATA

Running root on a microSD card works, but it's the single biggest reliability risk on an always-on SBC. SD cards fail from write wear. SATA drives don't — at least not on the same timescale.

The Banana Pi Pro has an onboard SATA connector. The practical setup: keep the SD card for boot (U-Boot + kernel + initramfs only) and put the actual root filesystem on a SATA drive. You get:

How this works: U-Boot loads from the SD card, reads the kernel and device tree, then the kernel mounts the SATA drive as / instead of the SD card partition. The SD card is only touched during the first few seconds of boot.

Prerequisites

Warning: This procedure will erase the SATA drive. Back up any data on it first. The SD card contents are preserved.

Partition the SATA Drive

# Wipe existing partition table
sudo wipefs -a /dev/sda

# Create a single Linux partition spanning the full drive
sudo fdisk /dev/sda <
Tip: Disabling the journal (-O ^has_journal) on an SSD reduces write amplification. If you're worried about power-loss resilience, keep the journal enabled — or consider F2FS instead. Both filesystems handle this trade-off differently. For deeper analysis, see the kernel LTS guide for filesystem support details by kernel version.

Copy the Root Filesystem

# Mount the SATA partition
sudo mkdir -p /mnt/sata
sudo mount /dev/sda1 /mnt/sata

# Copy the entire root filesystem, preserving permissions and special files
sudo rsync -axHAWXS --numeric-ids --info=progress2 / /mnt/sata/

# Verify the copy completed
ls -la /mnt/sata/
# Should mirror your root filesystem exactly

The rsync flags explained:

  • -a — archive mode (recursive, preserves permissions, timestamps, etc.)
  • -x — don't cross filesystem boundaries (skips /proc, /sys, /dev, tmpfs mounts)
  • -H — preserve hard links
  • -A — preserve ACLs
  • -W — whole file transfer (faster for local copies)
  • -X — preserve extended attributes
  • -S — handle sparse files efficiently

Configure Boot to Use SATA Root

You need to tell the kernel to mount SATA as root instead of the SD card. The method depends on your bootloader configuration.

Method A: Armbian (armbianEnv.txt)

# Edit the Armbian boot environment
sudo nano /boot/armbianEnv.txt

# Find or add the rootdev line:
rootdev=/dev/sda1

# If using UUID (more reliable):
# Get the UUID of your SATA partition
blkid /dev/sda1
# Add: rootdev=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Method B: Manual boot.cmd/boot.scr

# Edit boot.cmd
sudo nano /boot/boot.cmd

# Find the setenv bootargs line and change root= to point to SATA:
# OLD: root=/dev/mmcblk0p1
# NEW: root=/dev/sda1 rootfstype=ext4 rootwait

# Recompile boot.scr
sudo mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
Warning: The rootwait parameter is critical. Without it, the kernel may try to mount root before the SATA controller has initialized, causing a kernel panic. Always include rootwait when booting from SATA.

Update fstab

Edit fstab on both the SD card and the SATA copy to ensure consistency.

# Edit fstab on the SATA root (the one that will actually be used)
sudo nano /mnt/sata/etc/fstab

# Change the root mount from SD to SATA:
# OLD: /dev/mmcblk0p1  /  ext4  defaults,noatime  0  1
# NEW:
/dev/sda1  /  ext4  defaults,noatime  0  1

# Optionally mount the SD card's boot partition:
/dev/mmcblk0p1  /boot  vfat  defaults,ro  0  2
Tip: Using UUIDs in fstab instead of device names (/dev/sda1) is more robust. Device names can shift if you add USB storage. Get UUIDs with blkid.

Verification Steps

# Unmount SATA
sudo umount /mnt/sata

# Reboot
sudo reboot

After reboot, verify:

# 1. Check that root is on SATA
mount | grep "on / "
# Should show /dev/sda1 on / type ext4

# 2. Confirm correct filesystem
df -h /
# Should show SATA drive capacity, not SD card capacity

# 3. Verify the SD card is barely used
cat /proc/diskstats | grep mmcblk0
# Write counts should be near zero after boot

# 4. Check dmesg for any errors
dmesg | grep -iE "error|fail" | grep -v "firmware"

# 5. Test write performance
dd if=/dev/zero of=/tmp/testfile bs=4M count=256 conv=fsync
# SATA SSD: expect 80-150 MB/s
# SATA HDD: expect 40-80 MB/s
# (SD card was probably 10-20 MB/s)
rm /tmp/testfile

Performance Comparison

Typical numbers from a Banana Pi Pro with a Samsung 860 EVO 250 GB SSD vs a SanDisk Extreme 32 GB SD card:

Test SD Card SATA SSD Improvement
Sequential write (4M blocks) 18 MB/s 110 MB/s 6x
Sequential read (4M blocks) 22 MB/s 130 MB/s 6x
Random 4K write (IOPS) ~800 ~12,000 15x
Random 4K read (IOPS) ~2,500 ~25,000 10x
apt upgrade (100 packages) ~8 min ~2 min 4x

The random write improvement is what matters most for system responsiveness. Log writes, package installs, database operations — everything that hits random I/O patterns benefits enormously.

Full Rollback Procedure

If SATA boot fails, rolling back to SD-only root takes 60 seconds:

  1. Power off the Banana Pi Pro
  2. Remove the SD card and put it in another computer
  3. Revert the boot configuration: 
    # Mount the SD card's boot partition
sudo mount /dev/sdX1 /mnt

# For Armbian: edit armbianEnv.txt
sudo nano /mnt/armbianEnv.txt
# Remove or comment out: rootdev=/dev/sda1
# Or set: rootdev=/dev/mmcblk0p1

# For manual boot.scr: revert boot.cmd
sudo nano /mnt/boot.cmd
# Change root= back to /dev/mmcblk0p1
sudo mkimage -C none -A arm -T script -d /mnt/boot.cmd /mnt/boot.scr

sudo umount /mnt
  4. Put the SD card back in the board and boot — root will mount from the SD card again
Key point: The SD card's root filesystem was never modified or deleted during this process. It's still there, intact. You're just telling U-Boot which partition to mount as root. Switching back is a one-line config change.

Related Articles