Boot fail from usb/ssd on odroid c4

I wrote the DietPi_OdroidC4-ARMv8-Bullseye.img to a 120g SSD installed into a usb-3(to sata) case as it was $25 total cost and HD speed in desktop use.

I have petitboot 20220315 installed on SD and boot from that with the dietpi attached and it will see it. Ive tried changing parms and am able to get it to try to boot.

I set it to specify paths/urls manually and the kernel and intird paths are fine
I change the device tree from the tmp_usb0… to match the kernel and add dtb/amlogic/meson-sm1-odroid-c4.dtb

I also change the boot argument from root=/dev/mmcblk0p1 to sda1

It then tries to boot and loads drivers, scripts-premount, then start waiting for root file system from local-block and times out:

gave up waiting for root file system device

if I run blkid both the petitboot sd on mmcblk1p1 and usb ssd on /dev/sda1 are present.

Hope one of the dietpi experts can tell me if there is a way to get this working or some other way to use ssd hd’s connected via usb3.

This hardware setup works with debian 11 except I have been unable to get sound working through hdmi there. I just cant win!

I did my bullseye install via netboot. Is there one available for Dietpi?

P.S. This should probably be in the troubleshooting forum but since I couldnt boot it all I knew was the img name.

Welcome to our community forum.

So boot goes into systemd stage already, right? First I thought it could be a missing controller driver in initramfs, but it would fail to mount at bootloader stage already, also initramfs-tools packs in all available drivers but default.

You flashed the fresh image to the USB drive and there is no SD card or eMMC with the same image on it that could cause a UUID conflict in /etc/fstab?

Yes, the uuid on the petitboot sd and dietpi are different. If I swap Dietpi with another identical usb drive with debian 11 then it will load that.

Is it still in the initrd stage? I dont know when systemd starts. I think I recall looking for the scripts/local-block and it appeared to have mmc hardcoded. But I looked again and its not there so I dont know what I was seeing. The only file in usr/share/initramfs-tools that has mmc is hook-functions.

I was searching to see if I could figure out how petitboot builds the boot parms as I would like to not have to modify for every dietpi boot. If I remove the device tree entry it just errors on what was there before I deleted it! So I wonder if there isnt a petitboot issue?

I’ll attach a couple pics if that helps…


I tried to sync with what bullseye does at boot and made some observations:

If I change the boot parms to whats used by deb11 I get a lot of stuff detected (usb, etc) but then fail because no root dev specified. If I set the root=/dev/sda1 I get the timeout in the previous pic.

Deb11 uses a different structure/names in boot for the dtb stuff. So even if I use the correct tmp path it still fails to find the dtb.

I created a symlink to the dtb in boot and reformatted(swap underscores for slashes) the device tree and booted again and it threw the same waiting for root fs even though its now complaining about the sd it booted from (mmcblk0p1). Same with root=/dev/sda1

Sorry to be so annoying…

Ah you’re right, it’s in initramfs stage.

With Armbian kernel, the dtbs have an uncommon path indeed. Actually the kernel package ships with those in /usr/lib as well, but we remove them since they double with the ones shipped by the dedicated dtb package in /boot/dtb. Probably we should switch this, so that the dtb package is skipped and instead the dtbs in /usr/lib are used, to have compatibility with other bootloaders. At least for new images this should work well.

However, if you define the dtb path explicitly, it shouldn’t matter.

But I have no idea why /dev/sda1 wouldn’t exist (when the dtb is correctly loaded). Did you try to use the UUID instead, as done in /boot/boot.cmd|scr?

I just tried it with root=UUID and PARTUUID and both fail the same. Once I change the path for the device tree then It seems to load kernel/initrd/dtb (at least it appears to find them) and initrd starts but then loses something and cant read the fs.