Jump to content

[Odroid-C4] Alert! Root UUID does not exist. Dropping to a shell!


Recommended Posts

Hey, I'm trying to boot Armbian 27 Feb bullseye for Odroid C4 from microSD card and I get dropped to initramfs console because root UUID is not found. I fsck'd the card and it seems okay. Read that I should say to the kernel to wait for root to be found with rootdelay, added a line to armbianEnv.txt to no avail (didn't run any update command, though). What are your thoughts? Any other ideas? Thanks!

Board: Not on the list
Link to comment
Share on other sites

Donate your old hardware to community. Start a giveaway Raffle!

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.

Link to comment
Share on other sites

I continued testing today as it is a bright and sunny, but unseasonably cold and windy Sunday here. I did two tests, one with an identical but brand-new card as above (I bought them on Amazon as a 5-pack), and with a different card. The different card is also a PNY card, but a different series, capacity, and class of card. I followed the same process I had been using above to first use the SD Card Formatter to set the card to sdcard.org specifications. Then, I used the Win32 Disk Imager software to load the same image to the card. The results are interesting.


1. The brand-new card from the same 5-pack bundle purchased in late December 2022 as the problematic one in my last post (PNY 32GB 'Elite' microSDHC UHS-I U1) also fails with similar indication. This suggests the possibility of a systemic problem with this model of card combined with this Armbian image is systemically problematic. Performance characteristics observed above for a card that claims "up to 100 MB/sec. read speeds" on the Amazon.com details page for this item. The read and write performance is consistent across several cards used in this package of five, even if it fails to exceed 75% of the claimed top speed, as many factors influence this that are not stated. So, I have little suspicion that these are counterfeit cards, but have not dug into the details to verify this. 

2. The other model card (PNY 64GB Class 10 microSDXC UHS-I U1 - model number: P-SDUX64U190-GE) is an older card that I purchased in April of 2015. However, using this one resulted in a successful installation and boot of the installed OS. Additionally, this class 10 UHS-1 card claimed up to 90 MB/sec. read speeds. I have not tested this but did find it interesting that the write speeds when writing the image to the card with Win32 Disk Imager were about 50 MB/sec, about 2.5 times faster than the newer SDHC cards purchased more recently. I do not know if the 'XC' designator on this older card vs. the 'HC' designator on the more recent cards should account for such a difference in writing speed.


So, here are suggestions I would offer -


1. Try a different SDHC or SDXC card that is at the perfomance level of Class 10, UHS-I, 'V30', and 'A1' class or better. Note that the 'V30 and 'A' markings are newer and are not necessarily required. Also, keep in mind that the size of the cards was different in my testing. This was because I did not have other 32GB cards on hand for testing. Though not likely, the size of the card could be a part of the issue. For this version of Armbian, I would suggest no smaller than a 16 GB card, as the uncompressed image written to the card is only a little short of 8 GB.


2. Avoid bargain cards, as these occasionally turn out to be counterfeit or at least misrepresented in terms of performance. Even the large vendors like Amazon.com are occasionally duped into re-selling fakes or cards that do not match the specification claimed. Watch the rating scores and look at the product reviews for complaints about performance and data storage size that might indicate counterfeit cards.


3. Let the forum know by responding in this thread whether any of this was helpful to you. If you have the time, experiment with different elements involved in the process to write the card and tell us what you did to get around this problem.


I hope this helps and I wish you success in arriving at the functioning ODROID C4 milestone running the version of Armbian you have selected!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...