Got a brand new Raspberry Pi 5 Compute Module Development Kit
Flashed the latest Volumio from here today, on a USB drive
When I try to boot the RPi it’s stuck on this
“Waiting for usb devices this should not take too long”
Wondering this board is compatible. There are only 2 USB 3.0 ports and 1 USB-C for power.
the Volumio image for Raspberry Pi is compatible with the CM5 mounted on the DevKit.
some USB drives are not fully compatible with the CM5, please try another one.
Please also make sure to use a proper USB TypeC PSU, it is recommended to use the official 27W one designed for RPi5
Looks like it’s power related. Waiting for plug adapter as the official RPi AC adapter came with wrong plug type 
However, I was able to directly flash OS onto the eMMC using my Thunderbolt USB-C cable and MacBook. It’s working now.
Thanks.
I managed to reproduce the problem you described
with a CM5 with empty EMMC, boot from USB does not work, the boot process is stuck at the message “Waiting for usb devices this should not take too long”
the very same USB drive works without problem when connected to a RPi5
@nerd could you please try to reproduce it on your side as well?
This is not related to the Volumio image.
a CM5 with empty eMMC can’t boot from USB.
USB boot exists only to expose eMMC for flashing via rpiboot, not for runtime OS boot.
No USB boot unless you explicitly disable eMMC for rpiboot flashing
i tried to boot RaspiOS from the very same USB drive and it works just fine.
I also tried different USB drives, same story
@Wheaten if your statement was correct, RaspiOS would not boot as well.
In fact, Volumio does boot from USB on the CM5 (I can see the Volumuo plymouth boot animation with a HDMI display connected), but the boot process get stuck at a certain point, before loading the OS.
Several sites mention this, but if incorrect, then I didn’t mention it.
this is different, CM5 modules with EMMC cannot boot from SD-card, because the SD-card signals are not exposed on the connectors, SD-card and EMMC are mutually exclusive.
the reported issue is about boot from USB drive. it does work with RaspiOS with no problems, it does not work properly with Volumio. the boot process is initialized, but it gets stuck at a certain point.
@Wheaten I was able to boot LibreElec and Moode images via USB on the same board. Only Volumio wasn’t booting up. Could be that Volumio is drawing more power and I wasn’t supplying enough. The reason why I think this could be the case is because the only way I could get rpiboot to flash the eMMC was when using the official Apple USB-C Thunderbolt cable connected to my MacBook Pro. A regular USB-C cable failed to flash the drive.
That might indeed the case.
But looking at @Darmur response, Volumio boots but fails to execute the next step.
Let’s see what @nerd reply is.
I can confirm other OS boot fine from USB on CM5, I tried Lakka and LibreELEC
Besides Volumio, Ubuntu 24.04 has problems, but it could be due to the 2GB RAM of the CM5 I was using for testing (the minimum is now 4GB)
Hey @Darmur,
Thanks for reproducing this. You were right that the hang sits on the Volumio side, not in the kernel or firmware path. Plymouth is already up at the point of failure.
Traced it to custom_init_partition_params() in the pi initramfs. The function iterates /dev/mmcblk[0-9] and, whenever any mmc block device is present, unconditionally forces BOOT_DEVICE=mmcblk0 and DO_GEN=yes. init_partition_params() then takes the DO_GEN branch and synthesises imgpart, bootpart and datapart as /dev/mmcblk0p1…p3, discarding the UUID= values parsed from cmdline.txt a moment earlier. On a CM5 Dev Kit the eMMC is exposed as mmcblk0 even when empty, so the init code proceeds to wait for partitions on the empty eMMC while the USB stick carrying the squash image sits unused on sda. wait_for_partitions_ready times out after 5 retries and drops to a recovery shell, which plymouth obscures behind its last message.
This did not surface on any classic Pi model because USB boot and eMMC could not coexist on the same board. The init code was written when the CM5 was not even on the drawing board, so the combination of an empty eMMC on mmcblk0 alongside a USB boot volume was simply not a case the code had to account for. Lite version of CM5 does not have means of hogging mmcblk0, simply does not have it.
Fix committed:
The new guard returns early whenever imgpart is UUID= or LABEL= and genpnames is not on cmdline, so the normal boot path skips the mmcblk hijack on every board, and the post-upgrade genpnames migration path is preserved untouched.
A rebuilt image is required to validate this on the CM5 Dev Kit in practice. The change will land in the next dev build.
@KCAudio your workaround of flashing the eMMC directly is fine as an interim path. Proper USB boot will work once you flash a dev image that includes the commit above.
Kind Regards,
@nerd Well done!!
I always was wary about the DO_GEN parameter and I “declare” not being guilty of introducing it 
Also think it never covered a common use-case and there are other ways to configure this situation.
@nerd many thanks for your quick analysis of the problem and super-quick fix.
here the link of the new alpha image with the included fix, from my tests I can confirm it is effective, we can merge it in the master branch so it will end-up in the next stable release.
I think this issue was also relevant for the CM4 with empty EMMC, and it’s not related to Bookworm because I can reproduce it on buster images too. The fact that is slipped under the radar is because it requires very specific conditions, not very common ones.