Rock Pi 4B Debian Desktop not booting and boot folder empty

#1

I have a problem when booting my Rock Pi 4B v1.3.
It was running the official Debian Desktop image, released somewhere in 2020. However, I’m not sure which one.

The OS is located on an eMMC card (32GB).
When I look at the files on the eMMC, everything seems to be there.
The only thing I did before it stopped working was upgrade my apt packages. It asked me if I wanted to update the boot on my eMMC and I thought “sure why not”. Which may not have been the best idea.

I have ruled out all hardware issues because:

  • I can still read the eMMC when booting from a different OS on the SD card so I know that the RockPi, eMMC port and eMMC card are not dead.
  • When I try to boot from the eMMC without SD card plugged in, it just stops doing anything. The red and green LED are both constantly on (they don’t blink). The screen doesn’t show anything. The debug console on ttyS4 doesn’t show anything either.
  • When the SD card is plugged in, it just skips the eMMC completely.

So I have the following questions:

  • How did this happen? Could this have occurred when upgrading my packages and updating the boot?
  • What can I do to fix this? I’d rather not do a complete reinstall to not lose any progress I made.

Thanks in advance.

Ren

#2

First, backup your data.

https://wiki.radxa.com/Rockpi4/backup

Download an image and mount the boot folder in the image, copy everything in the image boot folder to your eMMC boot folder.

#3

Hello Jack, thank you for your reply.

I have backed everything up and copied the boot img from the debian image to the boot partition on the eMMC. No luck unfortunately.
However, I also tried copying the other partitions (loader1, loader2 and trust.img).

Now when powering on, the red status LED flashing twice every second or so.
The OS still doesn’t boot up but at least I get information on the debug console.

The last lines I get are:

Begin: Running /scripts/local-block … done.
Begin: Running /scripts/local-block … done.
Begin: Running /scripts/local-block … done.
Begin: Running /scripts/local-block … done.
Begin: Running /scripts/local-block … done.
done.
Gave up waiting for root file system device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! UUID=[Some UUID] does not exist. Dropping to a shell!
(initramfs) UUID=[Some shorter UUID]

Out of curiousity: What does it mean that it works after copying these partitions?
Does this mean that the loader1, loader2 and/or trust partitions have corrupted or something?
Also: What is the function of these partitions? I can’t find much information about this online.

Thanks,
-Ren

#4

That means that ROCK Pi 4B Stops in U-Boot. But fail to boot kernel.

By default the debug console is on ttyS2. You can check the boot log via ttyS2. Check this serial console guide. https://wiki.radxa.com/Rockpi4/dev/serial-console

If you could, please provide the boot log here.

#5

You’re right, I was mistaken in the number in the OP. I was using the right port at the wrong baud rate.

The kernel now loads, this is after I copied the loader1, loader2 and trust partition from “rockpi4b_debian_buster_xfce4_arm64_20210608_1321-gpt.img”.
I guess these were corrupted or something.

I don’t have a log of when the Rock Pi stopped in U-Boot. If it helps you I can try reverting to the “broken” loader1 which I backed up beforehand and look at the log?

The kernel then stopped because it was searching for the wrong UUID. Updating the extlinux.conf fixed this.

#6

@SARen

I see. I’m so glad to hear that the issue is solved.