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…
Thanks
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.
Our latest Odroid C4 image supports petitboot from SPI and that way USB boot 
.
2 Likes
I DL and wrote the 2023/02/04 version to my usb3-ssd and it boots under Petitboot! Very nice work!
Bullseye repo timed out on a key issue but retry worked. I installed xfce and the desktop comes up. No Sound though and dmesg shows bus/page faults from panfrost.
So at least its running from usb3-ssd now! Kernel updates on Debian 11 eventually resolved sound issues. I will keep working with it now 
1 Like
Sorry to say its failing again. I did apt upgrades a few weeks ago running 9.1 and then its failing to find the uuid at boot even though I just watched it start to boot. So I overwrote with the latest DietPi_OdroidC4-ARMv8-Bookworm (8.2?) and then it boots nicely, says that 9.2.1 is available and goes through all the steps to upgrade the system which then fails to reboot.
I dont see anyone else posting about this. I must be special 
I wrote the image again. Pulled the network so automatic updating would NOT occur. Booted, waited for net timeout and then it let me login so I enabled the network and did apt updates. Shutdown, pulled the network and booted. System comes up to a blank screen. Nothing, cant even get into a virtual console (alt-cntl-f1).
So it appears the current odroid updates are whats killing the system and not the upgrade from dietpi 8 to 9.2
- 2025 * March Update DietPi 9.11.2
Wrote the most recent DietPi_OdroidC4-ARMv8-Bookworm.img.xz to my drive using BalenaEtcher and was detected and booted from Petitboot. It timed out and dropped to shell but ‘exit’ let it continue and install. It did all the usual install tasks and I added mate desktop.
It boots and runs fine. NO sound even though it appears to detect it. I did install alsa during setup. I also dont see any panfrost named packages installed but there are msgs from it in dmesg so its installed
I tried Armbian the other day and it did get the sound right. I just wish they would switch their build to use the same image setup that DietPi now uses because once I wrote their image to my drive it was unreadable and would not boot. Same image to SD worked but it is SO SLOW compared to usb3/ssd!
Thank you @MichaIng for your Hardkernel/amlogic support!
Trying to figure out if the reason sound isnt working is due to missing packages I found a script versioning - How to compare installed Linux packages between two machines - Stack Overflow
So I made a copy of the packages installed on dietpi 9.11.2 and on the latest armbian. Ran the perl script and got this report.
pkg_compare_raw.txt (27.7 KB)
I will look through it for alsa/pipewire sound packages and see if installing any of those helps and update this thread if I have any luck
