RPi 5 Hybrid Boot with MicroSD Card & SSD via Penta SATA HAT cause initramfs

Hardware and peripherals SATA HAT
1

I have been using RADXA QuadSata HATs with RPI 4B for couple of years now and had no issues, recently bought the Penta SATA HAT for RPI 5 and ran into a strange issue so first time registered with RADXA community and posting my first topic.

Core Idea: The bootloader loads kernel from MicroSD, then the kernel mounts root=PARTUUID= and continues to boot from the SSD.

  1. Prepare MicroSD with Raspberry Pi OS 64-Bit(Full Media with Desktop) rootfs & /boot: Flash the full OS to the MicroSD using Raspberry Pi Imager.

  2. Prepare SSD with Raspberry Pi OS(Full Media with Desktop) rootfs & /boot: Flash the full OS to the SSD using Raspberry Pi Imager.

  3. Make sure SSD is not connected to the HAT, Insert the MicroSD card into the RPI-5 and power up.

  4. Make sure the RPI-5 is connected to the internet, perform apt update and apt full-upgrade
    sudo apt update && sudo apt full-upgrade -y

  5. To use the SATA HAT on RPI-5, Edit /boot/firmware/config.txt file(on /boot/firmware/ of microSD card) and enable the pcie gen 1 by adding the “dtparam=pciex1” parameter under [All] section and save the file.

  6. Power up the RPI-5 with SATA HAT attached along with the SSD (with the OS)

  7. Get the SSD root ( / ) PARTUUID with following command:
    lsblk -o NAME,TYPE,UUID,PARTUUID,SIZE

  8. Point the kernel at the SSD root (/): Edit MicroSD’s /boot/firmware/cmdline.txt to use the SSD’s root PARTUUID.
    e.g.: console=serial0,115200 console=tty1 root=PARTUUID=796ebf23-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=IN

  9. Power on the RPI-5 and align the fstab: On the SSD’s /etc/fstab, ensure entries reference the SSD’s own PARTUUIDs:
    • / on PARTUUID= 796ebf23-02
    • Do not mount /boot/firmware from SSD; the SD provides it. Either remove that line or point /boot/firmware to the SD only if you plan to mount it post-boot for edits.
    /etc/fstab looks like below after commenting the /boot/firmware line:
    proc /proc proc defaults 0 0
    #PARTUUID=796ebf23-01 /boot/firmware vfat defaults 0 2
    PARTUUID=796ebf23-02 / ext4 defaults,noatime 0 1

  10. First boot and verification
    • Power off, insert SD, connect SSD, power on.
    • Check root device & /boot device with lsblk -f; it displayed the /boot/firmware is booted from /dev/mmcblk0p1 (Micros SD card) and rootfs ( / ) is pointed to /dev/sda2

This is exactly how I want my RPI-5 load and run, /boot/firmware to load from MicroSD card at all times and use the SSD as rootfs ( / ).

RPI-5 works from 30mins to an hour with multiple reboots, shutdown and turn off power supply and turn on power supply, however randomly while I am working in terminal I start getting “exec format error” for system commands such as lsblk, blkid or even for ls command and when I reboot the RPI-5 loads into initramfs.

I have tried multiple times and run into similar situation every time and unable to identify the pattern or root cause for the issue.

RPI-5 Details:

Raspberry Pi 5
RADXA PenTA SATA HAT
1 x MicroSD card is SANDISK Extreme 128GB A2 V30
1 x SSD is Seagate Barracuda Compute Q1 SSD 240GB SATA 6GBPS and power required is +5VDC 0.20A => This is the drive to be used as rootfs ( / )
3 x SSDs for Data are Seagate Barracuda Compute with each disk of 2TB capacity and power required as +5VDC 1.0A
1 x Raspberry Pi Original 27W USB-C Power Supply

Assuming it could be power related issue, I tried powering up the RPI-5 with the different power adapters with different combinations, while repeating the entire process mentioned above for each combination and the results were same.

