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
  • 2 replies
  • 64 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 🙏

2 replies

  • 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 🙏


  • Axelera Team
  • March 10, 2026

Hello ​@hrithik_naik ,

Thank you for sharing the detailed steps you followed in attempting to boot Ubuntu 22.04 from the SATA SSD. Have you had a chance to review the Metis Compute Board User Guide?

The Metis Compute Board ships with a Yocto-based BSP, and if yours is outdated, you can follow the instructions in Section 3 to reflash it. The latest BSP v1.3.1 includes the Metis driver v1.4.4, which is compatible with the latest Voyager SDK v1.5.3 — Re-flashing the Metis Compute Board to latest BSP v1.3.1 should resolve the driver version mismatch error you encountered.

For running Ubuntu 22.04 with the Voyager SDK, the recommended approach is to use pre-built Docker containers (see Section 5 of the User Guide). This gives you a full Ubuntu-based environment with all the SDK tools pre-configured, while keeping the Yocto BSP as the underlying OS. You can mount your SATA SSD for additional storage using the instructions in Section 4.1.7.

Out of curiosity — what was the motivation behind booting Ubuntu natively from the SATA SSD rather than using the Docker-based workflow? Understanding your use case might help us provide better guidance.