Skip to main content
Question

RK3588 (Axelera BSP 1.2.1): Unable to Boot Ubuntu 22.04 from SATA – Mender Forcing eMMC RootFS

  • February 24, 2026
  • 1 reply
  • 10 views

Hey everyone,

I'm trying to boot Ubuntu 22.04 from a SATA SSD on a Metis Compute Board (RK3588) running the Axelera BSP.

Setup

  • Board: Metis Compute Board (RK3588)

  • BSP: Axelera Voyager Linux 1.2.1 (Mender-managed A/B boot)

  • Goal: Boot Ubuntu 22.04 from SATA SSD (/dev/sda1)

What I've Done

  • Built a full Ubuntu 22.04 arm64 rootfs on the SATA SSD

  • Copied BSP kernel modules (6.1.148-rockchip-standard) into the rootfs

  • Set correct fstab using UUID

  • Verified systemd and libc are present and valid

  • Used mender_post_setup_commands to override mender_kernel_root to /dev/sda1 after Mender setup

The Problem

Mender overwrites mender_kernel_root every boot with the eMMC partition.
Even after overriding it, the kernel attempts to boot from SATA but fails and then falls back to eMMC via mender_try_to_recover, leaving me stuck at a splash screen.

I currently do not have UART access, so I can’t see kernel logs during the failed boot attempt.

Additional Note

If the system gets stuck at the splash screen permanently, the only way I’ve found to recover is:

  • Set DIP switch 1 to the ON position

  • Flash a fresh image to the board

Question

Has anyone successfully redirected the rootfs away from Mender-managed eMMC partitions on this BSP?

What exactly does the kernel expect inside the rootfs to successfully pivot root in this setup?
Is there something specific required by the Axelera/Mender boot flow that a standard Ubuntu rootfs might be missing?

Thanks in advance πŸ™

1 reply

  • Author
  • Cadet
  • February 24, 2026

Update β€” What We've Tried So Far

Hey, wanted to share progress in case it helps anyone with the same setup.

The Mender override fix: Discovered that mender_setup hardcodes mender_kernel_root every boot, so setting it manually gets overwritten. The workaround was using mender_post_setup_commands which runs after Mender's setup:

fw_setenv mender_post_setup_commands "setenv mender_kernel_root /dev/sda1"

This correctly overrides the value β€” confirmed via fw_printenv. The kernel does attempt to boot from SATA, but then mender_try_to_recover kicks in and falls back to eMMC silently.

What the Ubuntu rootfs has:

  • /sbin/init (systemd) βœ…
  • /lib/aarch64-linux-gnu/libc.so.6 βœ…
  • /lib/modules/6.1.148-rockchip-standard/ (copied from BSP) βœ…
  • Correct /etc/fstab with UUID βœ…
  • initramfs generated via update-initramfs -c -k 6.1.148-rockchip-standard βœ…
  • ldconfig run inside chroot βœ…

Still splash freezes every time. Without UART we can't see why pivot root is failing.

Current workaround β€” chroot + VNC: Since we can't boot natively, we set up a working Ubuntu environment via chroot over ADB:

mount -o remount,rw /
mount /dev/sda1 /mnt/ubuntu
mount --bind /dev /mnt/ubuntu/dev
mount --bind /proc /mnt/ubuntu/proc
mount --bind /sys /mnt/ubuntu/sys
chroot /mnt/ubuntu /bin/bash

Then started a TightVNC server inside the chroot and connected from the host PC β€” giving us a full XFCE desktop running Ubuntu 22.04 over VNC. It works but it's not a native boot.

New issue: Now trying to use the Voyager SDK inside this Ubuntu environment and hitting:

Found kernel driver version 1.2.3, but at least version 1.4.1 is required.

The BSP ships with kernel driver 1.2.3 but the SDK needs 1.4.1+. Is there a newer BSP that includes the updated driver? And does anyone know the debug pad pinout for UART on the Metis board β€” that would let us finally see what's failing during the SATA boot attempt.

Thanks πŸ™