Power Supply Combinations Tested:

  1. Only Raspberry Pi Original 27W USB-C Power Supply
  2. Only FEDUS AC Adapter Model: FE-12V5AMP
    Input: 90-240~, 50Hz, 1.5A
    Output: 12V 5AMP
  3. Only KENTO AC Adapter Model: EA1050D~240
    Input: 100-240~1.8A, 50-60Hz
    Output: 12V 5A - 60W Max
  4. Tested with 1(RPI Original) connected to RPI-5 Type-C port & 2 (FEDUS) connected to SATA HAT’s 12V DC power input port
  5. Tested with 1(RPI Original) connected to RPI-5 Type-C port & 3 (KENTO) connected to SATA HAT’s 12V DC power input port

Thanks
Srini T

2

After spending a day googling, reading multiple articles in various forums, got to know that the Hybrid Boot is not a supported configuration with SATA SSDs.

Here’s the link: https://github.com/raspberrypi/firmware/issues/1653

3

It seems to me that you use some AI generated list. The problem is you get old strange concepts as this is 10+ years proprietary methods from RPi that were long incompatible with standard Linux boot process (as it is on PC). Core issue is there is no mentioning of a rootfs copy or transfer. In addition, the 10+ years old methods to use PARTUUID= instead of UUID= or LABEL= gets you into problems.

What you want is very well possible although not nice as you need an microSD card because it is correct that RPi cannot handle SATA. It is proprietary closed-source bootloader, if they would use U-Boot it all would work out-of-the-box. Or some variant of EDK2-UEFI, it all works fine with ROCK5B for example, even with just very cheap M.2 PCIe-to-SATA adaptors.

Best you can do from working SD-card bootfs+rootfs is format some partition on SSD (Ext4 or Btrfs, use Ext4 if you don’t know about Btrfs), mount that somewhere (e.g. sudo mount UUID= ext4 /mnt/ssdrootfs ).
Then sudo update-initramfs -c -k all
Then ‘rsync -avx --numeric-ids’ the whole rootfs from SD / to SSD /mnt/ssdrootfs
Then edit /mnt/ssdrootfs/etc/fstab and /boot/firmware/cmdline.txt to use your-new-UUID for rootfs on SSD.
Then it should be OK for reboot. You can check with sudo mount what is mounted where and in principle you can then wipe the rootfs on SD-card, the brute-force method is sudo blkdiscard /dev/mmcblk0p2

4

Thanks @radrocks will try your suggestion and update the post.

5

Hi Radrocks,

have performed multiple attempts of the steps that you suggested with UUID and finally the last attempt was today with PARTUUID(as i have seen PARTUUID is being referenced in /etc/fstab and /boot/firmware /cmdline.txt when the MicroSD card is imaged with Rasberry Pi imager tool).

I have followed the exact steps mentioned below which include your suggestions, may i request you to review the steps and provide your feedback and correct me if i am doing anything wrong.

sudo lsblk -o NAME,SIZE,TYPE,MOUNTPOINT ==> This detects only MicroSD card as PCIE is not enabled.

Enable PCIE
sudo vi /boot/firmware/cmdline.txt
Add dtparam=pciex1 to the end of the file and save it.
Reboot RPI 5 and verify if SSD is discovered.

Steps below are performed to cleanup the SSD from previous data.
sudo wipefs -a /dev/sda
sudo parted -s /dev/sda mklabel gpt
sudo parted -s /dev/sda mkpart rootfs ext4 1MiB 100%
sudo partprobe /dev/sda

sudo lsblk -o NAME,SIZE,TYPE /dev/sda
Output:
NAME SIZE TYPE MOUNTPOINT UUID PARTUUID
loop0 2G loop
sda 223.6G disk
└─sda1 223.6G part e9d91638-777b-48f7-9362-7744790fa9d4 9178bfdd-cb54-46a0-b1b4-5d301e8158e3
sdb 1.8T disk 154055f6-1b1e-e2e0-0f90-efdeb79b276f
sdc 1.8T disk 154055f6-1b1e-e2e0-0f90-efdeb79b276f
sdd 1.8T disk 154055f6-1b1e-e2e0-0f90-efdeb79b276f
mmcblk0 29.7G disk
├─mmcblk0p1 512M part /boot/firmware 3A0B-B890 8b04f4f9-01
└─mmcblk0p2 29.2G part / d5c521d2-34d1-47f4-a846-c46e74a9cf60 8b04f4f9-02
zram0 2G disk [SWAP] db783b14-5df4-43e2-b551-795a8fcc53e6

