I ran into the same problem with Armbian_23.02.2_Odroidc4_jammy_current_6.1.11_xfce_desktop.img.xz released 27 February 2023.
My equipment to write SD card images is a PC running Windows 11. In this case, I used the PNY 32GB SD Card that had just been running an official ODROID image (ubuntu-22.04-4.9-mate-odroid-c4-hc4-20220713.img.xz) This SD card has also been used with been used with other images and ARM-based SoCs. So, I was a bit surprised seeing the early error complaining that the UUID did not exist and finding myself in a busy box shell with the initramfs prompt.
My process was to first "Quick format" the SD card with the official SD Card Formatter software from the sdcard.org then use Win32 Disk Imager (v 1.0) to write the image. It has been a long time since I have had a system die this early in the boot process. If my rusty memory serves me correctly, the last time I saw something like this (over a decade ago on a Sun Microsystems Ultra 45 workstation running Solaris 10), the problem was a failing disk drive.
Another strange wrinkle that suggests the possibility of a bad card is that I happen to have a compatible eMMC card on which I used the same process and software (but necessarily different USB hardware) to write the image. The eMMC card works flawlessly.
The next thing I did with the non-booting SD card was plug it back into the PC, start Win32 Disk Imager again, select the image file and the device, then run the 'Verify Only' function. The results shows that Win32 Disk Imager indicates a match between the image file on the PC and what is on the SD card. This suggests that the problem is not with the SD card hardware but also does not rule out the USB 3.0 adapter stick that I used to write the image.
For fun, I decided to try starting over changing only one thing at a time in my process, hoping that the problem was traceable back to some minor relevant detail that I had missed or forgotten about. I started up the SD Card Formatter software, selecting the "Overwrite format" option instead of the "Quick format" option. As expected, this process took much longer. Unfortunately, I did not find any media verification / validation features in the SD Card Formatter software.
When the "Overwrite format" finished (about 30 minutes after I started), it reported that it had formatted the disk as FAT32 with 32 Kbyte cluster size. At this point, I again used Win32 Disk Imager to write the image to the SD card, following the same steps and configuration selection. The Win32 Disk Imager updates the write speed about every second. Write speeds are mostly between 21 and 23 MB / sec., with the occasional short duration (1 - 2 sec.) drops to 15~16 MB / sec. write speed. Sequential read speeds during the verify operation when tested earlier were consistently in the 69 - 70 MB / sec. range. These are expected performance levels with this class 10 card. Win32 Disk Imager indicated that the write had completed successfully. I shut down the app, ejected the SD card in the Windows tray, physically removed it from the PC, then shutdown the ODROID C4 running from eMMC without problems. After removing the eMMC card, I installed the SD card and booted. Same trouble.
It then occured to me that the case I had purchased with the ODROID C4 has a close fit area around the SD card slot. So, I tried again to boot the image after removing the C4 from its case, connecting the I/O cables, installing the SD card, then applying power. Saw the same failure at the same point in the boot process. So, I do not think the case was preventing the SD card from seating properly.
Since this board had worked with this same SD card running a different image, I decided to go back to the image that had been functioning and use my standard process to 'build' the same SD card with the image that previously worked on it. The ODROID image booted without event and works as expected.
So, experimentation suggests there is some problem with this combination of Armbian image and booting from an SD card. One other intersting thing I noticed, is how much faster the blue indicator comes on with the older ODROID image as compared to the Armbian image. Perhaps there is some relevance with uboot code that is a factor in this?
Other tests I will have time for later that I would like to try include booting the Armbian image from a different SD card to ensure this specific card is not an issue, though it seems unlikely at this point. The other variable within easy reach to test would be to use a different writer application, such as the Raspberry Pi Writer tool that i have sucessfully used with other images. I would be happy to offer up what I can in the way of testing if the gurus do not have access to an ODROID C4.