sudo mkfs.ext4 -F -L rootfs /dev/sda1
sudo blkid /dev/sda1 #noted down the PARTUUID
sudo mkdir -p /mnt/ssdrootfs
sudo mount /dev/sda1 /mnt/ssdrootfs

sudo update-initramfs -c -k all
sudo rsync -avx --numeric-ids --info=progress2 / /mnt/ssdrootfs

sudo vi /mnt/ssdrootfs/etc/fstab
Replace contents with (adjusted with PARTUUID): Tried multiple times with UUID, so trried with PARTUUID in this last run.

Also left the /boot/firmware line to boot from MicroSD and configured it to load as Read-Only
proc /proc proc defaults 0 0
PARTUUID=8b04f4f9-01 /boot/firmware vfat defaults,ro,x-systemd.device-timeout=5s 0 2
PARTUUID=9178bfdd-cb54-46a0-b1b4-5d301e8158e3 / ext4 defaults,noatime 0 1

point the kernel to the SSD root by UUID (on the SD’s cmdline.txt) - Tried multiple times with UUID, so trried with PARTUUID in this last run.
sudo blkid /dev/sda1 # double-check PARTUUID
sudo vi /boot/firmware/cmdline.txt
Ensure it is a single line including (replace PARTUUID):
root=PARTUUID= rootfstype=ext4 fsck.repair=yes rootwait

Keep /boot/firmware on the SD (optionally read-only) —> made it similar to /etc/fstab of SSD as mentioned above sudo nano /etc/fstab Ensure your SD boot line is: PARTUUID= /boot/firmware vfat ro,x-systemd.device-timeout=5s 0 2

Sanity checks before reboot sync sudo mount -o bind /dev /mnt/ssdrootfs/dev sudo mount -o bind /proc /mnt/ssdrootfs/proc sudo mount -o bind /sys /mnt/ssdrootfs/sys sudo chroot /mnt/ssdrootfs update-initramfs -u -k all

sudo umount /mnt/ssdrootfs/dev /mnt/ssdrootfs/proc /mnt/ssdrootfs/sys
sudo umount /mnt/ssdrootfs

Reboot and verify if rootfs is pointing to the SSD root
sudo reboot

Expected Result: RPI 5 to boot from MicroSD card and then forward the booting process from SSD using the rootfs.

Actual Result: RPI 5 Powers up, but doesn’t boot and also the blue lights on the Penta SATA HAT do not lit up but I can hear the fan on RPI 5 spin.

6

So your cmdline.txt should contain:
root=PARTUUID=9178bfdd-cb54-46a0-b1b4-5d301e8158e3 rootfstype=ext4 fsck.repair=yes rootwait

Maybe you have that, but you don’t show that. Also:
sudo lsblk -o NAME,SIZE,TYPE /dev/sda
will not output a UUID and/or PARTUUID
Its should be:
sudo lsblk -o NAME,SIZE,TYPE,UUID,PARTUUID /dev/sda

I don’t understand why you run update-initramfs a second time with all that mount binds, I never did that.
Also I think this is Rasberry Pi OS Trixie, which I am not sure of if all initramfs stuff works as in Bookworm. You might need to change initramfs conf file to include most modules instead of dependencies. There is some change done in Debian. I do not have a Pi5 also do not use Trixie from RPi, just plain Debian Trixie, and so can’t reproduce, but I do not see a fundamental error. I have done this kind of things many times, in Linux (not only SBC’s).

I have serial console cables connected to my SBC’s, so I can see what would go wrong (I add loglevel=7 by default on cmdline). RPi will need some specific statements in config.txt and also needs a special cable. You might ask on RPi forum, this is not were Radxa can help. The HAT works, it is just booting the Pi differently.